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.
逐一遍历结果集的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，他们希望执行多轮扫描时，长度较长的字符串先执行：
Sort之前：2,5,7
Sort之后：5,2,7 – 错了。
只有显式加上by length才行：SORT lt_search_f by length DESCENDING.
尽量follow ABAP help里定义的guideline来避免类似问题：