Multi - Org Setup

Multi - Org Setup, www.askhareesh.com
Multi-Org is a server-side (applications and database) enhancement that enables multiple business units in an enterprise to use a single installation of Oracle Applications products while keeping transaction data separate and secure. The Multi-Org enhancement uses native database views to build a security layer on top of a single installation of Oracle Applications. In Oracle Applications Release 11i,

Basic Business Needs:

The Multi-Org enhancement to Oracle Applications provides features necessary to satisfy the following basic business needs. You should be able to:

• Use a single installation of any Oracle Applications product to support any number of business units, even if those business units use different sets of books.
• Support any number of business units within a single installation of Oracle Applications.
• Secure access to data so that users can access only information that is relevant to them.
• Procure products from an operating unit that uses one set of book, but receive them from another operating unit using a different set of books.
• Sell products from an operating unit that uses one set of books, but ship them from another operating unit using a different set of books, automatically recording the appropriate inter-company sales by posting inter-company accounts payable and accounts receivable invoices.
• Report at any level of the organizational structure

Oracle Apps R12 MOAC and its impact

Oracle Apps R12 MOAC and its impact, AskHareesh Blogspot

Setup the Security Profile: 


1) Create a Security Profile in HRMS Responsibility
HRMS Manager>Security>Profile
 In this setup specify different Operating Units that you want to Access.

2) Run the Security List Maintenance
This is a required step when you create a new Profile or modify existing one.

3) Setup the MO: Security Profile value to above created security profile.
This "MO: Security Profile" Profile option has to be setup at the responsibility level.This will ensure that responsibility will have access to the data of all the Operating units under the Security Profile.

Important profile option

MO: Security Profile:

MO: Operating Unit:
This comes from 11i and is still valid only its evaluated, if there is no value setup at MO:Security
Profile.

MO: Default Operating Unit
If the security profile is setup to access multiple operating units, this requires users to select
the Operating Unit every time user access the Sub ledger pages. To avoid this the Default Operating Unit profile can be setup.

How MOAC impacts the way we work in TOAD

11i


To set the Org id in TOAD
Get the Org_id from HR_ORGANIZATION_UNITS

In toad execute the below code
        begin
        fnd_client_info.set_org_context(&org_id);
        end;



To set the responsibility context in TOAD
Get the User id, Responsibility Id and Application id from Front end
Help>Diagnostic>Examine and select BLOCK as "$PROFILES$" and then get the respective IDS

Using the IDs execute the below code in TOAD
      begin
      FND_GLOBAL.APPS_INITIALIZE(user_id in number,resp_id in number,resp_appl_id in
      number);
      end;


R12:

To set the Org id in TOAD
Get the Org_id from HR_ORGANIZATION_UNITS

In toad execute the below code
    --Sets the 201 as single Org id
    exec MO_GLOBAL.SET_POLICY_CONTEXT('S',201);
    Pass a value "S" in case you want your current session to work against Single ORG_ID
    Pass a value of "M" in case you want your current session to work against multiple ORG_ID's

To set the responsibility context and initiate MOAC in TOAD


Get the User id, Responsibility Id and Application id from Front end
Help>Diagnostic>Examine and select BLOCK as "$PROFILES$" and then get the respective IDS

Using the IDs execute the below code in TOAD

exec  FND_GLOBAL.INITIALIZE
This will set your responsibility id, user_id etc

call MO_GLOBAL.INIT('AR')
This will read the MO profile option values for your responsibility/user, and will initialize the Multi Org Access.
   

MOAC for table access


In 11i _ALL Tables where non Org specific and Org specific views were created on these tables.
But in R12 its different concept

  a. For the table AP_INVOICES_ALL a synonym  AP_INVOICES_ALL is created in APPS.

  b. Also another synonym AP_INVOICES is created which refers to AP_INOICES_ALL.

  c. A Row Level security is applied to AP_INVOICES, using package function
      MO_GLOBAL.ORG_SECURITY.
     This can be double-checked by running SQL select * from all_policies where
      object_name='AP_INVOICES'

e. The effect of this policy is that,whenever you access AP_INVOICES, Oracle RLS will
    dynamically append WHERE CLAUSE similar to below

    SELECT * FROM AP_INVOICES
    WHERE EXISTS (SELECT 1 FROM mo_glob_org_access_tmp oa WHERE oa.organization_id =
     org_id)


Multi-Org Architecture

Multi-Org Architecture in Release 12, www.askhareesh.com
Multi-Org Architecture before to Release 12
  • Oracle has come up with a column ORG_ID to accommodate data of different operating units in one table,. For example PO_REQUISITION_HEADERS_ALL.org_id is column which stores operating unit ID.
  • Whereas the table PO_REQUISITION_HEADERS_ALL is stored in PO Schema and a VIEW PO_HEADERS is present in APPS Schema which return rows corresponded to the current operating unit’s organization ID only.
  • A view in the APPS schema provides the Multi-Org filtering based on the statement below in the where clause. SUBSTRB(USERENV ('CLIENT_INFO'), 1, 10)
  • When logging into the applications, the CLIENT_INFO value was set to the appropriate operating unit organization ID for the session based on the profile option setting for “MO: Operating Unit”.
  • In SQL*Plus, CLIENT_INFO could be set to point to a particular operating unit using EXECUTE dbms_application_info.set_client_info('');
Multi-Org Architecture in Release 12

Users allowed defining security profiles through this architecture, so users may access data for more than one operating unit within a single responsibility.

To accomplish this
  1. Multi-org views have been removed, and replaced with synonyms. For example, PO_HEADERS would no longer be a VIEW defined on PO_REQUISITION_HEADERS_ALL, but rather a synonym which points to PO_REQUISITION_HEADERS_ALL
  2. The data restriction is accomplished by assigning a virtual private database (VPD) policy also known as Row Level Security (RLS)  to the synonym. This policy allows the system to dynamically generate restricting conditions when queries are run against the synonym.
  3. A Row Level security is applied to PO_REQUISITION_HEADERS, using package function MO_GLOBAL.ORG_SECURITY. Below query will help you to find out the security policy applied on PO_HEADERS.
  4. SELECT * FROM dba_policies WHERE object_name LIKE 'PO_REQUISITION_HEADERS';
  5. With effect of this security policy, whenever you access PO_REQUISITION_HEADERS, Oracle RLS will dynamically append WHERE CLAUSE similar to below
SELECT *
FROM PO_REQUISITION_HEADERS
WHERE EXISTS
(SELECT 1 FROM mo_glob_org_access_tmp oa WHERE oa.organization_id = org_id)

MO_GLOB_ORG_ACCESS_TMP:
MO_GLOB_ORG_ACCESS_TMP is a global temporary table. The current session is able see data that it placed in the table but other sessions cannot. Data in the table is temporary. It has a data duration of SYS$SESSION. Data is removed at the end of this period.

More about ‘MO_GLOBAL.ORG_SECURITY’
The purpose of Row-Level-Security is to hide certain data [based on some conditions]. RLS does so by appending a where clause to the secured object.
  • MO_GLOBAL.ORG_SECURITY is a function that returns a predicate for the WHERE CLAUSE
  • The where clause will be appended to Table/Synonym/View for which Multi Org Row Level security is enabled
How to set Org Context in R12?
BEGIN
  EXECUTE mo_global.set_policy_context('S',&org_id);
END;
--'S' means Single Org Context.
Where option ‘S’ is used to fetch records from specified org_id and
option ‘M’ is used to fetch records from all accessible Operating Units.

Also read : Multi-Org Setup