Oracle EBS R12多组织（多OU）访问架构
Oracle EBS R12多组织访问架构
多组织架构实现了经营单位(OU)的数据安全性，在底层数据表中有一列ORG_ID来记录数据所属的经营单一，所有多OU的基表都是以”_ALL”结尾，对应经营单位屏蔽信息的视图创建在
APPS数据库模式下。 多OU的视图通过职责上面设置的MO: Operating Unit预制文件的值来限制值的读取。预制文件的值在用户登录系统职责后通过FND来初始化，CLIENT_INFO这个功能函数来
取得ORG_ID的值，这个值在一个连接会话中有效。这样一来一个职责只能访问一个经营单位的数据。
从Oracle Applications R12开始，使用了多组织访问控制(Multi-Org Access Control)功能，使用户在一个职责下存取一个或者多个经营单位(Operation Units)的数据。增加了用户操作的方便性和灵活性。MOAC是通过安全配置文件(Security Profile)来实现的，通过在HR模块中定义安全配置文件来包括层次结构的组织架构，然后使用MO: Security Profile 预制文件将安全
性配置文件和职责关联起来，这样就实现了用户能够访问MO: Security Profile预制文件中所对应安全配置文件中的经营单位信息。而后台则是通过数据库中的VPD(Virtual Private
Database)功能来替换CLIENT_INFO实现多OU存取数据的控制。
MOAC对用户系统操作的影响 :
所有与多OU相关的业务窗口中，都添加了一个OU选择的值列表
MOAC对客户化开发的影响:
VPD(Virtual Private Database)替换了CLIENT_INFO，因此以前的安全性访问初始化的方式已经不再适用，如R12前使用如下的代码：
begin
dbms_application_info.set_client_info(‘&org_id’);
end;
/
select * from po_headers
/ 但是在R12种已经不适用，在12版的工作流数据库包开发中使用MO_GLOBAL来实现 而在表单和报表的客户化开发中，都需要通过安全配置文件来初始化安全访问。 为了和系统标准功能保持
一致以及程序的扩展性，需要在多OU相关的界面设计中添加OU选择的值列表。
关于R12的新特性Multi-Org Access Control(MOAC).Oracle宣传的好处主要有:
1.enable users to access to secured data in one or more Operating Units from a single responsibility
使用户能够从一个单一的责任访问一个或多个经营单位的安全数据。
2.End-Users can access/transact data within several operating units based on Security Profile attached to a responsibility.
最终用户可以基于安全配置文件连接到责任访问/办理多个经营单位内的数据。
3.Profile 'MO:Security Profile' will ensure access to multiple operating units from single responsibility
Profile 'MO:Security Profile'可以确保从单一的责任访问多个经营单位
具 体为什么会改成这样的原因可以从R12的宣传语看出:"The Global Business Release" "R12 Enables You To Think Globally,Work Globally,Manage Systems Globally "
从技术角度的一些拾零记录
1.在R12之前的版本中,组织控制是通过View来实现,比如说AP_INVOICES是定义在AP_INVOICES_ALL上面的View,而View一般都是通过在ORG_ID加条件来限制数据访问.
从R12开始,这样的View被取消了,取而代之的是同义词(synonyms),比如说AP_INVOICES就是AP_INVOICES_ALL的同义词(synonyms).
在R12里可以通过下面的SQL语句来查询有这样关系的表
---
select *
from dba_synonyms syn
where syn.synonym_name || '_ALL' = syn.table_name
---
2.R12中的组织访问限制是如何实现的呢?
是通过数据库安全方面的新特性virtual private database (VPD) policy来实现的,具体就是给_ALL表的同义词(比如说AP_INVOICES),添加对应的Policy.
这样在在查询的时候,数据库会根据Policy的来生成对应的条件(where)语句,来限制我们对数据的访问.
通过select * from dba_policies where policy_name = 'ORG_SEC'我们可以查询到那些表添加了Policy,以及是通过那个具体的Function来生成要添加的where条件
我们通过查询可以发现,比较具体的一个例子
Policy_name: ORG_SEC
Policy_group: SYS_DEFAULT
Package: MO_GLOBAL
Function: ORG_SECURITY
通过查看MO_GLOBAL.MO_GLOBAL,我们可以看到具体的生成限制语句的逻辑.其中Multiple OU Access是通过GLOBAL TEMPORARY TABLE MO_GLOB_ORG_ACCESS_TMP来实现的.
可以参看Note462383.1来看具体的每种情况会生成什么样的Where条件(a WHERE clause).
3.可以通过表FND_MO_PRODUCT_INIT中的STATUS来判断具体的某个Application是否支持MOAC.
4.通过表FND_MO_SP_PREFERENCES的User_ID, Resp_ID, Security_Profile_ID可以查看缺省的组织(Default Org_ID).相关联的Profile是MO: Default OU
5.MOAC定义的步骤
1.Define Operating Units(Optional)
2.Define Security Profile Enter the Operating Units for which you want access
3.Run concurrent program "Security List Maintenance Program"
4.Assign the security profile to MO: Security Profile profile option for your responsibility or user
5.Assign MO: Default Operating Unit(Optional)
6.Assign MO: Operating Unit(Mandatory for only Single Org or if MO: Security Profile is not defined)
中文：MOAC定义的步骤（对上面英文的翻译）
1.定义组织架构及OU信息
2.定义安全配置文件
3.运行”Security List Maintenance Program”请求
4.为用户职责分配”MO: Security Profile”预制文件的值为安全配置文件的定义
5.为用户职责设置一个默认的操作OU，分配”MO: Default Operating Unit”预制文件的值
6.如果还是希望一个职责对应一个单独的OU，设置职责层的”MO: Operating Unit”预制文件
6.MOAC在应用中初始化的基本流程
1.MO_GLOBAL.init
2.Set_Org_Access -- MO_GLOB_ORG_ACCESS_TMP
3.Check FND_MO_PRODUCT_INIT
4.If MO: Security Profile Else MO: Operating Unit
5.Set Policy Context "A", "S", "M" and org_id
注:这里的Policy Context的含义如下
Restrict the data to eliminate only seed data rows is the access mode is All
Restrict the data to a single operating unit if the access mode is Single
Restrict the data to multiple operating units if the access mode is Multiple
Restrict the data to not return any rows if the access mode is None
