下面我们分别讨论一下AM/EO/VO/CO这几种BC4J对象还有PG和RN的基本意义和二次开发方法。
先粗略解释一下这几种对象的含义和所起的作用
1、AM Application Module
AM作为一个管理容器而存在，为相关(这些对象共同完成一个相同的任务)的BC4J对象提供容器服务。
AM为事务处理提供上下文环境。
AM创建数据库连接
AM间可以进行上下级嵌套(一对多)
总结：可以看出AM偏向于事务控制。
2、EO Entity Object
EO封装业务规则、业务逻辑
EO完成对数据的实际的增、删、该动作
EO提供贯穿多个应用的持续的数据验证
EO之间通过AO来建立Relationship
总结：可以看出EO偏向于数据库对象控制
3、VO View Object
VO封装了一个数据库查询
VO提供对查询结果集的循环遍历
VO可以基于EO创建也可以基于SQL创建
可通过VO来对EO的属性值进行get或者set
VO之间通过VL来建立Relationship
总结：可以看出VO偏重于数据提取后与UI的展现和再交互
4、CO Controller Object
CO可以控制UI行为
CO可以处理GET/POST请求
总结：可以看出CO偏重于事件的处理和UI的重绘
5、PG OAF Page
PG是xml文件，通过树型结构描述了页面上的UI顺序，指定了需要调用的AM、VO和CO等BC4J对象
PG可作为独立功能来进行指定调用
6、RN OAF Region
RN是xml文件，其作用与PG类似，区别是其可以被PG或者其他RN引用调用，而不能被独立功能调用，其最大优点是可以被多个PG作为共用组件共享调用。
总结：PG可理解为多个非独立的RN组成，独立RN有自己对应的xml文件，可以被多个PG共享。
现在我们讨论一下以上各种对象的二次开发的方法。
在这里采用的是直接覆盖标准功能的做法。也许你会觉得这种方法不太安全，没有保留下来的标准功能可以作对照，出了问题不知道是系统标准功能的问题还是二次开发导致的。另外打补丁后是否会覆盖二次开发的程序也未可知。似乎这是一种不推荐的做法。
在项目初期，刚开始研究OAF二次开发模式的时候，也曾经考虑借鉴FORM二次开发的标准来进行。但是其间遇到的问题无法解决，要重新复制一个新的OAF 功能出来就是非常费劲，并且OAF的菜单权限等不如FORM的那样那么分明，很多功能无法拆分出来。最终采取的就是直接改写标准功能的做法。
还有不得不提的java类的反编译问题。
R12 的class反编译偶尔会失败，产生的代码加入OAProject中会报上百个错误，仔细观察后发现，主要是两种问题，一是变量名称的变化导致，在11i 的class中，变量通常是oapagecontext和oawebbean，到了R12中工具默认的标准名称是pageContext和 webBean；另外一个是jad反编译工具，在jdk1.5以后遇到finally关键字就犯傻，例如，
SQLException sqlexception;
sqlexception;
try {
oraclecallablestatement.close();
}
catch (Exception exception) { }
throw OAException.wrapperException(sqlexception);
或者在行号位置上增加MISSING_BLOCK_LABEL的语句，导致报错。另外还会出现以下Class aclass[] = {[Ljava/lang/String;这样的语句。当然某些时候if语句花括号不知道该括到哪里也会有时产生。而如果同样的class出现在 11.5.10中，反编译后就没有问题，当然我指的是两个版本上没有代码差异的类。
目前对EBS的OAF中的某些类的反编译失败的问题还未能有有效的解决办法。我使用的jad是最新版的，号称是支持jdk1.5的。我因为是java半路出家，写出来希望有java高手能解决这个问题，在下不胜感激。
在此思想指导下，我也整理出了一些开发的规范来保证二次开发对系统标准功能冲击最少。
1、对PG和RN的二次开发
在二次开发前，首先需要对标准功能和用户需求之间的差距进行研究，以达到最小改动即可实现所需要求的目的。在此之后，对功能页面通过“关于此页”链接进行 分析－－打开“关于此页”的配置文件设置，见我的《OAF开发中相关的配置文件》，里面有详细说明。做出整体的调整计划后就可以知道是不是需要将PG或 RN导出进行调整了。一般情况下，如果二次开发涉及到要在页面上增加或隐藏UI控件(对UI控件不推荐删除)，改变AM/CO/VO等的名称时需要调整 PG或RN，在其他情况下，一般不需要将页面导出进行二次开发。
2、对AM的二次开发
AM在不改变名称的前提下，对PG或RN以及其他的对象是透明的，除非要增删AM中包含的VO(AM定义中的VO等对象也不推荐删除)或修改amimpl类。AM的构成就是两个文件：XML和AMIMPL类。一般涉及到的AM的调整，这两个文件均需要调整。保险的方法是将AMIMPL类反编译后，将xml文件和java文件加入OAProject中，使用AM的编辑功能来利用jdev完成。
将AM引入OAProject比较麻烦，因为同时还需要将AM引用的所有VO的xml都拷贝到myproject的相应路径下，否则编译无法通过。
在二次开发时，在AM中增加一个VO的步骤是：反编译AMIMPL类，将AM的xml文件和相应的impl类引入OAProject中。编辑AM，添加 VO,保存，系统会重写AMIMPL.java文件，编译会报一堆变量名错误，替换变量名后，排错，然后再在其中根据需要添加方法一般是 initQuery等方法。
3、对VO的二次开发
一般在PG和RN中要增加一个数据区，是需要增加一个VO到AM中，该AM可以新建也可以修改原有系统的。
VO是开发需要，一般有两个或三个文件，包括VO.xml、VOImpl.class(主要完成对整个查询的初始化)和VORowImpl.class(主要完成对每个字段的赋值、取值)。
如果只是修改VO中的定义的SQL语句，则仅需要修改VO.xml即可。注意不要增删字段，不要修改字段的别名、顺序等，并且在字段列表的最后加入。该修 改要在Jdev之外通过文本编辑器来进行即可。因为不反编译class，没有java文件，在Jdev中是无法修改VO的SQL语句的。
如果涉及到增加字段(不推荐删除字段)，则最好使用Jdev来完成，如果VO创建了VORowImpl文件，则必须进行反编译并引入Project， VOImpl则视开发需要来决定是否需要反编译相应的class文件，在编辑了VO后，保存时，一般make java文件都会报错，均是变量名不匹配导致，替换即可。
4、对EO的二次开发
在二次开发中，一般不涉及到对EO的操作。因为很多二次开发可以通过VO的调整来完成，其他的如果要于数据库交互可直接在CO中调用存储过程来进行，这样比修改EO简单有效的多。如果高手有关于EO的二次开发心得，也欢迎赐教。
5、对CO的二次开发
在二次开发中，涉及到的最多的就是CO的调整了，因为CO直接控制着事务逻辑，可以在CO中控制UI的变化，在CO中直接与后台数据交互完成校验等等。
CO的二次开发，有两种模式，一种是直接反编译系统CO，一种是继承系统CO。两种模式各有取舍。
继承模式是要优先考虑的，该种方式比较简单，比如我要扩展oracle.apps.eam.workorder.webui.SystemCO,那么我的步骤就是：
首先，创建一个新的CO,比如oracle.apps.eam.workorder.webui.MyCO,其extends不是 OAControllerImpl类，而是SystemCO，同样在CO中视需要建标准的processRequest方法和processFormRequest方法，并在方法体的第一行调用父类方法super.processRequest或者 super.processFormRequest。
其次，修改调用CO的PG或RN，将原有的CO指向调整到新建的子类CO上即可。
而反编译模式就比较直接了，当然前提是要反编译成功，而且对于需要暂停标准功能流程的要求，则必须使用该种模式，比如需要在执行某个操作前，给用户一个确认对话框，则必须反编译系统CO，在其中增加校验的方法才行。
