Multi Organizations Access Control (MOAC)

Filed under Enterprise Resource Planning written by Jade Global on August 14,
2013 No Comments
The new feature in R12 enables companies wanting to implement a shared services
operating model to efficiently process business transactions by allowing them to access,
process and report on data for an unlimited number of operating units within a single
applications responsibility.
With MOAC, users can:
Perform multiple tasks across Operating Units without changing responsibilities such as
invoice entry, order processing, bank payments etc. thus improving the efficiency of
transactions for companies that have centralized business functions or operate Shared
Service Centers
Obtain better information for decision making such as, accessing supplier and customer
site levels details across multiple OUs
Speed up data entry
Reduce setup and maintenance of many responsibilities
How MOAC works technically:
MOAC is initialized when you open a Form, Oracle EBS page or a Report or submit the
concurrent program. The first MOAC call checks if the profile MO: Security Profile has a
value. If Yes, then the list of operating units to which access is allowed is fetched and the
list of values (LOV) is populated .This list of values is nothing but list of OUs associated with
the Security Profile attached to MO: Security Profile. Security profiles are defined with the
help of the HR responsibility. Then, default value of the LOV is set to the operating unit
specified in MO: Default Operating Unit.
When the profile MO: Security Profile does not have a value, MOAC switches to the 11i
single organization mode. As in 11i, the profile MO: Operating Unit is checked and the
operating unit is initialized to the one defined in it.
The important point to note here is that the profile MO: Operating Unit is ignored when the
profile MO: Security Profile is set.
MOAC setups:
Following are the basic steps to be performed in order to enable MOAC feature:
1. Define Security Profiles (using form function Define Global Security Profile)
Enter a unique name for the security profile.
To restrict access by discrete list of organizations, select Secure organizations
by organization hierarchy and/or organization list for the Security Type.
Check the Exclude Business Group check box to remove the business group in
the list of organizations.
Use the Classification field to limit the list of values (LOV) in the Organization
Name field. For example, if you select the classification to Operating Unit, only
operating units will display in the LOV.

In the organization name field, select the Operating Unit for which you want
access.

Repeat until you have included all organizations to which you need access.
2. Run the concurrent program Security List Maintenance Program from the standard
request submission form. The Security List Maintenance Program can be run for a
single named security profile to prevent impact to other security profiles.
3. Assign appropriate security to the profile option MO: Security Profile for your users and
responsibilities
Navigate to the System Administrator responsibility > System Profile Options
Assign the security profiles to MO: Security Profile for your responsibilities and/or
users.

4. Assign a value for profile option MO: Default Operating Unit (Optional)
Navigate to System Administrator Responsibility > System Profile Options
Assign a default operating unit to MO: Default Operating Unit profile option for your
responsibilities and/or user.
5. Assign MO: Operating Unit (Mandatory for only Single Org or if MO: Security Profile is
not defined)
Navigate to System Administrator Responsibility > System Profile Options
Assign the Operating unit to MO: Operating Unit profile option for your responsibility
or user.
Note From the above screen shots we can conclude that user with purchasing
responsibility will be able to access data from two Operating Units Vision Operations and
Vision Services.
Developers Insight:
To increase the flexibility and performance in a multiple organizations environment and
provide the same level of data security, the DBMS Virtual Private Database (VPD) feature
replaces the CLIENT_INFO function.
The Virtual Private Database (VPD) feature allows developers to enforce security by
attaching a security policy to database objects such as tables, views and synonyms. It
attaches a predicate function to every SQL statement to the objects by applying security
policies. When a user directly or indirectly accesses the secure objects, the database

rewrites the users SQL statement to include conditions set by security policy that are visible
to the user.
MOAC Changes to Custom Code while upgrading to R12 from 11i-During R12 upgrade
the major task is to enable the MOAC feature to custom code. Following is the
recommended approach to achieve MOAC implemented in real aspect to custom code:
1. Multiple Organizations Views/Tables Changes Single Organization View
Drop the single organization view
Create a synonym with the same name as the obsolete single organization view
Attach a policy function to the synonym
Reference Views
Add the ORG_ID column if it does not exist
Replace single organization views with _ALL tables for all except one, which
must be a secured synonym
Include the ORG_ID filter in the where clause of the view to avoid the cartesian
product, if the ORG_ID is the driving key or part of the composite key
Include the ORG_ID parameter in the columns based on functions, if necessary
2. Enhancements to Forms The multiple organizations setup and transaction forms
must display the Operating Unit field. This allows users to select the operating unit
and enter the setup or transaction for the operating unit. Oracle recommends
deriving the operating units from the transaction attributes.
1. Enhancements to Reports and Concurrent Programs
You must remove references of CLIENT_INFO and NVL function to the ORG_ID
column in the reports.
Single Organization ReportsThe operating unit mode for single organization
reports are flagged as SINGLE in the Define Concurrent Programs page.
Cross Organization ReportsThe Operating Unit mode for cross organization reports
are flagged as MULTIPLE in the Define Concurrent Programs page.
2. Enhancements to Public APIs
Do not use the multiple organizations temporary table directly in the SQL query.
Rewrite the SQL joins with two or more views to use just one secured synonym
depending on the driving table for the query and replace the remaining views by
_ALL tables.
Add the ORG_ID to the WHERE clause of the SQL to avoid cartesian joins for tables
that include ORG_ID the composite or driving key.
Use MO_GLOBAL.Set_Policy_Context.
This API has 2 parameters 1. Operating unit 2. Context
Context has 2 values 1. M 2. S
When policy context is set to M, data from all accessible Operating Units will be
returned.
When policy context is set to S, then only data from the specified Org_Id will be
returned.
Products must call the MO_GLOBAL.init() API to execute the multiple organizations
initialization.
3. Enhancements to Workflows
With multiple organizations access control, you must set the current organization ID and
not the CLIENT_INFO org context. You must derive the current organization ID from

item keys. Do not rely on MO: Security Profile, MO: Default Operating Unit, and MO:
Operating Unit profile options when setting the organization context because the
operating unit must be validated before initiating the workflow.