Multi-Instance support in BI Apps using Multiple Contexts.

Contents
Multi-Instance support in BI Apps using Multiple Contexts. ........................................................................ 1

Introduction: ............................................................................................................................................. 1

Background ............................................................................................................................................... 2

Steps.......................................................................................................................................................... 3

Register one datasource in the BIACM UI............................................................................................. 3

Create Instance specific Contexts ......................................................................................................... 5

Generate Load Plan ............................................................................................................................... 8

Execute the Load Plan for each Instance ............................................................................................ 13

Supporting DEV, TEST, PROD instances .................................................................................................. 14

Physical Topology ................................................................................................................................ 14

Contexts .............................................................................................................................................. 15

Customization ......................................................................................................................................... 16

Instances Share same customizations ................................................................................................ 16

Instances Require Different customizations ....................................................................................... 16

Introduction:
Out-of-the-box BI Applications ships a single set of ETL Adaptors associated with a single logical schema.
This whitepaper details how the one ETL Adaptor can be run to extract data from more than one source
of the same product line version to bring the data into the same BI Applications data warehouse. In this
approach an ODI context is created for each additional source of the same product line version. Sources
can be deployed as Source Dependent Datastores in an SDS schema or on a transactional database. One
datasource can be configured to leverage an SDS while the other relies on the transactional database.

This approach currently does not support extracting from the different instances of the same product
line version in the same load plan - instead it is necessary to generate one load plan for each additional
data source of the same product line version and execute these separately.
This approach also supports the requirement that is typical in a development environment where one
ODI repository is used to populate more than one target DW.

Background
In the BI Apps metadata, each supported source type is represented by a product line version code. For
example, eBusiness Suite is considered a Product Line with multiple versions. Similarly, Siebel CRM is a
Product Line with multiple versions. PeopleSoft supports multiple pillars, each pillar is considered its
own product line. The table shows various codes used to represent some of the supported sources:

Product Line Version Product Line Code Product Line Version Code

Fusion V1 Instance FUSION FUSION_1_0

Oracle E-Business Suite R11.5.10 Instance EBS EBS_11_5_10

Oracle E-Business Suite R12.1.1.x Instance EBS EBS_12_1_1

Oracle E-Business Suite R12.0.0.x Instance EBS EBS_12_0

Oracle E-Business Suite R12.1.2.x Instance EBS EBS_12_1_2

Oracle E-Business Suite R12.1.3.x Instance EBS EBS_12_1_3

Oracle E-Business Suite R12.2.x Instance EBS EBS_12_2

JD Edwards EnterpriseOne 9.0.x Instance JDE JDE_9_0

JD Edwards EnterpriseOne 9.1.x Instance JDE JDE_9_1

PeopleSoft Enterprise 9.0.x CS Instance PSFT PSFT_9_0

PeopleSoft Enterprise 9.0.x FINSCM Instance PSFT PSFT_9_0

PeopleSoft Enterprise 9.0.x HCM Instance PSFT PSFT_9_0

PeopleSoft Enterprise 9.1.x CS Instance PSFT PSFT_9_1

PeopleSoft Enterprise 9.1.x FINSCM Instance PSFT PSFT_9_1

PeopleSoft Enterprise 9.1.x HCM Instance PSFT PSFT_9_1

PeopleSoft Enterprise 9.2.x CS Instance PSFT PSFT_9_2

PeopleSoft Enterprise 9.2.x FINSCM Instance PSFT PSFT_9_2

PeopleSoft Enterprise 9.2.x HCM Instance PSFT PSFT_9_2

Siebel CRM 8.1.1 Instance SEBL SEBL_8_1_1

Siebel CRM 8.2.2 Instance SEBL SEBL_8_2_2

A single load plan can be generated with any combination of a single instance of each product line
version. For example, you can have an Oracle E-Business Suite R11.5.10 Instance and a Siebel CRM 8.1.1
Instance in the same load plan. You can also have an Oracle E-Business Suite R11.5.10 Instance with an
Oracle E-Business Suite R12.1.3.x Instance. However, multiple instances of the same product line
version (for example, two different instances Oracle E-Business Suite R11.5.10) requires additional steps
to be supported.

