我一直对form 都感觉比较困惑, 特别是form 里面的trigger, 像PRE-QUERY, POST-QUERY 一直都弄不清情况. 这个trigger 是什么时候触发的呢? 看名字就是在QUERY 之前或之后触发的. 那么QUERY 什么呢? 搞不清楚.

     今天就看下代码, 弄明白点了 "find" 之后做了什么事情, 那些数据库里面的值怎么到form 界面上去的.

     我们知道, 每一个form 上的数据块都是绑定一个table 或者 view 的. 通常会绑定view. 像下面那样:

     我们可以认为, 一个数据块就是一个view. 而数据块上的字段, 通常也和view 里面的字段一一对应. 注意, 这里说的是通常. 在我们刚开始学习做form 的时候, 选择一个view, 比方说DEM_ORDER_V, 然后把view 里面的字段一一对应于数据块的字段, 这样编译运行的时候, 在form 界面菜单上 view -> query by -> run, 就可以直接做查询的动作, 在form 界面上就会显示出数据库的记录.

     这里就做了一次QUERY 的动作, 查询数据库, 然后把记录的值填到对应的field 里面去.

     但是这样的逻辑是简单的, 没有办法应付EBS 复杂的业务逻辑. 因此在实际的做法中, 并没有用这样简单直接的方式. 我们去看EBS 里面的form, 数据库上的字段和view 里面的字段几乎没有对应关系. 似乎是两个不相关连的东西, 只是名字很像.

     这样做的结果就是几乎所有的行为都要自己写代码实现. 不能像上面那样点下查询, 然后所有的值自动显示在界面上了. 由于缺少数据库与界面字段的关联, 即使查询了数据库, 也要手动把值复制给界面上的字段.

     我们以PO Receipts 界面为例, 看看点下"find" 都做了哪些事情.

1. 首先为了简化问题, 我们这里只考虑RCVRCERC.fmb 这个form 只有两个数据块 a) Find   b)RCV_TRANSACTION

在Find 界面上填写好查询条件后, 点一下"find", 这时会出发WHEN-BUTTON-PRESSED 这个trigger. 在这个trigger 里面先调用APP_STANDARD.APP_VALIDATE (RECORD_SCOPE) 做验证, 然后调用了FIND_BUTTON_CODE 这个方法. 

在这个方法里面, 调用了RCV_FIND_C.FIND_BUTTON(‘WHEN-BUTTON-PRESSED‘,‘FIND‘,‘RCV_TRANSACTION‘) 这个过程. 

这时在RCVCOFND.pld 里面定义的一个过程. 这个文件是一个比较底层的文件, Receipts form 从这个from 上继承了很多, 也调用里面的方法.

这个方法里面有3 个参数, 第一个是trigger 名. 第二个是find block name, 第三个是navigation block name. 那么调用这个过程会去到RCV_TRANSACTION 这个数据块, 然后做查询, 用下面的代码来实现:

go_block(navigation block name);

do_key(‘EXECUTE_QUERY‘);

2. 那么这时焦点就会跑到RCV_TRANSACTION 这个块上去, 然后做查询. 查询什么呢? 就是查询这个数据块所绑定的view.

在做查询之前, 我们要在RCV_TRANSACTION 这个数据块下面找到了PRE-QUERY 和 POST-QUERY 这两个trigger. 这两个是干嘛的呢? 就是在做QUERY 之前给查询做一些准备工作, 和查询结束之后进行一些后续工作. PRE-QUERY 只在查询之前执行一次, 但是POST-QUERY 要在查询之后触发多次. 查询到多少条记录就出发多少次.

3. 现在来看PRE-QUERY 里面做了什么. 

先是调用了这个过程: analyze_search_criteria(l_rcv_view,   l_dest_query_pos,   l_src_type); 看名字能看出来是在做什么... 分析查询条件. 这3 个参数属性都是OUT. 在这个过程里面确定了查询使用的view: l_rcv_view 是那个. 比如说, 如果我们做的是一个组织间转移 inter org transfer, 那么使用的view 就是RCV_ENTER_RECEIPTS_INTERNAL_V; 如果是ASN 接收的话, 使用的view 是RCV_ENTER_RECEIPTS_ASN_V; 使用哪个view 做查询就是在这个过程里面决定的. 决定标准是根据"Find" form 界面上填入的查询条件. l_dest_query_pos 意思是使用的查询方式, 有"from" 和 "where" 两种取值可能. l_src_type 就是source type, 可能是INTERNAL, LCM, CUSTOMER, VENDOR, ALL 等等;

