Multiple Organizations (Multi-Org) Architecture

1. What is Multiple Organizations (Multi-Org) architecture?

Multi-Org feature uses database views to partition data. The security is embedded in the view layer, which allows access to the partitioned data without any changes to the applications code.

The Multi-Org views reside in the APPS schema, which has access to the complete E-Business Suite data model, and contains synonyms to all tables and sequences, stored procedures, views, and database triggers. All applications code runs against the APPS schema. The Multi-Org views are based on the Multi-Org tables that are partitioned by Operating Unit (ORG_ID). These tables reside in the product schema (for example, AP).

A Multi-Org table is named with _ALL suffix. In the APPS schema, the corresponding Multi-Org view is created with the same table name without the _ALL suffix. For example, AP schema has a Multi-Org table named AP_INVOICES_ALL; the APPS schema has a corresponding synonym named AP_INVOICES_ALL, which can be used to access all the data. The view AP_INVOICES exists in the APPS schema to access the partitioned data by Operating Unit.

The Multi-Org views derive the Operating Unit context from a global database variable “CLIENT_INFO” included in the view definition.

2. How do you set the CLIENT_INFO variable?

The CLIENT_INFO variable is a global database variable that has been introduced in Release 10.7 to hold the ORG_ID value and other information. It is 64 bytes long. The first 10 bytes are used to store the ORG_ID value.

Upon session initialization, AOL initialization (FND_GLOBAL.initialize) populates the org context in the CLIENT_INFO global database variable, with the value from the profile option "MO: Operating Unit". The org context in the CLIENT_INFO variable is set only if you have enabled Multi-Org in your database. This can be verified by looking at the MULTI_ORG_FLAG in FND_PRODUCT_GROUPS table. The MULTI_ORG_FLAG is 'N' or NULL in a non Multi-Org database and ‘Y’ in a Multi-Org database.

Even though the ORG_ID column in the database tables allows a maximum of 15 digits, only 10 digits are used for the org context in the CLIENT_INFO variable. If you specify more than 10 digits for the ORG_ID in the profile option "MO: Operating Unit", you will get an error when your session is initialized. The API FND_CLIENT_INFO.set_org_context, which sets the org context in the CLIENT_INFO variable, raises the error. Additional information is available in Metalink Note 233987.1.

3. Why is the ORG_ID value in CLIENT_INFO variable different from SQL*Plus vs. from Applications?

You may not be initializing your session in SQL*Plus in the same way as in Applications.

When you access a form from Applications, the FND_GLOBAL.initialize() API sets the org context in the CLIENT_INFO variable. This API accepts the user_id, responsibility_id, and resp_appl_id for the session as input parameters, and performs the following activities:

• Reads the profiles, and caches the values

• Sets the org context, and the MRC context in the CLIENT_INFO variable • Sets the Security Group context • Executes product specific, and custom initialization

To mimic the behavior you observe in Applications to SQL*Plus, you need to execute the FND_GLOBAL.apps_initialize() API, and pass user_id, responsibility_id and resp_appl_id as parameters. You can retrieve these values from Applications, by executing the following steps:

• Logging in, and choosing the Responsibility that you are interested in • From the menu, navigating to Help -> Examine • Getting the session values for user_id, responsibility_id and resp_appl_id

FND_GLOBAL.apps_initialize() API in turn calls FND_GLOBAL.initialize() API as in Applications.

In SQL*Plus, it is not recommended to directly call APIs that set the CLIENT_INFO org context, e.g. fnd_client_info.setup_client_info(), or dbms_application_info.set_client_info(). These APIs initialize only the org context, which is insufficient because of an upcoming feature of E-Business Suite, which will require a temporary table to be populated with one or multiple Operating Units.

4. How do Multi-Org views secure the data?

The Multi-Org views secure data based on the Operating Unit associated with a Responsibility.

The Multi-Org views filter data, based on the value of the org context in the CLIENT_INFO variable. A sample Multi-Org view is as given below:

SELECT * FROM <table name>_ALL WHERE NVL(ORG_ID,NVL(TO_NUMBER(DECODE(SUBSTRB(USERENV(‘CLIENT_INFO’),1,1),‘ ‘, NULL, SUBSTRB(USERENV(‘CLIENT_INFO’),1,10))),–99)) =NVL(TO_NUMBER(DECODE(SUBSTRB(USERENV(‘CLIENT_INFO’),1,1),‘ ‘,NULL,SUBSTRB(USERENV(‘CLIENT_INFO’),1,10))),–99)

If you have not enabled Multi-Org in your database, the CLIENT_INFO org context is not set. In such case, the views return only the rows that have NULL value for ORG_ID column.

5. Can you use –99 for ORG_ID value in a Multi-Org table?

