说起 F4 值帮助很多人第一反应是SE11 里挂张表就完事了。真到项目里你会发现光挂表根本不够用物料号要按工厂和物料类型过滤选了物料号还得顺手把描述带回来某些用户还不允许看到特定组织范围的数据。这些需求落到 SE11 上就是给 search help 挂一个 search help exit。这篇东西就是围绕这件事展开的怎么在 SE11 里把一个带 exit 的搜索帮助从零建起来出口函数的接口为什么一字不能改四个回调步骤各干什么活以及我踩过的那些代码明明写了但就是不生效列表列宽全歪了的坑。适合已经会基本的 SE11 建表、写过简单 FUNCTION但还没正经做过自定义搜索帮助出口的 ABAP 同学也适合被老系统 F4 折磨过、想搞清楚背后机制的人。下面全部是我自己实际做下来的顺序和判断不是照着文档抄一遍。1. 先想清楚这个出口到底解决什么问题1.1 三种做法摆在一起比一比在建对象之前我一直坚持先把能不能不写代码这个问题问一遍。因为搜索帮助出口是典型的一旦引入就要长期维护的东西后面接手的人如果不熟悉改一个字段顺序就能把列表搞乱。所以先把三条路摆开对比选最省的那条。做法典型场景好处代价直接挂透明表字段本身就在表里过滤条件单一零代码SE11 三分钟搞定没法带文本、没法做权限、没法做动态过滤挂数据库视图或维护视图需要 join 文本表、需要带描述代码量小视图复用性好视图字段固定逻辑复杂一点的过滤做不了挂搜索帮助出口动态过滤、附加返回字段、权限收窄、去重灵活度最高几乎什么都能干要写函数接口和字符串对齐都容易出错我给自己的判断标准很简单如果需求里出现了根据只能顺便带出这三个词中的任何一个基本就得写出口了。根据工厂过滤是动态条件只能看自己组织范围是权限顺便带出描述是附加返回字段。反过来如果只是一张码表的全量展示硬上出口纯属给自己加维护成本。还有一种情况值得单独说需求是带出文本但文本表很小而且是固定的。这种情况下我会先考虑建一个数据库视图把主表和文本表 join 起来当选择方法比写出口省事得多而且后面别人接手一看视图名就懂。出口留到真正需要运行时才知道怎么过滤的时候用这是我多年下来的取舍习惯。1.2 出口的能力边界出口能做和不能做的事边界其实很清楚但很多文档不写导致新手一上手就想在里面弹窗、想读调用程序的全局变量然后 dump 得一塌糊涂。出口本质上就是一个普通函数模块它运行在调用程序所在的同一个内部会话里但看不到调用程序的全局变量。它唯一能拿到的上下文是接口参数里那几张表CALLCONTROL 告诉你现在是哪一步SHLP 描述搜索帮助本身INTERFACE 装着从屏幕字段带进来的值SELECTION 装着用户选中的值RECORD_TAB 是要显示的行。你想知道调用我的那个程序现在是什么状态对不起拿不到。想拿只能让调用方通过搜索帮助的 IMPORT 参数把值传进来。同理出口里不要 CALL SCREEN、不要弹 POPUP、不要 COMMIT WORK。我见过有人在 EXIT 步骤里弹个确认框问确定要选这个吗结果 F4 界面直接僵在那儿用户以为系统卡死。这类交互应该在调用程序里做或者干脆用搜索帮助的对话框模块Dialog module来做那是另一套机制跟出口是两回事。出口最擅长的四件事收窄数据范围过滤、补充返回字段回填、做权限校验AUTHORITY-CHECK 后清空结果、把代码值翻译成可读文本。把这四件事记住遇到需求先往里套套得上就写出口套不上就想别的办法别硬来。2. 动手之前要定的三件事2.1 选择方法选表还是选视图选择方法Selection method决定了框架默认去哪儿取数。这个字段填错了后面写的出口代码基本全废。SE11 里它接受透明表、数据库视图、投影视图、维护视图、CDS 视图新版本不接受的是一般结构体。我的经验是先看数据在哪儿。如果候选值本来就集中在一张自定义表里比如配置表、码表直接选那张表最干净。如果候选值散在主数据表里、还需要带描述那就建一个数据库视图把主表和文本表用 INNER JOIN 拼起来语言条件放在SPRAS sy-langu上。这里有个小细节视图里的语言字段用固定条件sy-langu会导致视图本身不能按语言过滤有些场景下会出问题稳妥做法是不在视图里写死语言而是在出口的 SELECT 步骤里带AND spras sy-langu。还有一点必须提前确认选择方法里必须包含你在参数页签里要用到的所有字段。如果参数里要一个字段、但视图里没有SE11 保存时会报字段不在选择方法中。这种情况要么扩视图要么把这个字段改成只作为 EXPORT 参数、在出口里手工回填。后者更常见也更灵活比如物料描述 MAKTX 就经常不在选择方法里靠出口回填。2.2 参数与显示字段怎么排搜索帮助的参数页签是整个对象里最容易被忽视、但出问题最多的地方。这里有两组位置编号LPos 管列表显示顺序SPos 管选择条件顺序。两个都必须从 1 开始连续编号中间不能跳。我试过留了个空位1、2、4结果列表第 3 列直接是空白数据整体右移查了半天才发现是编号断档。参数本身的勾选也有讲究。IMPORT 表示调用界面传进来的值EXPORT 表示选中后回传给界面的值。只勾 IMPORT 的参数用户看不到它返回只勾 EXPORT 的参数用户没法预先限制它。绝大多数场景是两个都勾这样既能输入条件又能返回结果。唯一的例外是纯展示用的附加字段比如描述文本只勾 EXPORT 就够了。字段类型这里建议一律挂参考表和参考字段而不是手填类型。原因很实在参考字段会自动带出类型、长度、F4、转换例程一旦数据类型升级比如物料号从 18 位改长度虽然几乎不可能但确实存在搜索帮助会跟着走。手填类型的对象在升级时是没人管的属于定时炸弹。参数的数据元素最好跟调用界面的字段保持一致这样挂到数据元素上的时候不会报类型不匹配。2.3 出口函数放哪个函数组出口函数必须归属于某个函数组且处理类型必须是普通函数模块不能是远程、不能是更新模块。函数组本身没什么特殊要求我习惯单独建一个ZFG_F4_EXIT之类的组把所有出口函数都放进去好处是查依赖的时候一眼能看全坏处是组太大后激活慢。如果是按模块划分的系统放业务模块自己的函数组也行看团队习惯。命名我强烈建议带上场景ZF4_EXIT_MATNR_BY_WERKS比Z_F4_01有用得多。半年后翻代码名字就是最好的文档。这一点在传输对象多、人员流动大的项目里体现得尤其明显——一个看不出用途的出口函数通常的结局是没人敢动然后在它旁边再写一个新的。3. SE11 里把搜索帮助搭出来3.1 基础属性填写进 SE11输入以 Z 或 Y 开头的名字单选搜索帮助点创建。第一屏要填的东西不多但每一项都不能随便描述写清楚业务含义和过滤条件比如按工厂过滤的物料搜索帮助。这句描述会显示在 F4 弹窗的标题栏用户看得见。搜索帮助类型选基本搜索帮助Elementary。集合搜索帮助是把多个基本搜索帮助拼起来一般很少自己建除非要做按编号查和按描述查两个入口。选择方法填第 2 节里确定的表或视图名。搜索帮助出口填出口函数名。这个字段是第一屏就能填的很多人以为要建完再回来改其实一开始填好更省事因为保存时会做接口校验。对话框类型这里有立即显示值显示所有值等选项。默认值通常是合适的如果想让用户一进 F4 就看到全部候选不进条件屏幕选立即显示值。填完这些按回车系统会去读选择方法的结构并把字段列出来。如果这一步报错八成是选择方法不存在或者没激活——先去激活对象别在这儿死磕。3.2 参数页签的字段映射参数页签是主体工作。操作顺序建议这样先在参数区域手动定义参数名可以跟表字段同名也可以自定义再在下方的字段列表里把选择方法的字段往参数上拖。具体填法在参数区填参数名、参考表和参考字段、数据元素。参数名建议就用表字段名省得后面写代码时来回换算。勾 IMPORT / EXPORT。这一步决定了这个参数是输入、输出还是双向。在字段列表区选中对应的表字段点分配或者直接双击到参数行的字段位置。填 LPos显示序号和 SPos选择序号。只想显示不想让人筛的字段LPos 给值、SPos 留空只想让人筛不想显示的字段比如隐藏的工厂限制字段SPos 给值、LPos 留空。这里有个实际场景值得展开如果搜索帮助要挂在数据元素上让所有用这个数据元素的屏幕字段自动带上 F4那么参数的 IMPORT 部分必须在数量上够用而且要在数据元素的进一步特性里指定搜索帮助名。但数据元素只能指定一个搜索帮助多个场景按工厂查、按物料类型查就得靠集合搜索帮助或者搜索帮助参数分配在搜索帮助的参数分配页签里把不同搜索帮助的参数映射起来。3.3 挂上出口并激活第一屏已经填了出口函数名剩下的就是检查接口。保存的时候系统会去读那个函数模块的接口如果参数名、类型对不上会直接抛消息说接口不正确。这时候别急着改搜索帮助先回 SE37 把接口改对。激活的顺序我一般是这样先激活函数组和出口函数再回到 SE11 激活搜索帮助。反过来做的话第一次激活一定失败因为搜索帮助生成程序的时候找不到可用的函数。这个顺序在传输的时候会自动处理但在开发机上手工激活时经常有人搞反。激活之后测试。SE11 打开搜索帮助的显示界面工具栏里有测试按钮不同版本位置略有差异菜单里也有对应入口点进去就是真实的 F4 交互。我在这一步会专门测三种情况不输条件直接回车、只输一个条件、输一个不可能的区间。第三种最能暴露问题很多出口在查不到数据时的处理是错的直接弹个空列表或者干脆 dump。提示改了出口函数之后一定要重新激活搜索帮助。因为搜索帮助会生成一段程序里面固化了参数结构只激活函数模块生成的程序还是旧的表现出来的现象就是我代码明明改了但一点变化都没有。这个坑我至少踩过三次。4. 出口函数的实现细节4.1 接口签名必须一字不差这是整件事里最硬的一条规则出口函数的接口是框架约定死的参数名、类型、传递方式任何一个字不对搜索帮助就认不出来。正确的签名长这样FUNCTION zf4_exit_matnr_by_werks. *---------------------------------------------------------------------- **Local Interface: * IMPORTING * VALUE(CALLCONTROL) TYPE DDSHF4CTRL * CHANGING * VALUE(SHLP) TYPE SHLP_DESCR * VALUE(INTERFACE) TYPE DDSHIFACE_TAB * VALUE(SELECTION) TYPE DDSHRETVAL_TAB * VALUE(RECORD_TAB) TYPE SEAHLPRES_TAB *----------------------------------------------------------------------几个容易翻车的点。第一CALLCONTROL 是 IMPORTING不是 CHANGING写成 CHANGING 就废了。第二后面四个都是 CHANGING 且都是表类型带 _TAB 后缀写成结构体或者单个字段都不行。第三别自作聪明加参数比如想再传一个当前用户进去加了之后搜索帮助激活会报接口错误。要传值走搜索帮助的 IMPORT 参数。RECORD_TAB 的行结构值得单独说一句。它不是一个宽结构而是一个只有STRING一个字段的定长字符串具体长度以 SE11 里 SEAHLPRES 的定义为准常见是 250 位。也就是说这个搜索帮助显示出来的每一行本质上是把若干字段按顺序拼成一根字符串。这一点如果没搞明白后面列表错位的问题永远解决不了。4.2 STEP 全景与各步骤的分工CALLCONTROL-STEP 是出口函数里的总开关。同一个函数会在一次 F4 交互中被调用多次每次带着不同的 STEP 值你得用 CASE 分开处理。常见的步骤值和我实际用到的场景如下STEP 值触发时机我一般在这里干什么SELECT框架准备取数之前自己查数据、拼 RECORD_TAB或者只改 SELECTION 让标准取数去执行PRESEL带值进入字段已有值再按 F4根据带入值收窄条件避免一进弹窗就查全表DISP列表即将显示之前修饰 RECORD_TAB 内容比如把代码换成文本EXIT用户确认选中、值返回之前回填附加字段、做最后一道校验RETURN用户取消或返回清理、记录日志一般可以什么都不做APPEND / APPENDALL用户把值追加到多选列表多选场景下的附加处理大原则不要随意改 CALLCONTROL-STEP。除非你明确知道要跳到哪一步否则让框架自己走完流程。我见过有人在 SELECT 里把 STEP 设成 DISP想让列表直接出来结果列表出来了但选中值回不去用户点确定没反应。这种问题排查起来非常费劲因为代码看起来逻辑通顺。还有个细节每个 STEP 里都建议加一个WHEN OTHERS兜底并且不要在里面写复杂逻辑。框架在某些版本会传一些你没想到的步骤值进来兜底里什么都不做反而是最安全的。4.3 SELECT 步骤自己取数并拼行SELECT 步骤是出口的主战场。逻辑是先从前面的 SELECTION 表里把用户输的条件读出来自己组织 SELECT把结果拼成行塞进 RECORD_TAB。关键点是——RECORD_TAB 有内容的时候框架就不再执行标准取数了所以这一步你自己说了算。DATA: ls_sel TYPE ddshretval, lt_result TYPE TABLE OF zmaterial_v, ls_result TYPE zmaterial_v, ls_record TYPE seahlpres. DATA: BEGIN OF ls_line, matnr TYPE matnr, mtart TYPE mtart, meins TYPE meins, END OF ls_line. CASE callcontrol-step. WHEN SELECT. DATA: lv_matnr_from TYPE matnr, lv_matnr_to TYPE matnr, lv_mtart TYPE mtart. 1) 把界面上输的条件收下来 LOOP AT selection INTO ls_sel. CASE ls_sel-fieldname. WHEN MATNR. IF ls_sel-option EQ. lv_matnr_from ls_sel-fieldval. lv_matnr_to ls_sel-fieldval. ELSE. lv_matnr_from ls_sel-fieldval. lv_matnr_to ls_sel-high. ENDIF. WHEN MTART. lv_mtart ls_sel-fieldval. ENDCASE. ENDLOOP. 2) 自己查注意带上条数上限 SELECT matnr mtart meins FROM zmaterial_v INTO TABLE lt_result UP TO callcontrol-maxrecords ROWS WHERE matnr BETWEEN lv_matnr_from AND lv_matnr_to AND mtart lv_mtart AND spras sy-langu. 3) 按显示顺序拼成定长字符串 LOOP AT lt_result INTO ls_result. CLEAR ls_line. ls_line-matnr ls_result-matnr. ls_line-mtart ls_result-mtart. ls_line-meins ls_result-meins. CLEAR ls_record. ls_record-string ls_line. APPEND ls_record TO record_tab. ENDLOOP. WHEN OTHERS. 兜底什么都不做 ENDCASE.这段代码里有三个我特别想强调的地方。第一拼行用的是结构体赋值ls_record-string ls_line而不是手工算偏移量ls_record-string(18) ...。为什么因为结构体的字段长度和搜索帮助里显示字段的内部长度是一致的赋值时系统会自动按长度补空格对齐。手工算偏移量一旦哪个字段长度记错一位整行数据全部错位而且错得很整齐看起来像是字段顺序排错了实际是长度问题非常难查。当然用结构体有个前提结构体总长度不能超过 STRING 字段的长度超了会被截断最后几列直接不显示。第二callcontrol-maxrecords一定要带上。这个值来自搜索帮助的最大记录数设置不带的话一个没输条件的 F4 可能拉出几十万行页面卡住不说还可能触发内存告警。我一般还会在自己的 SELECT 里再兜一层比如强制不超过 500 行。第三条件读取的代码不能假设用户一定输的是 EQ。F4 弹窗里的选择字段支持区间、包含、排除OPTION 可能是 BT、CP、NE。如果只处理 EQ用户输个区间就查不出东西而界面上不会有任何报错只是列表空的。这种情况用户会以为系统里没这个物料然后去提工单。4.4 EXIT 步骤回填附加字段这是出口最常用的第二个场景用户选了物料号还要把描述、规格、单位一起带回调用界面。做法是在 EXIT 步骤里遍历 SELECTION为每条选中记录追加对应的附加字段条目。前提是这些附加字段在搜索帮助里定义成 EXPORT 参数。WHEN EXIT. DATA: lt_add TYPE TABLE OF ddshretval, ls_add TYPE ddshretval, lv_matnr TYPE matnr, lv_maktx TYPE maktx. LOOP AT selection INTO ls_sel. IF ls_sel-fieldname MATNR. lv_matnr ls_sel-fieldval. SELECT SINGLE maktx FROM makt INTO lv_maktx WHERE matnr lv_matnr AND spras sy-langu. IF sy-subrc 0. CLEAR ls_add. ls_add-fieldname MAKTX. ls_add-fieldval lv_maktx. APPEND ls_add TO lt_add. ENDIF. ENDIF. ENDLOOP. 别在 LOOP 里直接 APPEND 到正在遍历的内表 APPEND LINES OF lt_add TO selection.这里有个 ABAP 的通用禁忌不要在LOOP AT selection的循环体里往 selection 里 APPEND行为不可预期。我习惯先用一个临时表收集循环结束后APPEND LINES OF一次性追加代码干净也不会有隐患。还有一个坑是单条 SELECT。上面为了说明逻辑写得直白实际上如果用户多选了几百行就是几百次单条 SELECT性能会很差。正确做法是一次性把物料号收进一个内表或 ranges用FOR ALL ENTRIES或者SELECT ... INTO TABLE ... WHERE matnr IN s_matnr批量查再在内存里 READ TABLE 匹配。这个优化在数据量小的时候完全看不出差别一旦用户全选就原形毕露。另外要注意 MULTI 场景。如果搜索帮助支持多选EXIT 步骤会被调用一次SELECTION 里包含所有选中的行回填的时候要保证附加字段的行数和主字段的行数一一对应错位了调用界面拿到的描述就全串了。稳妥点可以在 EXIT 里做一次数量核对不相等就直接清空 SELECTION 让用户重选——虽然粗暴但比返回错数据强。4.5 PRESEL 与 DISP 的实用场景PRESEL 步骤很多人不用但它在带值进入的场景下很有价值。什么叫带值进入屏幕上字段已经有值了用户按 F4希望看到的是以这个值为中心的候选而不是全表。如果什么都不做框架会把这个值作为条件传进 SELECTION你的 SELECT 逻辑自然就收窄了看起来不需要 PRESEL。但如果带入的值是个模糊值或者你想额外加一个默认条件比如默认只看当前用户所属公司代码PRESEL 就是最合适的位置。DISP 步骤我主要用于显示美化成。比如列表里有一列是状态代码 A/B/C用户看着难受想显示成启用/停用/冻结。做法是在 DISP 里遍历 RECORD_TAB按当前拼装顺序定位到那一列替换掉内容。这里的修改必须严格按显示字段的长度和偏移来写否则会把相邻列的内容切掉一半。所以我在 DISP 里动手脚之前一定先把显示字段的顺序、长度抄在纸上改完立刻测试列表显示不给自己留隐患。说句实话能用选择方法里 join 一张文本表解决的就别在 DISP 里替换字符串。字符串操作属于看起来简单、出问题最难查的那一类尤其是在中英文混排、字符宽度不一致的时候偏移量算错一位就是一整列的错乱。5. 排查实录与性能细节5.1 出口根本没进去的排查顺序最让人抓狂的是代码写完了、激活了、搜索帮助也建好了按 F4 出来的是标准列表断点根本不进。我总结了一套排查顺序按这个走基本五分钟能定位。第一步确认搜索帮助第一屏的搜索帮助出口字段真的有值而且没有拼写错误。这个字段不会自动补全填错了保存时不报错只是不生效。第二步确认出口函数的接口完全正确。用 SE37 打开函数逐个核对五个参数的名字、类型、传递方式。特别注意有没有人为了方便调试临时加过参数然后又删得不干净。第三步重新激活搜索帮助对象。这一步不是形式主义是实打实会解决问题。搜索帮助生成的程序里固化了出口函数的调用不重新生成你改的所有东西都不生效。第四步确认调用方用的到底是不是这个搜索帮助。屏幕字段上可能挂了多个 F4数据元素上挂了一个屏幕字段的进一步特性里又挂了一个后者优先级更高。这种情况在老系统里非常常见尤其是有多人在同一批表上工作过的时候。第五步检查是不是被唯一值自动带出的行为绕过去了。如果搜索帮助只有一个 EXPORT 字段、用户输的值在数据库里唯一匹配某些配置下系统会直接带出值不弹窗出口的 SELECT 步骤可能以另一种方式被调用。这时候看起来像没走出口其实是走了但没显示界面。测试时故意输一个不唯一的值就能验证。5.2 列表错位、乱码、丢行的成因列表错位是出口开发里最高频的问题成因就那么几个我列出来对照着看现象大概率原因处理方式所有列整体右移显示字段的 LPos 编号不连续改成 1、2、3 连续编号某一列内容被截断拼行时该字段的偏移或长度算错改用结构体赋值别手工算偏移最后一列不显示结构体总长度超过 STRING 字段长度减少显示字段或拆分显示中文显示成问号或方块字段类型是 CHAR 但内容含多字节字符长度按字节算检查字段定义确认数据元素长度语义行数比预期少SELECT 里带了 maxrecords 限制调整搜索帮助的最大记录数设置数据重复视图 join 没有去重或文本表有多语言记录视图里加语言条件或用 SELECT DISTINCT中文显示的问题值得单独讲两句。ABAP 里 CHAR 类型的长度在不同场景下语义不完全一致屏幕上按字符算、内存里按字节算的情况是存在的。如果拼行时按字符数来估算偏移遇到中文一定会错位。这也是我坚持用结构体赋值的另一个理由赋值时由系统按目标字段的实际长度处理不用我操心。5.3 数据量与响应速度一个没做优化的出口在测试环境里跑得飞快到生产环境一按 F4 就转圈半分钟。原因通常是三个没有条数限制、没有走索引、在循环里做 SELECT。条数限制前面说过callcontrol-maxrecords是基本盘。索引方面出口里的 WHERE 条件必须能命中选择方法表或视图上的索引否则就是全表扫。自定义表建的时候如果只建了主键索引而你的过滤条件是物料类型 工厂那大概率走不到索引。解决办法是在 SE11 里给表加二级索引或者干脆把常用的过滤字段做进视图的 key 里。循环里做 SELECT 是最常见的性能杀手尤其出现在 EXIT 步骤回填的时候。我做过一个粗略的对比用户一次选 200 行物料单条 SELECT 回填描述大约需要 2 到 4 秒取决于数据库和网络改成批量查询加内存匹配之后稳定在 100 毫秒以内。差别就是这么大。所以只要回填逻辑里出现了 SELECT SINGLE 写在 LOOP 里我就会立刻改成批量。还有个小技巧如果候选数据的量不大而且相对稳定可以在函数组里定义一个带缓冲的全局内表做内存缓存第一次查完之后后续调用直接用。但要注意缓存的有效期和并发问题不是所有场景都适用。5.4 常见问题速查表把上面的经验压缩成一张表出问题的时候先扫一遍问题现象先查什么再查什么F4 出的还是标准列表搜索帮助第一屏的出口字段搜索帮助是否重新激活断点不进出口函数调用方挂的是不是同一个搜索帮助屏幕字段上的 F4 优先级出口进去但列表为空SELECT 条件是否处理了 BT/CP语言条件、客户端条件是否漏了选中后没有返回值参数是否勾了 EXPORT参数映射是否和调用界面字段匹配附加字段带回来是空的EXIT 步骤有没有真正追加条目追加的 FIELDNAME 是否是 EXPORT 参数名出口改完没反应重新激活搜索帮助清掉本地缓存再测多选时描述串行主字段行数和附加字段行数是否相同追加顺序是否与选中顺序一致用户能看到不该看的数据出口里有没有做 AUTHORITY-CHECK权限对象是否配到了对应角色权限这一条单独提一句。在出口里做权限校验的正确做法是在 SELECT 步骤里先做 AUTHORITY-CHECK没权限就直接让 RECORD_TAB 保持为空用户看到的是没有匹配值而不是无权限的报错。前者体验更好也不会暴露系统的权限设计。当然如果业务上需要明确告知那就把提示信息放进列表的一行里比弹错误框温和。6. 命名、传输与后续维护6.1 命名与对象清单一个带出口的搜索帮助实际涉及的对象比想象中多搜索帮助本身、出口函数、函数组如果新建、选择方法用的表或视图、可能还有数据元素。上线前我会列个清单逐个确认避免传输的时候漏了某个对象导致生产环境报对象不存在。命名上我的习惯是搜索帮助叫ZSH_业务对象_场景出口函数叫ZF4_EXIT_业务对象_场景视图叫ZV_业务对象_用途。名字里带上场景很重要因为同一个业务对象往往有多个搜索帮助按工厂查、按客户查、按销售组织查名字分不清后面全乱。函数组的划分见仁见智。我倾向于按业务模块建组比如ZFG_SD_F4、ZFG_MM_F4而不是所有模块共用一个。共用的后果是权限和传输粒度都对不上——销售改一个出口把采购的传输请求也带上了。6.2 传输与激活顺序传输的时候出口函数和搜索帮助通常会自动进同一个请求但如果有视图、表这些对象建议拆成多个请求按依赖顺序传先传表和视图再传函数组和函数最后传搜索帮助。这样即使中间某一步失败也能定位到具体是哪一层的问题。生产环境激活后一定要实测。我遇到过一次开发机好好的传到生产后 F4 出不来数据查了半天发现是生产环境缺少某张文本表的数据配置数据没跟着传。这类问题跟代码无关但表现和代码 bug 一模一样如果没有上线后实测这一步等用户报上来就更被动了。还有一点是激活顺序在多人协作时的坑。两个人同时改同一个搜索帮助的不同部分后激活的把先激活的覆盖掉这是很常见的事故。所以改公共搜索帮助之前先在群里问一句有人在动 ZSH_XXX 吗比事后追查省事得多。6.3 什么时候该换赛道最后说个现实问题。SE11 搜索帮助这套机制是为经典 dynpro 界面设计的在 Fiori 或 Web 场景下基本用不上。新项目如果走的是 CDS 视图加注解的方式值帮助应该用 CDS 的 value help 定义配合Consumption.valueHelpDefinition之类的注解来做前台自动渲染比 SE11 这套省心很多。这时候还硬上 search help exit属于用错了工具。但老系统改造的现实是大量存量代码还是 dynpro屏幕上几百个字段挂着 SE11 搜索帮助短期不可能全迁。这种情况下我的策略是新需求优先用 CDS value help存量搜索帮助只做必要维护不做大规模重构。真要重构也是跟着业务模块的改造节奏走而不是单独为了技术先进去动它。我自己在实际操作中的体会是搜索帮助出口这类框架约定型的开发最难的不是写代码而是搞清楚框架在什么时候调用你、给了你什么、期望你返回什么。把这几个问题搞清楚之后剩下的都是常规 ABAP。反过来如果跳过这一步直接抄代码那必然会在某个步骤上卡住而且卡住的时候连该看哪儿都不知道。所以我现在的习惯是每建一个新出口先在函数里把callcontrol-step打出来看一眼实际调用的顺序确认清楚之后再往里填逻辑这几分钟的功夫能省掉后面几个小时的排查。