Steps
Designate one datasource as the ‘initial’ datasource. This datasource is registered as normal in the
BIACM UI. All other datasources are added manually directly in the ODI Studio by copying the initial
datasource.

Make a note of the desired Instance name and datasource num Id used by each instance. Each
datasource has an associated relational and flat file physical server and schema. The values for the
physical server must be unique in ODI. Designate unique values ahead of time and use these values
consistently.

In the examples below, the naming convention used for the physical server is <Product Line Version
Code>_<Datasource ID> so we have the following:

Instance Datasource Relational Flat File Physical Context

Num Id Physical Server Server

eBusiness Suite 311 EBS11510_311 FILE_EBS11510_311 GLOBAL (Initially)

11.1.5.0 – North
America EBS111510_311

eBusiness Suite 312 EBS11510_312 FILE_EBS11510_311 EBS111510_312

11.1.5.0 – Europe

Register one datasource in the BIACM UI

Register a single instance in BI Applications Config Manager (BIACM). BIACM will automatically add a
physical server and schema in the ODI topology, update the corresponding logical schema with the
Datasource Num ID value, and map the two in the GLOBAL context.
Using our example, we would register the ‘eBusiness Suite 11.1.5.0 – North America’ datasource in the
BIACM UI with the Datasource Num Id 311. ODI Data Server name for the Oracle connection would be
EBS11510_311 and the File connection would be FILE_EBS11510_311.

Enter the connection details as normal in the next screen.

BIACM will automatically add the physical server and schema for the Oracle and File connections in ODI.

Open the ODI Studio Client, make a copy of the relational and flat file physical servers and schemas and
update the DATASOURCE_NUM_ID flexfield to hold a unique value assigned to the second instance.
Repeat for each instance that must be supported.

Using our example where the second datasource is assigned 312 as the Datasource Num Id, we end up
with the following where we have a single logical schema and multiple physical schemas:
Create Instance specific Contexts
Create two new contexts in ODI (for example EBS111510_311 and EBS111510_312) by duplicating the
GLOBAL context:
Edit and provide a unique value for both the Name and Code for each Context.

Map the source and targets in the first context. Since the initial source registered via BIACM already
performed this mapping, simply verify it is correctly mapped.

OLTP logical schema mapped to first instance’s physical schema:

Data Warehouse logical schema mapped to the data warehouse physical schema

Map the source and targets in the second context. Note that the data warehouse is the same for both
contexts. Since this is a duplicate of the GLOBAL context, the logical schema will be mapped to the
initial source, simply remap the Oracle and File logical schemas to the secondary source’s physical
schemas.

OLTP logical schema mapped to second instance’s physical schema:

Data Warehouse logical schema mapped to the same physical schema:

Generate Load Plan

Load Plans are generated as normal using the BIACM UI. We generate a separate Domain-Only and
combined SDE/SIL/PLP load plan for each source.

In the BIACM UI, generate an SDE/SIL/PLP Load Plan using the instance you registered. When complete,
generate a Domain-Only Load Plan for this source.

Important: You should not generate separate SDE-only load plans for each source with the expectation
of running the SDE-only load plans serially followed by an SIL/PLP load plan. Table maintenance steps
are executed within the individual load plans and are not cross load plan aware. Truncates will continue
to be executed within each load plan – the SDE-only load plan that runs last will truncate the data from
the previous load plan and this data is lost before the SIL/PLP load plan runs.
Edit the existing datasource you have registered in the BIACM UI, changing the name and Datasource
Num Id of the source to match the secondary source:

As you are updating the existing datasource and not adding a new one, you will see just the single
instance of your datasource as below:
This will update the ODI logical and physical schemas mapped in the GLOBAL context. Using the
example, verify that the EBS11510_311 and FILE_EBS11510_311 physical schemas as well as the
DS_EBS11510 and DS_EBS11510_SRCFILE logical schemas are updated to reflect 312 as the Datasource
Num Id. The physical schemas must Datasource Num Id value must match the secondary source for the
load plan to be generated – once generated, we set the value back to the original value.

If the DATASOURCE_NUM_ID flexfield does not match the secondary datasource in any of these cases,
manually set the value to match.

In ODI Studio, navigate to Topology ->

Physical Architecture –> Technologies

File -> FILE_EBS11510_311 Data Server -> Double click FILE_EBS11510_311 physical schema to open ->
Flexfields – DATASOURCE_NUM_ID should reflect the value for the secondary source (ie 312)

Oracle -> EBS11510_311 Data Server -> Double click EBS11510_311 physical schema to open ->
Flexfields – DATASOURCE_NUM_ID should reflect the value for the secondary source (ie 312)

Logical Architecture -> Technologies

File – Double click DS_EBS11510_SRCFILE logical schema to open -> Flexfields -> DATASOURCE_NUM_ID
should reflect the value for the secondary source (ie 312)

Oracle – Double click DS_EBS11510 logical schema to open -> Flexfields -> DATASOURCE_NUM_ID
should reflect the value for the secondary source (ie 312)

Generate another SDE/SIL/PLP Load Plan and Domain-Only Load Plan using this updated source.
When done, we have the following load plans:

Set the datasource registered in BIACM to reflect the name and datasource num Id originally registered
(ie back to 311 using our example) – this will update the logical and physical schemas mapped to the
GLOBAL context in ODI back to the initial value.

When generating a load plan, the Load Plan Generator takes the value of the DATASOURCE_NUM_ID
flexfield of the logical and physical schemas that are mapped to the GLOBAL schema and passes this as a
value that overrides the DATASOURCE_NUM_ID variable in the load plan. This is why we change the
value for the single datasource we have registered.

To verify the Datasource Num Id was correctly applied, follow these steps:

Click a load plan in the BIACM UI, this will drill into the ODI Web Console (you may be prompted to log
into the console)
Scroll down to any step that follows the naming convention <Product Line Code> - DSN <nnn>

Steps have variables that are associated with them. In this case, we are interested in the
BIAPPS.DATASOURCE_NUM_ID variable – it should be overwritten with a value assigned that
corresponds to our datasource. This value is inherited by all child steps under this step.
Repeat the same steps for the load plan associated with the other datasource and you should see its
value set for the BIAPPS.DATASOURCE_NUM_ID variable.

Execute the Load Plan for each Instance

Prior to executing a Load Plan, verify the Data Source Number corresponds to the Load Plan you are
about to execute. If not, update the Data Source Number of the source in BIACM. BIACM auto-
generates the domain member mappings based on the currently registered source. If the Load Plan
executes while the source is configured with another Data Source Number in BIACM, the domain
member mappings will not resolve correctly. Refer to the section 'Generate Load Plan’ for more details
on how to edit the existing datasource you have registered in the BIACM.

When you execute the load plan, provide the appropriate context. Do not use the GLOBAL context –
rather, use the instance specific context.
IMPORTANT: Be careful not to use the wrong context. For example, if executing the load plan
generated for the North American instance (datasource num id 311), do not use the context created for
the European instance (datasource num id 312). Data would be extracted from the European source but
stamped with the North American datasource num id value.

Supporting DEV, TEST, PROD instances

You may have a requirement that the same ODI repository be used to support multiple source and
target types – you may have instances used for testing, other instances used for development and other
instances used for production for example.

Physical Topology
Create separate DEV, TEST and PROD physical schemas for each source and target instance to be
supported. Remember to do the same with the flat file physical schemas. In the following example, we
are supporting three data warehouse databases (DEV, TEST and PROD). We have separate DEV, TEST
and PROD databases for the two EBS 11510 instances we are supporting.
Contexts
In each context, map the environment specific physical schemas to the appropriate logical schemas.