The Multi-Org views include a CLIENT_INFO predicate that filters data based on the org context in the CLIENT_INFO variable, or based on NULL ORG_ID. The ORG_ID value can be a positive integer or can be NULL. Any other value will not be retrieved by the views. Global data is stored with NULL ORG_ID value.

To make data globally available, you must not stamp your transaction with a negative integer, e.g. –99, for ORG_ID value. If you have a business need for global data, then that data should not belong in a Multi-Org table in the first place. Alternatively, you can have the data made available to every Operating Unit.

6. How is the ORG_ID value stored in the Multi-Org tables?

If you provide an ORG_ID value when you perform an insert, that ORG_ID value is stored.

If you do not provide an ORG_ID, the database uses the default value, which is the org context stored in the first 10 bytes of the CLIENT_INFO global database variable.

7. How do you convert a global table into a Multi-Org table?

To convert a global table into a Multi-Org table, execute the following steps:

• Rename the table to add _ALL suffix • Add ORG_ID column to the table • Include RDBMS default value for ORG_ID column to use the CLIENT_INFO predicate if value

not specified • If the table contains seed data that is replicated to every Operating Unit, include ORG_ID as

part of the composite unique index • Inform AD to add the Multi-Org table in the AD_MORG package.

This package lists all Multi-Org tables, and whether the tables contain seed data to be replicated.

8. How do you convert a Multi-Org table into a global table?

To convert a Multi-Org table into a global table, execute the following steps:

• Drop the Multi-Org view • Rename the table to remove _ALL suffix.

This should be done after all objects that reference the table have been updated to reflect the name change.

• If ORG_ID column was part of the composite unique index, first upgrade the data in the table to unique values without including the ORG_ID value, then drop ORG_ID column.

The recommendation is to set the ORG_ID column to UNUSED in the current release, and to drop the column in the subsequent major release of the E-Business Suite.

• Inform AD to remove the table from the list of Multi-Org tables in the AD_MORG package

9. What is the purpose of MO_GLOB_ORG_ACCESS_TMP table?

To prepare for an upcoming feature of the E-Business Suite, a session specific global temporary table has been introduced for Multi-Org.

The MO_GLOB_ORG_ACCESS_TMP table is used to store the list of Operating Units to which a Responsibility has access.

Today the Multi-Org views are secured by the CLIENT_INFO predicate, giving user access to one Operating Unit at a time. In the future, those views will be replaced by synonyms with the Multi-Org security policy attached. The table is populated by the Multi-Org initialization code upon session initialization and is used in the Multi-Org security policy function to control data secured by Operating Unit.

10. Why do you see increased temporary tablespace resource usage after applying 11.5.8

Maintenance Patch?

For an upcoming feature of E-Business Suite, a Multi-Org temporary table, MO_GLOB_ORG_ACCESS_TMP, is populated on session initialization with one or more Operating Units for all products that have an integration point with Multi-Org. This results in increased temporary tablespace resource consumption.

Solution to the problem has been provided through patch 2816177, which is available for download from Metalink. The temporary table is now populated for only the products that have made code changes to uptake the upcoming feature of the E-Business Suite, therefore significantly reducing the tablespace resource consumption of every user who logs on the system.

Profile Options

11. Why is the Responsibility level value for the profile option "MO: Operating Unit" not retrieved when you access Applications?

Recent changes to Profiles Hierarchy feature have introduced this problem. Solution to the problem has been provided through patch 2822998.

Irrespective of the "MO: Operating Unit" profile option at the Responsibility level, only the Site level value was cached. This has been causing “No Data Found” error in many forms.

12. Can you set “MO: Operating Unit” profile option in a non Multi-Org database?

In a non Multi-Org instance, the profile option “MO: Operating Unit” is ignored and the org context in the CLIENT_INFO variable is not set.

It does not matter whether you have set up one or more Operating Units in the system. The org context in the CLIENT_INFO variable is set only if the MULTI_ORG_FLAG is set to ‘Y’ in the FND_PRODUCT_GROUPS table. The MULTI_ORG_FLAG is 'N' or NULL in a non Multi-Org database.

13. What is the purpose of the "MO: Security Profile" profile option?

Currently, CRM Foundation (JTF) product uses the profile option "MO: Security Profile" to control data secured by Operating Unit for inquiry only. Several other products will also use this profile option, because of an upcoming feature of the E-Business Suite.

If you use JTF Territories, you may optionally set this profile option at Responsibility level. Otherwise, do not set this profile at any level. Additional information is available in Metalink Note: 211431.1.

14. What is the purpose of "MO: Default Operating Unit" profile option?

The "MO: Default Operating Unit" profile option is reserved for an upcoming feature of the E-Business Suite. You should not set this profile option at any level.

