Migrate Your Customizations With iSetup: Part I So – your developers have been working on creating some new concurrent programs in your test environment. Or perhaps they’ve got some new request groups, printer setups, new responsibilities or other customized objects that need to be migrated out of the test environment and into production. Or perhaps you’d like to add users to a test environment that are already set up on production. It turns out you have three options:

1. Manually - Open up a screen pointing to your test environment and a screen pointing to your production environment, and manually copy (type) everything you want to move. Uggh – that’s how we did it in the olden days, but it is certainly not how we want to do it today. Manually making the changes takes too long, and it’s too easy to make mistakes. A thorough and time-consuming test of each migration would have to be included in your project plan.

2. FNDLOAD – Oracle’s utility can be used to download application data from an Oracle Applications instance into a portable, editable text file (.ldt file). The data in the FNDLOAD .ldt file can then be uploaded into another Oracle E-Business Suite instance. Check out Brad Simmons’ and Donna Campbell’s paper Customization Survival Guide: How to Use E-Business Utilities to Migrate Your Custom Code. They’ve included examples of commands and sample Unix scripts, and they’ve highlighted the potential “gotchas” that you need to keep in mind. With FNDLOAD, you’re working from a Unix account and have to have a thorough understanding of the objects that you want to move. You’ll still need to do a thorough test of the objects that you’ve migrated, but errors are less likely than if you hand-typed the information.

3. iSetup – iSetup is a module provided within the E-Business Suite that allows you to easily migrate setups using a user-friendly interface. You’ll work through E-Business Suite screens rather than at the Unix level, so you do not have to be a programmer or DBA to feel comfortable using this tool. iSetup includes templates that make it easy to move commonly migrated objects, and, unlike our other two options, iSetup documents the configuration changes to allow you to compare changes across instances and timelines. There is one major caveat with iSetup – your source and target instances must be running the same patch set levels of the E-Business Suite, so iSetup would not be the tool to use for an upgrade, but would be very useful once the upgrade is complete for ongoing maintenance.

For this paper, we’ll use two Release 12 Vision Instances that have been patched to Release Update Pack 12.0.5 (RUP5) Financials and HRMS. Besides the typical FND customizations that we expect iSetup to handle, like Roles, Users and Lookups, the Oracle E-Business Suite Release Content Document for Release Update Pack 12.0.5 (RUP5) Financials and HRMS says that iSetup also includes APIs for the General Ledger, Accounts Payable, Accounts Receivable, Assets, Cash Management, Credit Management, E-Business Tax, Legal Entity, Public Sector Financials, Payments, and WebExpense modules. It is worthwhile to stay current on your ATG Family Pack levels because Oracle continues to enhance iSetup.

Copyright 2008 TruTek 1

For this first round of evaluation, I’ll describe how iSetup works and test moving some users created on one instance over to another instance. Once I have that working, I’ll add more to the paper about issues encountered and ease of use. iSetup consists of three main pieces – iSetup Migrator, the tool that actually migrates data from one instance to another; iSetup Reporter, the tool that reports on what has been migrated; and Administration, the screens used to set up iSetup. iSetup allows you to migrate Application Setup data (AOL), Foundation data and Operational data, and then report on the configuration as well as compare configurations across instances or across time lines from the same instance.

Administration To use iSetup, you need to have an E-Business Suite account that has the iSetup responsibility. Note that this is a powerful responsibility, so your Applications System Administrators are not likely to hand it out to just anyone. Your company needs to incorporate using iSetup into your customization migration process. Customizations must be tested thoroughly on your test environment. A Functional Super User should sign off on the customization after thorough testing. Only then should the customization be considered for migration into your production environment. Most companies would also include a migration test from your test instance into another test instance before migrating into production. And, even though iSetup makes migrating a simple process, someone still needs to test the customization after it is migrated. From an account with the iSetup responsibility assigned, Figure 1 shows the screen you’ll see after selecting iSetup:

Copyright 2008 TruTek 2

Figure 1 Your Applications System Administrator or your Applications DBA will need to do some configuration of your environment before you can start migrating customizations. Figure 2 shows the Administration screen. In this case, we haven’t configured iSetup yet, so we’ll need to tell iSetup which Applications instances can migrate data into this instance.

Click on iSetup, and you’ll see ‘Home’, ‘Migrations’, ‘Reports’ and ‘Administration’.

Figure 2

Copyright 2008 TruTek 3

Before you can map an instance, your Applications System Administrator or DBA will need to copy the source instance’s DBC file into the target instance. In Release 12, DBC files are located under $FND_SECURE. Next, click on the Create button on the target instance (see Figure 2) to set up a new instance. In our example, the VIS instance is the target instance, and VIS1 is the source instance. Enter a Name for the instance that you’ll migrate from. Enter the DBC Filename of that instance. Enter the Responsibility Name that can migrate setups (you should choose iSetup). If the DBC file is not in place where iSetup expects to find it, or if you type the DBC Filename incorrectly, the Create Instance Mapping screen will give you an error.

Figure 3

Figure 4

Copyright 2008 TruTek 4

According to Oracle’s R12: Oracle iSetup Functional Overview online training class, additional settings that need to be reviewed to run iSetup are: 1. Profile Options, including AZ: VO Fetch Size (Oracle’s recommended value: 100),

AZ: Commit Row Counts (Oracle’s recommended value: 1000), AZ: CP Number of Batches (Oracle’s recommended value: 5, except if running Manufacturing APIs to extract or load, use 1), AZ: Number of Records For Home Tab (Oracle’s recommended value: 4), AZ: Reporter Max Records (Oracle’s recommended value: 100)