我们这里考虑l_dest_query_pos = where 的情况. 

这里面会用下面这个过程APP_QUERY.append(block_name, clause) 把 clause 加到前面block_name 后面, 作为查询条件. 

4. 就这样通过判断find form 里面填入的值, 给查询的数据块加入一个一个条件. 比如, 如果FIND.SOURCE_TYPE 的值是VENDOR, 加上的查询条件就是: (RCV_ENTER_RECEIPTS_V.SOURCE_TYPE_CODE = ‘‘VENDOR‘‘ OR RCV_ENTER_RECEIPTS_V.SOURCE_TYPE_CODE = ‘‘ASN‘‘). 诸如此类.

5. PRE-QUERY 还做了一件事, 就是把find 界面上的值copy 给RCV_TRANSACTION 对应的字段. 但是这些不是作为查询条件来的.

6. 就这样在PRE-QUERY 里面确定了查询使用哪个view, 并且确定了查询条件. 然后就是做查询的动作. 查询是从前面的RCV_ENTER_RECEIPTS_INTERNAL_V 和RCV_TRANSACTION 绑定的view RCV_ENTER_RECEIPTS_V 两个view 里面查出结果来. 当查询结束后, 就会执行POST-QUERY 这个trigger.

7. 之前我们说过, 由于RCV_TRANSACTION 这个数据块上的字段和view 里面的字段是没有绑定关系的, 因此查询出来的结果并不会自动赋值给界面上的字段. 需要在POST-QUERY 里面手动赋值. 所以这个trigger 主要就是做的赋值的工作. 这个里面有大量的代码, 格式很单一:

if (criteria ) then select a into b from table where .. copy (b , ‘RCV_TRANSACTION.field‘);

也就是根据某个条件从数据库查出某个值, 赋值给数据库的字段. 所以这个里面出现了大量select 语句和copy 语句.

8. 在POST-QUERY 里面也调用了非常多的数据库过程, 这些过程写在 pls  文件中. 这里没有去深究这许多过程有哪些功能, 但能从调用的结果上看出来, 这里面是做了一些逻辑判断和计算的. 例如v_secondary_quantity  := inv_convert.inv_um_convert

9. 另外在这个trigger 的最后会set 字段的属性, 例如set_item_property: item_is_valid, 就是让字段验证属性为真.

10. 到这里为止, query 的动作就做完了, 通过PRE-QUERY 设定查询条件, POST-QUERY 给界面字段赋值. 要注意的是, 如果查询出来有两条记录的话, 那么POST-QUERY 会执行两次. 为啥要执行两次呢? 因为界面上两条记录的字段是不一样的, 需要根据不同的条件赋值, 比如两条记录的id 不一样, 就要用这个id 分别查出某个字段的值在赋值.

11. 到这里为止, 上面的RCV_FIND_C.FIND_BUTTON(‘WHEN-BUTTON-PRESSED‘,‘FIND‘,‘RCV_TRANSACTION‘) 这个过程就执行完了. 在此之后又执行了一下过程, 但是已经更查询的关系不大了, 主要是跳到某个窗口, 设置属性等等. 至此, WHEN-BUTTON-PRESSED 这个trigger 就全部执行完毕了. 查询的结果就已经在界面上显示出来了. 

12. 在焦点跳入RCV_TRANSACTION 数据块的时候, 又会出发WHEN-NEW-RECORD-INSTANCE 等等trigger, 但这是后事了, 这里就不讨论了;

     总结: 这样的做法显得非常复杂而且需要写很多代码, 但是优点也是比较明显的, 这对于所有的字段都有比较精确的控制. 这对于实现复杂的业务逻辑是必须的. 

     代码中有许多built-in 的代码, 可以在form builder 里面找看看是怎么用的. 帮助很大.

     注: 这是我看着代码写出来的, 如果里面有错误的地方, 希望大家能够指出来, 共同进步.