Additional information is available in Metalink Note: 211431.1.

15. What is the purpose of the profile option "MO: Distributed Environment"?

The profile option "MO: Distributed Environment" is introduced to handle Multi-Org initialization in a

distributed environment. Multi-Org initialization uses autonomous transaction, which is supported in a distributed environment from Release 9iR2.

Users who are using distributed transactions in a Multi-Org environment, with a prior version of the database, should set this profile option to 'Yes' at Site, Responsibility, or User level, to indicate that autonomous commit should not be used in the Multi-Org initialization.

Additional information is available in Metalink Note: 228329.1.

Session Initialization

16. How do you register Multi-Org Access Control initialization for Custom Products?

To prepare for an upcoming feature of the E-Business Suite, several products of the E-Business Suite have been modified to use the new Multi-Org Initialization code that populates a temporary table.

Those products are registered in the AOL Callout tables to execute Multi-Org initialization on session startup. If the Multi-Org initialization is not executed on forms opening for those products, you will get "No data found" error. As custom products are not registered in this table, you will get the same error.

To execute the Multi-Org Initialization code on session startup for a Responsibility that is associated with a custom product, add the following PL/SQL block to the “Initialization SQL Statement – Custom” profile option at Responsibility, or Application level:

begin mo_global.init; end;

Additional information is available in Metalink Note: 214702.1.

17. Why is the following error raised when you open a form: "You do not have access privilege to any Operating Unit. Please check if your profile option "MO: Security Profile" includes any Operating Unit or the profile option "MO: Operating Unit" is set”?

For an upcoming feature of the E-Business Suite, the Multi-Org initialization is modified to populate a temporary table with the Operating Units specified by the profile option "MO: Security Profile".

The initialization code raises the aforementioned error if the profile option "MO: Security Profile" is set, but does not include any Operating Units. You will also get the error if either "MO: Security Profile" or "MO: Operating Unit" profile option is not set.

Make sure you have applied patch 2820541, which is available for download from Metalink. The solution ignores the “MO: Security Profile” profile option value even if it is set.

Additional Information is available in the Metalink Note 201520.1

18. Why is the following error raised when you run “Refresh Snapshots” process in Oracle Advanced Pricing Module: "ORA-00164: autonomous transaction disallowed"?

This error is raised when the Multi-Org initialization code, which includes autonomous commit, is executed, because autonomous transactions are not supported in a distributed environment prior to

Release 9iR2.

Solution to the problem has been provided through patch 2753304, which is available for download from Metalink. Multi-Org initialization is now modified to support distributed and non distributed environments. You need to set the profile option "MO: Distribute Environment" to ‘Yes’ for the Responsibility you are getting the error.

Additional information is available in Metalink Note: 228329.1.

Public APIs

19. What public APIs are available in the MO_UTILS package?

The following public APIs are available:

• Get_Legal_Entity_Name, which retrieves the Legal Entity Name for a given Operating Unit • Get_Legal_Entity_Info, which retrieves the Legal Entity Id and Legal Entity Name for a given

Operating Unit • Get_Set_Of_Books_Name, which retrieves the Set of Books Name for a given Operating Unit • Get_Set_Of_Books_Info, which retrieves the Set of Books Name and Set of Books Id for a

given Operating Unit • Get_Multi_Org_Flag, which retrieves if the database has been converted to Multi-Org (Y) or

not (N or NULL)

20. What public APIs are available for Cross Organization Reporting feature?

The following public APIs are available in XLA_MO_REPORTING_API package:

• Initialize procedure, which initializes the security context for the current database session • Get_Predicate function, which initializes the lexical parameter(s) P_ORG_WHERE used in the

report query.

You need to pass the table alias to this function, which will generate the appropriate SQL predicate at runtime.

• Validate_Reporting_Level procedure, which validates the reporting level parameter, if you do not use predefined valuesets for validation

• Validate_Reporting_Entity procedure, which validates the reporting entity parameter, if you do not use predefined valuesets for validation

Upgrade

21. What is involved in the “Convert to Multi-Org” process?

The Convert to Multi-Org process upgrades a standard product group into a Multi-Org product group.

You can convert to Multi-Org by running the process available from the Database Objects menu of the ADADMIN utility. You can choose this option only if you do not already have Multi-Org enabled in your database.

The “Convert to Multi-Org” process does the following:

• Populates the ORG_ID column with the Operating Unit value you specified for the profile option: "MO: Operating Unit" at site level.

• Sets the MULTI_ORG_FLAG in the FND_PRODUCT_GROUPS table to “Y”. • Runs the “Replicate Seed Data” program.

If you define more than one Operating Unit, the “Replicate Seed Data” process is run for all Operating Units.