2. XML DB must be enabled for the database for both iSetup Migrator and iSetup

Reporter. MetaLink Doc. ID: 560719.1, How to troubleshoot iSetup issues describes how to check your database’s XML DB Setup: ♦ Check to see if the user XDB exists with the sql query: select * from all_users

where username=’XDB’; ♦ Confirm that the view RESOURCE VIEW exists with the sql command: describe

resource_view; ♦ Determine if the Oracle XML DB status is valid with the sql query: select status

from dba_registry where comp_id=’XDB’;

If you receive any “no rows selected” errors, you’ll need to install XDB using the instructions in MetaLink Doc. ID: 243554.1, How to Deinstall and Reinstall XML Database (XDB).

3. The database instances need to be able to connect to each other via sqlnet, so tcp.invited_nodes needs to be updated on the database tier in $TNS_ADMIN/sqlnet.ora. ♦ For each node, add: tcp.validnode_checking = yes to the sqlnet.ora file, then:

o On the source node, tcp.invited_nodes=(<source>,<central>) o On the central instance, tcp.invited_nodes=(<source>,<central>,<target>) o On the target instance, tcp.invited_nodes=(<central>,<target>)

The “central instance” is an instance that just runs iSetup. I am testing whether you can work with just a source and target instance because at least for now we don’t feel like using a third instance. But you can see that having a separate instance where all the setup configurations are maintained would be preferred, since you will lose your iSetup configurations if the instance that handles extracting and migrating the data is refreshed.

iSetup Migrator To migrate data, iSetup extracts data from a source instance, optionally transforms the data, and then loads the data into a target instance. The ability to transform data is a very useful feature. iSetup allows you to transform certain attributes within an Extract prior to loading the data into the target instance. This feature means that users can save a transformed set of data just once and then reuse that transformed data the next time they

Copyright 2008 TruTek 5

need to load data. Additional iSetup Migrator features include the ability to create a custom selection set, and to register Generic Loader interfaces and set filters for them to extract a subset of the data. For a simple example, from the SYSTEM ADMINISTRATOR responsibility, I created three new users on our VIS1 instance: MARYJOBEAKLEY, JONATHANHOWARD and JUMPINJEHOSEPHAT. Next, I’ll extract those three users from VIS1:

1. Create a new Selection Set

Figure 5 When you click on the Create button, you get to choose what type of information you want to extract. While there are a number of options, the one we’re interested in is General Foundation. This Selection Set is used to migrate AOL Foundation setups, including user accounts:

Copyright 2008 TruTek 6

Figure 6 Choose a pre-defined Selection Set from the list

Figure 7 Additional Select Sets that you may choose in the Create Selction Set: Select Template screen Next, we see the Create Selection Set: Set Parameters screen, where we can choose what we want to migrate:

Copyright 2008 TruTek 7

1. Notice that our Source Instance VIS1 is automatically available

3. Click on the Filter for “users” to see how much control we have over choosing users 2. Uncheck all the Select

boxes except ‘Users’

Figure 8 I gave my Selection Set a Name, “New Users”, I chose VIS1 from the list of values for the Source Instance, I gave my Selection Set a Description, “New Users for Production”. I unchecked all the boxes under the Select column except the one for Users. And then I clicked on the Filter to limit which users will be extracted:

Copyright 2008 TruTek 8

Figure 9 – The Create Selection Set: Set Parameters screen, just before filtering out users

Figure 10 If I click on the magnifying glass next to “USER_NAME”,

Copyright 2008 TruTek 9

Figure 11

Figure 12

Copyright 2008 TruTek 10

2. Click on the Filter for “users” to see how much control we have over choosing users

1. Uncheck all the Select boxes except ‘Users’

All we want are these three users, so I unclicked the checkmarked Select boxes for everything except “Users”. Then I clicked on the “Filter” icon to see how much help I might get in pulling the three users.

Copyright 2008 TruTek 11

Figure 13

Stay Tuned… This is as far as I got before my lovely VIS instance was refreshed, so I’ll take a break and come back to finish off the migration next month. In the meantime, read on to understand some of iSetup’s other features. I believe my next steps will be to finish the extract of my three users, then migrate the extract into my VIS1 database instance. My biggest concern as I tackled this migration was to see how simple it would be to find the three users and extract them. Just how user friendly is the iSetup User Interface? Stay tuned!

1. Click on Extracts

2. Next I’ll create an extract to get our new users from VIS1

Figure 14 The extract is next

iSetup Reporter With iSetup Reporter, users can compare setup data between snapshots of the data. The comparisons can be between two different instances, or on a single instance between two

Copyright 2008 TruTek 12

Copyright 2008 TruTek 13

different timelines. With this reporting capability, users can determine differences between the setups of two different instances, or determine what setups have changed over a period of time. Once I finish the migration, I’ll move on to detailing more about the reports. Stay tuned!

Sources MetaLink Note: 560719.1, “How to troubleshoot iSetup issues” – caveats include: 1. The Source and Target instances must be on the same patchset before migrating setup

data. Also, the ATG Family Pack level has to be the same. 2. A user must have an account on both the source and target instances. 3. The DBC file name is case-sensitive, so be careful when filling out the Instance

Mapping screen. 4. The file $TNS_ADMIN/sqlnet.ora on both the source and target instances must have

the corresponding instance invited. 5. This note references some patches for performance issues and

java.lang.OutOfMemory Errors. Oracle iSetup User Guide, Release 12, Part No. B31430-02, August 2007 Oracle offers three self-paced learning topics, all very helpful: R12: Oracle iSetup Functional Overview R12: Oracle iSetup Technical Overview R12: Oracle Payables iSetup Technical Overview