R12 - MOAC

Definition:

Multi-org or Multiple Organization Access Control (MOAC) is basically the ability to access multiple operating units from a single application responsibility.

In Release 11i, to enter or process data for multiple operating units, one had to switch between different responsibilities because each responsibility could only access one operating unit.

This has been addressed in R12 using the MOAC architecture which is implemented using the RLS (Row Level Security)

Benefits:

• Multi-Org Access Control feature allows you to enter process data and generate reports from a single responsibility. This is achieved by providing the Operating Unit field on the forms/pages and while running the concurrent processes
• User can default the Operating Unit on forms/pages by setting the MO: Default Operating Unit profile
• Enhanced multi-org reporting and processing

Multi –Org implementation

11.5.x

Base tables (ending with ‘_ALL’) contain data for all operating unit, with a column org_id indicating the operating unit to which the data belongs.

Access to data was restricted using the views which would retrieve only the data related to a specific operating unit using the client context information set for the session, based on the ‘MO: Operating unit’ profile value while logging.

This restricted access to the data related to a particular operating unit and org context has to be changed, to process the data related to a different operating units which is done while switching the responsibility.

R12

Multi-Org Access Control Architecture is implemented, which enables users to access data for more than one operating unit within the same responsibility.

Multi-Org views in 11.5.x are now replaced with synonyms and the data restriction is achieved by assigning Virtual Private Database (VPD) policies to the synonym.

The VPD policy allows the system to dynamically generate restrictive conditions when queries are executed against the synonym.

The VPD policy is associated with a function, which can return additional restrictions on the objects to restrict the data returned.

VPD policy that is used in R12 for the MOAC is as follows:

Policy Name: ORG_SEC

Policy Group: SYS_DEFAULT

Package: MO_GLOBAL

Function: ORG_SECURITY.

Required Setups:

<![if !supportLists]>·         <![endif]>Create a security profile

<![if !supportLists]>o    <![endif]>Create security profile

<![if !supportLists]>o    <![endif]>Assign operating units to the profile.

<![if !supportLists]>·         <![endif]>Setting the profile option at the required level i.e., either at User or Responsibility level.

<![if !supportLists]>o    <![endif]>Assigning the security profile option.

<![if !supportLists]>o    <![endif]>Assigning the Default operating unit (optional).

Interesting to Developers and Testers

During the development work involving 11.5.x multi-org views, org context or apps initialization is to be done to enable the views to retrieve the data.

For backward compatibility in R12, the above approach is still supported, if the “MO: Set Client_Info for Debugging” (FND_MO_INIT_CI_DEBUG) is set to ‘YES’.

If the benefits of MOAC are to be used, then the org context can be set using the following procedures available in MO_GLOBAL package.

<![if !supportLists]>1.       <![endif]>SET_POLICY_CONTEXT

<![if !supportLists]>2.       <![endif]>SET_ORG_ACCESS

Note: Implementing MOAC is not mandatory and may and may not be implemented based on the client’s requirements.