EBS功能安全性基本原理

AOL开发框架:

1、 “用户”如sysadmin登录，系统验证其用户名/密码
2、 如果OK，系统列出其拥有的所有角色，在EBS中叫“职责”（Responsibility），
而每个职责，都对应一个定义好的“菜单”
3、 当用户选择相应的职责进入“Navigator”后，显示的就是此菜单的内容
4、 每个底层菜单项，还不是直接对应Forms，而是先对应一个“功能”
（Function），由功能再去对应一个具体的“Forms”。这里的好处是，在功能上
可以定义参数比如查询条件、控制码等，然后传递给Forms，当然大部分情况是不
定义参数，所以功能和Forms基本上是一一对应关系
5、 用户点击菜单项，到定义Forms时指定的应用的TOP下，找到“fmx文件”执行之所以，反过来，如果我们开发好一个Forms，要在EBS中跑起来，完整的过程就是为该
“Forms”定义“功能”，定义“菜单”调用该功能，定义“职责”使用该菜单，最
后把职责分配给“用户”等一系列无Coding的定义工作。

 

EBS 文件系统：

整个EBS的角度看，分DB、APP两部分、五个大目录：

COMN目录（对应环境变量$COMMON_TOP）存放服务启停脚本和基于HTML
的应用文件（Java类、JSP页等）：

APPL（对应环境变量$APPL_TOP）则存放配置文件、各种管理脚本、各模块应用代
码：

APPL下的各个应用模块目录

AU模块存放fmb、pll、plx文件、各应用模块存放fmx文件，具体是：
$AU_TOP/resource： pll文件、plx文件
$AU_TOP/forms/US： 英文fmb文件
$AU_TOP/forms/<语言代码>： 特定语种（如ZHS）的fmb文件
$<应用简称>_TOP/forms/US： 各模块英文fmx文件录
$<应用简称>_TOP/forms/<语言代码>： 特定语种（如ZHS）fmb文件

上面<应用简称>，如INV、GL、AP、AR等等，在System Administrator职责下的
Application/Register中定义。

我们需要的模版及相关文件在AU_TOP下；我们开发的fmb文件呢，也应根据上
述规则传到$AU_TOP/forms的相关语言路径下，不过为管理、备份方便，实际开发
中可能故意违反EBS的规则，与fmx一起放在$CUX_TOP/forms的相关语言路径下。

 

多组织支持：

Oracle的多组织数据屏蔽，设计要点如下：
1、 核心层次：业务组BG→账套SOB→法人实体LE→经营单位OU→库存组织INV，
这些层次统称为组织，可通过视图org_organization_definitions查看关系。
2、 数据级别：表中设计有组织ID来屏蔽；不同模块因为针对的层次不同，其组织ID
含义不同，比如HR的表用Business_Group_Id，GL的表用Set_Of_Book_Id，
AR/AP/PO/OM等表用经营单位Org_Id，INV/MRP/WIP/BOM等模块用库存
组织Organization_Id。
3、 程序级别：用户登录、选择职责后，其所能操作的业务组、账套、法人实体、经
营单位就确定了，这个是通过相关的Profile来设置的；当进入制造和库存相关模
块，需要通过Change Organization菜单来获得可操作的库存组织。Oracle标准的
Package、Form、Java等程序，都是严格根据当前用户的参数来过滤各模块表数
据。

 

转载于:https://www.cnblogs.com/SanFrans/p/3267846.html