概述
我一直对form 都感觉比较困惑, 特别是form 里面的trigger, 像PRE-QUERY, POST-QUERY 一直都弄不清情况. 这个trigger 是什么时候触发的呢? 看名字知道在QUERY 之前或之后触发的. 那么QUERY 什么呢? 搞不清楚.
今天就看下代码, 弄明白点了 "find" 之后做了什么事情, 那些数据库里面的值怎么到form 界面上去的.
我们知道, 每一个form 上的数据块都是绑定一个table 或者 view 的. EBS绑定的都是 view. 像下面那样:
我们可以认为, 一个数据块就是一个view. 而数据块上的字段, 通常也和view 里面的字段一一对应. 注意, 这里说的是通常. 在我们刚开始学习做form 的时候, 选择一个view, 然后把view 里面的字段一一对应于数据块的字段, 这样编译运行的时候, 在form 界面菜单上 view -> query by -> run, 就可以直接做查询的动作, 在form 界面上就会显示出数据库的记录.
这里就做了一次QUERY 的动作, 查询数据库, 然后把记录的值填到对应的 field 里面去.
但是这样的逻辑是简单的, 没有办法应付EBS 复杂的业务逻辑. 因此在实际的做法中, 并没有用这样简单直接的方式. 我们去看EBS 里面的form, 数据库上的字段和view 里面的字段几乎没有对应关系. 似乎是两个不相关连的东西, 只是名字很像.
这样做的结果就是几乎所有的行为都要自己写代码实现. 不能像上面那样点下查询, 然后所有的值自动显示在界面上了. 由于缺少数据库与界面字段的关联, 即使查询了数据库, 也要手动把值复制给界面上的字段.
我们以 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 里面定义的一个过程. RCVCOFND 是一个比较底层的文件, 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 对应的字段. 但是这些不是作为查询条件来的. 上面说过, PRE-QUERY 只执行一次, 因此这里copy 就会把RCV_TRANSACTION 里面所有记录的一个属性赋成一样的值. 而POST-QUERY 是对不同的记赋不同的值的.
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 ( ) 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 里面找看看是怎么用的. 帮助很大.
注: 这些是看着代码整理出来的, 错误在所难免. 如果有错误的地方, 希望大家能够指出来, 共同进步.
----------------------------2014-05-22 更新
之前对于PRE-QUERY 和POST-QUERY 的理解不准确, 今天问了下小波同学, 他解释的比较好.
PRE-QUERY 是block 级别的, 只执行一次. data block 和view 上面的字段是有绑定关系的, execute-query 的时候, 比如查出10 条记录, 那么查询的结果就已经赋值给data block 的字段了.
POST-QUERY 是record 级别的. 查出来10 条记录, 那么每条记录会做一次POST-QUERY, 对必要的字段做处理.
另外上面说的从view 里面查出来的值没有自动赋值给界面上的字段, 这个不对. 从view 里面select 出来的字段的值都自动copy 给form 上对应的字段了, select 了哪些字段可以从 $SYSTEM.LAST_QUERY 上看出来. 我猜测在fmb 文件里面是有明文写着select 哪些字段的, 可是没找到...
最后
以上就是伶俐嚓茶为你收集整理的在 EBS Form 查找界面点 "Find" 之后都发生了什么?的全部内容,希望文章能够帮你解决在 EBS Form 查找界面点 "Find" 之后都发生了什么?所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复