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

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

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.

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
2. Uncheck all the Select
boxes except ‘Users’ choosing 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

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

Copyright 2008 TruTek 13