Generate and execute load plans as described in the previous steps using these contexts.

Customization
The published customization methodology has the user create separate ‘Custom’ SDE and SIL adaptor
folders. The tasks to be customized are copied to these adaptor folders, scenarios generated and the
load plan components use these new scenarios rather than the out-of-the-box scenarios. This
methodology is extended as follows to support multiple instances.

Instances Share same customizations

It is possible that the multiple instances require the exact same customizations. In this case, introduce a
single custom SDE and a single custom SIL adaptor and perform the customizations as normal.

Instances Require Different customizations

In this case, the instances will have some differing customizations. They may be able to leverage several
customizations but some are distinct to the instances – for example, the instances may be able to reuse
80% of customizations but each instance requires the remaining 20% of customizations to be instance
specific.

In this case, create a Custom SDE adaptor folder for each instance but a single custom SIL adaptor folder.
To keep track of which datasource a custom SDE adaptor folder is associated with, use the Datasource
Num Id as a suffix in the folder name. To support the examples used in this document, we would create
the following:

Copy the SDE tasks to be customized to the new SDE adaptor folder that corresponds to your initial
datasource you originally registered. Duplicate the tasks as shortcuts and copy the shortcuts to the
other custom SDE adaptor(s). For those tasks where customizations are not reused, materialize those
tasks. Apply all customizations as normal to the interfaces and packages.

An important note is that all interfaces use the same model. If there are differences in the tables in the
different source systems, the model in ODI must be a superset that combines all differences so that
everything is available to the separate interfaces. If the North American instance has column A and the
European instance has column B, the datastore in ODI must have both columns A and B.

ODI requires that scenario names be unique. We ensure the scenarios have names that reflect the
datasource they are associated with by including the Datasource Num Id as a suffix in the adaptor folder.
Scenario names reflect the adaptor folder and therefore remain unique.

A load plan is generated for each instance. Follow the same steps as discussed previously to generate
several SDE-SIL load plans. You must update the load plan steps in the generated load plan to point to
the custom scenarios – do not edit the load plan steps in the out-of-the-box load plan components, only
edit the load plan steps in the generated load plans.
Follow the documented steps for implementing customizations with the following changes.

Perform the following steps:

1. Prior to generating scenarios, ensure the ‘Scenario Naming Convention’ User Parameter has a
value of %FOLDER_NAME(2)%_%OBJECT_NAME%

Steps

 In the Menu, select ODI – User Parameters

 Locate the ‘Scenario Naming Convention’ parameter
 Set the value to %FOLDER_NAME(2)%_%OBJECT_NAME% and save

2. Generate scenarios for new Adaptor(s). Use the ‘materialize’ option. Scenarios will be
generated reflecting the custom adaptor name.

Steps

 Right Click Package in the customized task folder

 Select ‘Generate Scenario…’
 Name of scenario should automatically be in the form ‘Adaptor Folder_Task Folder’
 Check the ‘Generate scenario as if all underlying objects are materialized’ option
 Click OK
 When prompted for Startup Parameters, select the ‘Use All’ option
 Click OK

3. Generate Load Plan as normal.

4. Update the Load Plan Steps in the generated Load Plan to reference the custom scenario.

Steps

 In ODI Studio, navigate to the Designer tab -> ‘Load Plans and Scenarios’ ->
Generated Load Plans
 Double click the load plan you generated
 Go to the ‘Steps’ subtab
 Expand all branches by clicking the ++ button near the top right
 Locate the load plan step that executes your scenario (load plan steps match
the task name) and select it with the mouse
 If the Property Inspector is not visible, select ‘View -> ‘Property Inspector’ from
the menu
 In the Property Inspector window, you should see ‘Step Properties’. One of the
properties is ‘Scenario’. Click the ‘…’ button
 Change the Scenario Name property to match the custom scenario you
generated. Leave the ‘Version’ property as -1 (you could click the magnifying
glass button to search for your scenario but this can take a while – it is always
faster to just type the name of the scenario).