Sent: Thursday, April 16, 2015 1:13 PM
在My task UI上维护了Account后,再点Contact F4 value help:
我们发现在GM6上,只要在search field里加了”Dr”, 就搜索不出来contact,如下图。但是换成诸如“Florianna Adler”就可以。
昨晚我们纠结了好久,想知道为什么会有这种奇怪的behavior。
上午经过debug找到了原因:
起初我们怀疑加了Dr之后的search没出来结果,是因为DB 没query到数据。今早经过验证,发现不是。Contact 的open sql是下列这个方法里动态生成的
主要就是这4张表做inner join
然后在下列这个方法里动态执行OPEN SQL,命中40条数据。
命中40条的原因就是OPEN SQL的where条件是扫描account的mc_name1和contact的mc_name1, mc_name2这三个字段。
因此,像下图中第一行和第三行这种数据也命中了,只因为它们的三个column中有一个column的value包含”DR”:
DB search做完后,对结果集做filter.
1
逐一遍历结果集的40条entry,对每个entry,执行三轮扫描,扫描条件定义在lt_search_f里, 每个entry只有通过所有三轮扫描,才会最后返回给UI。
扫描的具体逻辑:检查某个entry的这三个红色的field里是否包含每轮扫描指定的key word。如果不包含,将该行entry从结果集中删除,再处理下一个。
因此,加了Dr后搜不出来结果的原因:
Contact F4 search仍然将Dr作为一个free text传入后台,在后台从DB取回来数据做filter之后,如果结果集的三个column里没有包含DR这个字符串的话,就会从结果集里过滤掉。只有name1 & name2里面形如Andrew,Dragon的contact才有机会呗search出来。
Fiori ui上Contact search看起来像google like search,但其实technical 实现(指DB query那部分)还是和Webclient ui上的search一样。
当然,它也支持enterprise search。
而BP 的title Dr是以key 0001的形式存放在field TITLE_ACA1里的,Dr只是0001的可翻译的description,所以通过Dr搜索得不到期望的结果。
BP的code里有个bug,他们希望执行多轮扫描时,长度较长的字符串先执行:
1
Sort之前:2,5,7
Sort之后:5,2,7 – 错了。
只有显式加上by length才行:SORT lt_search_f by length DESCENDING.
尽量follow ABAP help里定义的guideline来避免类似问题:
————————————————
版权声明:本文为CSDN博主「汪子熙」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。