EBS功能安全性基本原理

yonghu

　　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等程序，都是严格根据当前用户的参数来过滤各模块表数        
据。