Before running the “Convert to Multi-Org” process, make sure you do the following:

• Apply the AD Patch 2412184: ADADMIN Convert to Multi-Org Performance Improvement: Increase parallelization

• Define at least one Operating Unit, and set the profile option, "MO: Operating Unit" at Site level, to that Operating Unit’s value

After running the “Convert to Multi-Org” process, make sure you apply the following TCA patch as post conversion process:

• Patch 2451368: Migrate data from Customers to Site Uses

22. What is involved in the “Replicate Seed Data” process?

The “Replicate Seed Data” process copies the seed data in the Multi-Org tables.

The program can be run in “single organization” mode or in “all organization” mode. The “single organization” mode applies when the “Replicate Seed Data” process is executed within the context of a particular Operating Unit (or ORG_ID). The “all organization” mode applies when the “Replicate Seed Data” process is executed without any Operating Unit context.

There are two types of seed data: shared and replicated to every Operating Unit. A shared seed data row has an ORG_ID value of -3114. The “Replicate Seed Data” process copies the row, sets ORG_ID value to NULL in the new row, and makes the row available across Operating Units. Seed data that is replicated to every Operating Unit has an ORG_ID value of -3113. The “Replicate Seed Data” process copies the row to every Operating Unit you defined in the system if you run the process in “all organization” mode, or to a particular Operating Unit if you run the process in “single organization” mode.

If your database is not Multi-Org enabled, the “Replicate Seed Data” process copies both types of seed data to new rows with NULL value for ORG_ID column.

23. What enhancements to the “Convert to Multi-Org” process are available?

In Release 10.7, 11 and 11i, the “Convert to Multi-Org” process has been improved to significantly reduce the time needed to convert a non Multi-Org system into a Multi-Org system:

• The improved “Convert to Multi-Org” process for Release 10.7 is available for download from Metalink. The patch number is 2576566. Additional information is available in Metalink Note 220382.1.

It now uses the adpatch infrastructure to launch multiple instances of the conversion script that

execute in parallel. Each instance handles the conversion of one Multi-Org table. The performance gain is dependent on several factors such as the number of CPUs, amount of memory, and the volume of data to be updated.

In addition, the process uses bulk binds to improve the performance of the SELECT and UPDATE statements. Bulk bind is a feature introduced in Oracle 8i that minimizes the number of context switches between the SQL and PL/SQL engines. This results in a significantly reduced overhead. The process detects the version of the database server and only uses bulk binds if it is 8i or greater. Otherwise, it falls back to conventional SELECT and UPDATE statements.

• The improved “Convert to Multi-Org” process for Release 11 is available for download from Metalink. The patch number is 2573222. Additional information is available in Metalink Note 220384.1.

It now uses bulk binds to improve the performance of the SELECT and UPDATE statements. Bulk bind is a feature introduced in Oracle 8i that minimizes the number of context switches between the SQL and PL/SQL engines. This results in a significantly reduced overhead. The program detects the version of the database server and only uses bulk binds if it is 8i or greater. Otherwise, it falls back to conventional SELECT and UPDATE statements.

• The improved “Convert to Multi-Org” process for Release 11i is available for download from Metalink. The patch number is 2412194. Additional information is available in Metalink Note 208267.1.

It now uses AD's parallel update method to increase server's CPU utilization for updates. The performance gain is dependent on several factors such as the number of CPUs, memory, and the volume of data to be updated.

Documentation Library

24. Where can you find more information on Multiple Organizations (Multi-Org)?

The user's guides, "Multiple Organizations in Oracle Applications" for Release 11i, Release 11, and Release 10.7 can be found in the following locations:

• MetaLink or iSupport: Navigate to Top Tech Docs / E-Business Suite: ERP / Applications Core Technology / Multiple Organizations Architecture (Multi-Org) / Manuals and eTRMs / Release 11i, Release 11, or Release 10 / Architecture

Feature information can be found in the following locations:

• MetaLink or iSupport: Navigate to Top Tech Docs / E-Business Suite: ERP / Applications Core Technology / Multiple Organizations Architecture (Multi-Org)

Top of Page

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 USA Worldwide Inquiries: 650.506.7000 Fax: 650.506.7200 http://www.oracle.com Oracle Corporation (Nasdaq: ORCL) is the world's leading supplier of software for information management, and the world's second largest independent software company. With annual revenues of more than $10.1 billion, the company offers its database, tools and application products, along with related consulting, education, and support services, in more than 145 countries around the world.

Features and screen shots shown may not correspond exactly to the released product.

Oracle is a registered trademark of Oracle Corporation.

All other company and product names mentioned are used for identification purposes only and may be trademarks of their respective owners.

Copyright © 2002 Oracle Corporation All Rights Reserved