R12 – MOAC Security

Multiple Organizations Access Control (MOAC) security give the possibility of querying or seeing transactions of one or more Operating Units (OU) without changing responsibility.
In 11i we were securing transactions by Operating Unit (OU) only and we would have to choose a corresponding responsibility to see the transactions:

• OU1 – Receivables Manager
• OU2 – Receivables Manager
• OU3 – Receivables Manager

In R12 it is now possible to have a shared services responsibility like:

• ALL – Receivables Manager

This new kind of security is based on Security Profiles which is a hierarchy of operating units.
So best practice in R12 is now to secure all responsibilities by Security Profile rather than by Operating Unit.
11i non-MOAC setup:

	Site Level	Receivables (Vision)
MO: Default Operating Unit
MO: Operating Unit	Vision Operations	Vision Operations
MO: Security Profile
GL Set of Books Name		Vision Operations

So a global shared service responsibility was not possible in 11i so some companies had very long lists of responsibilities.
Also note in R11i site level setting takes precedence at lower levels so the responsibility level setting in this case is not needed – only if the OU had been different.
R12 MOAC setup:

	Site Level	Receivables (Vision)	Receivables (Global)
MO: Default Operating Unit		Vision Operations	Vision Services
MO: Operating Unit
MO: Security Profile	Vision Global	Vision Operations	Vision Global

Assuming we have a hierarchy like this where OU and security profiles have same names:
> Vision Global
>> Vision US
>>> Vision Operations (OU)
>>> Vision Services (OU)
>> Vision Europe (OU)
We do not need to have a security profile for all branches in the hierarchy above but it is best practice to do so.
So in R12 GL Set of Books Name is gone and you leave MO: Operating Unit empty and leave it to the Security Profile.
Note: MO: Default Operating Unit is not required and can be left empty however I have had several bugs in R12.1.1 and R12.1.2 related to missing default operating unit in IEX so try leaving it empty first and if you get problems put a default value in this and try again.
So Oracle has created MOAC but forgot a few details here and there.
Mixed R11i/R12 MOAC setup:
Some modules in R12 does not yet fully support MOAC so a mixed setup may be needed.
Luckily Oracle changed the MO profile settings inheritance so the site level setting does NOT override at responsibility level as in R11i – well at least this setup worked in R12.1.1.

	Site Level	Receivables (Vision)	Receivables (Global)
MO: Default Operating Unit			Vision Operations
MO: Operating Unit	Vision Operations
MO: Security Profile	Vision Global	Vision Operations	Vision Global

Using the setup above you will get a site level default OU of “Vision Operations” however at responsibility level the security profile takes precedence so Receivables (Global) will be able to see all OU’s within “Vision Global”. In 11i you would have been locked down to “Vision Operations”.

Technical

11i – View Based Security

11i used views to secure transactions in individual schemas:
APPS.AR_PAYMENT_SCHEDULES on AR.AR_PAYMENT_SCHEDULES_ALL
With where clause using CLIENT_INFO set from the responsibility context.
In PL/SQL programs you would set:

• fnd_global.apps_initialize( var_user_id, var_resp_id, var_application_id);

and:

• dbms_application_info.set_client_info(var_organization_id);

R12 – VPD Based Security

R12 uses the Virtual Private Database (VPD) technology for MOAC security.
Synonym APPS.AR_PAYMENT_SCHEDULES on AR.AR_PAYMENT_SCHEDULES_ALL
With a policy attached to synonym APPS.AR_PAYMENT_SCHEDULES.
In PL/SQL program you still need to set:

• fnd_global.apps_initialize( var_user_id, var_resp_id, var_application_id);

and for single OU access:

• mo_global.set_policy_context(‘S’,var_organization_id);

or for multi OU access:

• mo_global.set_policy_context(‘M’,null);

Accessible Organisation Units

In 11i it was easy to see what access you had:

• dbms_application_info.read_client_info(var_organization_id);

Which would return your current org_id however in R12 you need to do the following:

• select organization_id
  from HR_ORGANIZATION_UNITS
  where MO_GLOBAL.CHECK_ACCESS(organization_id)=’Y’
  ;

I usually use the following script:

declare

  l_user_id number;

  l_responsibility_id number;

  l_application_id number;

  l_organization_id number;

begin

--  dbms_output.enable;

  select application_id,responsibility_id

    into l_application_id,l_responsibility_id

    from fnd_responsibility_tl

    where responsibility_name = 'General Ledger Super User';

  select user_id

    into l_user_id

    from fnd_user where user_name='ORACLE';

  select organization_id

    into l_organization_id

    from hr_all_organization_units

    where name='Vision Operations';

  fnd_global.apps_initialize(l_user_id,l_responsibility_id,l_application_id);  

  --mo_global.set_policy_context('S',l_organization_id);

  mo_global.set_policy_context('M',l_organization_id);

--  dbms_output.put_line('Done...');

end;

Concurrent Requests

Concurrent request can now be setup to run as in 11i (default) or as MOAC compliant programs.
Use the “System Administrator” OAF screen “Concurrent Program” to set Operating Unit Mode to Single (OU) or Multi (MOAC compliant):