Form开发指南-起始篇：开发背景与基础环境介绍

1 用户和常用工具

1.1 区分3类用户

1. OS用户：包括超级用户root，应用OS用户如applprod，数据库OS用户oraprod。
2. 数据库用户：包括内置管理用户sys、system，EBS用户apps，EBS各模块用户applys、gl、inv、po、ar、ap等等。EBS网关用户applsyspub。
3. EBS用户：也叫OA用户、应用用户、ERP用户，包括默认超级用户sysadmin，其他内置用户，企业实施，使用过程中创建的用户。

1.2 Form开发使用的用户和工具

Forms开发过程中需要具体使用如下3个用户：

1. 应用OS用户

   • 使用Telnet工具（如SecureCRT）登录服务器，获得各 $XXX_TOP 的具体路径，编译form和pll。
   • 使用FTP工具（如CuteFTP）连接服务器，下载必要文件，上传开发的form。

2. APPS用户

   • 使用PL/SQL Developer登录数据库，创建各类数据库对象。

3. sysadmin用户（或拥有应用开发员和系统管理员职责的等价用户）

   • 注册form等各AOL对象，测试form。

2 AOL开发框架

2.1 Navigator

Forms自身菜单其实和传统菜单一样：

然而EBS中基本摒弃Forms自身的菜单功能，而是专门开发了一个Navigator界面，采用树形结构显示菜单，每个菜单项对应一个Forms：

        这里的菜单是可随意组织的，因此非常灵活，而不用如传统菜单那样要么写死要么用代码控制。 实际上，该方式完成了EBS最主要的安全性控制——功能安全性，为什么这么说呢？ 

 2.2 AOL开发框架：EBS功能安全性基本原理

        这里仅说明Forms部分， 安全性最终都要落实到“用户”身上，即某一用户是否具有某一权限；功能安全性的核心就是某一用户是否具有运行某一个Forms的权限。 为了方便管理，分类维护，EBS在“用户”和“Forms”之间加了几个层次。考察如下过程：                                        

        ①“用户”如sysadmin登录，系统验证其用户名/密码                                      

        ②如果OK，系统列出其拥有的所有角色，在EBS中叫“职责”（Responsibility），而每个职责，都对应一个定义好的“菜单”                                       

        ③当用户选择相应的职责进入“Navigator”后，显示的就是此菜单的

        ④每个底层菜单项，还不是直接对应Forms，而是先对应一个“功能”（Function），由功能再去对应一个具体的“Forms”。这里的好处是，在功能上可以定义参数比如查询条件、控制码等，然后传递给Forms，当然大部分情况是不定义参数，所以功能和Forms基本上是一一对应关系            

        ⑤用户点击菜单项，到定义Forms时指定的应用的TOP下，找到“fmx文件”执行之所以，反过来，如果我们开发好一个Forms，要在EBS中跑起来，完整的过程就是为该“Forms”定义“功能”，定义“菜单”调用该功能，定义“职责”使用该菜单，最后把职责分配给“用户”等一系列无Coding的定义工作。 

2.3 Tmeplate.fmb

        专业的软件系统，其操作方式、界面风格总是非常统一，即便是后来收购集成进来的模块，经过调整优化后，风格也基本一致。那么如何才能做到统一呢？一是依赖于规范文档，大家老老实实照标准开发；二是采用更加直接有效的办法——模版。 Oracle EBS的Forms，基本上都是从Template.fmb开始，该模版预先定义了： 

1. 各种界面元素的属性集——子类
2. 常用的控件——日历、进度条
3. 一系列Form级触发器，统一处理各种未被明确处理的事件
4. 丰富的PLL库函数，大大超越了Forms Builder内置的函数

        所以，我们基于EBS的开发，当然也是从Template.fmb开始。 

2.4 EBS文件系统

        EBS文件系统，指其以怎样的目录结构组织各种可执行文件、命令文件、配置文件的。 从整个EBS的角度看，分DB、APP两部分、五个大目录： 

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

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

         APPL下的各个应用模块目录，则是本次介绍的主角了：

         AU模块存放fmb、pll、plx文件、各应用模块存放fmx文件，具体是：

        上面<应用简称>，如INV、GL、AP、AR等等，在System Administrator职责下的Application/Register中定义。 通常各个企业都会创建一个客户化应用来管理二次开发的所有代码和设置，比如CUX、HAND等，下面以CUX（客户化的意思）为例。

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

3 多组织支持

3.1 说明

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

3.2 主要实例

         本文档主要围绕开发销售订单来介绍Form开发过程中涉及的关键技术点。

3.2.1 销售订单

         销售订单最核心的内容为：某客户，在某天，以何价格，购买多少数量的哪些商品。 一张销售订单，客户是一定的，销售员可能有多个，这里假定只记录主销售员，所以这两个信息构成销售订单的“头信息”；一次订单，客户通常会同时购买多种商品，并且未必是同一天要货，这样需求日期、商品、数量、价格构成销售订单的“行信息”。

