Professional Documents
Culture Documents
(http://www.jadeglobal.com/blog/)
Subscribe
Enter your email address to subscribe
this blog and receive notifications of ne
posts by email.
Work Email*
Submit
Categories
Select Category
Multi Organizations Access Control (MOAC)
December 14, 2013 By: Jade Global (http://www.jadeglobal.com)
Archives
Select Month
0!
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
Connect With Us
operating units within a single applications’ responsibility.
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.
http://www.jadeglobal.com/blog/multi-organizations-access-control-moac/ Page 1 of 4
Multi Organizations Access Control (MOAC) 10/6/18, 10(52 AM
(http://www.jadeglobal.com/blog/wp-
content/uploads/2013/08/img_1.png)
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.
(http://www.jadeglobal.com/blog/wp-
content/uploads/2013/08/img_2.png)
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.
Developer’s 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 user’s 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:
http://www.jadeglobal.com/blog/multi-organizations-access-control-moac/ Page 2 of 4
Multi Organizations Access Control (MOAC) 10/6/18, 10(52 AM
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.
Related Posts:
(http://www.jadeglobal.com/blog/oracle-r12-upgrade-challenges/)
Semiconductor Industry IT
Constraints
(http://www.jadeglobal.com/blog/semiconductor-industry-it-constraints/)
http://www.jadeglobal.com/blog/multi-organizations-access-control-moac/ Page 3 of 4
Multi Organizations Access Control (MOAC) 10/6/18, 10(52 AM
Related articles
http://www.jadeglobal.com/blog/multi-organizations-access-control-moac/ Page 4 of 4