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