Professional Documents
Culture Documents
com -
The multiple organization support feature uses native database features to build a security layer on top of a single
installation of Oracle Applications. This layer of security provides the necessary data partitioning; while at the same time
minimizes the number of potentially destabilizing changes to the application code itself. The security layer is provided using
database views, which allow access to the partitioned data without any changes to the applications code.
For ERP applications, data partitioning is performed by database views. These views reside in the APPS Oracle schema and
derive the appropriate operating unit context from an RDBMS variable.
All applications code is run against the APPS schema. The Applications database architecture is now the same for a Multiple
Organizations and non-Multiple Organizations implementation.
Multiple Organizations in Oracle Applications is enabled by partitioning some database tables by operating unit. Other
tables are shared across operating units (and thus across sets of books).
In general, the following criteria determine if a table would be partitioned:
The table contains a GL Account Code (code combination ID).
There is a business reason for the table to be partitioned (for example, the entity should not be shared).
The table contains transaction data.
The table is an interface table where data being loaded is partitioned.
RDBMS Variable
A global variable exists in the Oracle database called CLIENT_INFO, which is 64 bytes long. The first 10 bytes are used to
store the operating unit ID (or ORG_ID) for the Multiple Organization Support feature. The CLIENT_INFO context is derived
from a profile option that the user sets for each responsibility as part of the Multi-Org setup steps.
2006-2007:OracleApps Epicenter