3.2.2 开发需求分析

         销售订单还需要记录其它重要的内容，这个可直接参照EBS的“Sales Order”，为学习方便，这里仅加入如下不完整、不严谨的信息。

         头信息：订单编号、订单日期、内销还是外销、所采用的价目表、总价、币别、订单状态；非“录入”的不能删除，“部分履行”或“完全履行”的不能修改。

        订单状态：录入、确定、部分履行、完全履行。

        行信息：发货日期、收款日期；如果已发货，商品和数量不能修改，记录不能删除；如果已收款，整条记录都不能修改、不能删除。 全部行都已发货、已收款则订单状态为“完全履行”，部分发货或部分收款，则订单状态为“部分履行”。

         订单查询：需要提供按订单号、订单日期、客户、销售员、销售类型、商品、是否发货、是否收款等条件进行组合查询，查询表现方式分为Folder形式和Grid形式。

3.2.3 其它说明

        本文档使用“SCF”客户化应用做开发，不过数据库对象仍然沿用“CUX”前缀；没有建立专门的索引表空间。 

4 基于EBS的Forms开发过程

4.1 Form文件类型

        调用关系：fmb文件可以引用其他fmb文件、pll文件，pll文件可以进一步引用其他pll文件，引用是可以嵌套的。

        所以要成功打开一个forms源文件，必须保证其直接引用、间接引用的fmb、pll文件均存在。

        怎样才叫“存在”呢？类似各种语言如C的Include Path或Java的Class Path，Forms也有一个参数——注册表FORMS60_PATH来指示引用的路径，只要需要的文件在该路径下即可。 

 4.2 下载TEMPLATE.fmb

1.          用FTP以应用操作系统用户登录EBS服务器，进入到$AU_TOP目录下。
2.          从$AU_TOP/forms/US下载TEMPLATE.fmb到FORMS60_PATH对应的目录下。

find / -iname "template.fmb" 2>/dev/null

         也可以使用上面的命令去寻找模板所在地，登陆服务器后，直接运行即可。

4.3 打开TEMPLATE.fmb及报错分析

        打开TEMPLATE.fmb及报错分析

        本地仅有TEMPLATE.fmb，将报fmb文件找不到——Source Module后就是form文件名： 

        点击OK，再报pll文件找不到——PL/SQL library后面就是就是pll文件名： 

注意只可关闭、不可保存TEMPLATE.fmb！ 

4.4 下载必要的文件到FORMS60_PATH对应的目录

        目标：不断测试、下载，直至打开TEMPLATE.fmb，没有任何错误为止。 从$AU_TOP/forms/US下载缺失的fmb文件。

        从$AU_TOP/resource下载缺失的pll文件。 因为form和pll都可嵌套引用，所以有时候把提示的form或者pll下载下来，打开TEMPLATE.fmb依然报错，那么需要直接打开提示缺失的fmb或pll文件，这个时候才会看到真正缺失的文件，下载之。 

4.5 fs1、fs2和fs_ne三个系统文件的存在原因 

        在Oracle EBS（ERP）系统中，为什么会存在 /u01/SIT/app/fs1、/u01/SIT/app/fs2 和 /u01/SIT/app/fs_ne 这三个不同的文件系统目录，背后其实是为了满足系统的高可用性、灵活升级和版本管理需求。下面详细解释原因：

1. 多个应用文件系统副本（fs1 和 fs2）的原因

• 高可用性和负载均衡
  通过部署两个（或多个）应用文件系统副本，系统可以实现负载均衡和故障切换。

  • 当fs1所在的节点出现故障时，可以切换到fs2继续提供服务，保证系统不间断运行。
  • 也可以根据负载情况，将请求分配到fs1或fs2，提高整体性能。

• 无缝升级和版本切换
  在升级或维护时，可以先在fs2上部署新版本，测试确认无误后，再切换流量到fs2，而fs1保持旧版本，减少停机时间。
  这种方式称为“蓝绿部署”或“滚动升级”，极大提升了系统的可维护性和稳定性。

2. 非版本化文件系统（fs_ne）的作用

• 共享公共资源
  fs_ne目录存放的是不随版本变化的公共文件，比如共享库、公共配置文件、工具脚本等。
  这些文件对所有版本都是通用的，避免了重复存储和维护。

• 简化版本管理
  通过将公共资源放在fs_ne，升级时只需替换fs1或fs2，而不必重复更新公共文件，降低了升级复杂度和风险。

简单比喻：可以把fs1和fs2看成两台“备用服务器”，fs_ne是“公共仓库”，这样即使一台服务器升级或维护，另一台还能继续工作，公共仓库里的资源也不用重复拷贝。