ABAP 主调程序动态获取被调程序ALV数据列表的三种实现方式

1. 为什么需要动态获取另一个程序的ALV数据在SAP的日常开发中经常会遇到一个挺有意思的场景程序A主调程序需要获取程序B被调程序里已经展示在ALV报表上的数据然后对这些数据进行二次处理、分析或者传递给其他模块。你可能会问为什么不直接在程序B里把逻辑都写完呢或者为什么不把数据查询逻辑做成一个通用的函数模块让两个程序都去调用呢在实际项目 里情况往往更复杂。比如业务部门已有一个运行了好几年的成熟报表程序逻辑复杂权限检查、数据筛选、格式控制都做得非常完善。突然有一天他们提出一个新需求需要基于这个报表的数据做一个自动化的数据核对或者批量修改功能。这时候如果去修改原有的报表程序风险很高可能会影响到其他依赖它的业务流程。最稳妥、最快捷的办法就是新写一个程序主调程序让它去“借用”老程序被调程序已经准备好的、并且经过用户筛选和确认的ALV数据。这就是CL_SALV_BS_RUNTIME_INFO这个类大显身手的时候了。它就像一个“数据捕手”能在被调程序运行ALV展示的瞬间把准备要显示的数据“截获”下来然后传递给主调程序。这样做的好处显而易见代码复用性高你无需重复编写复杂的数据获取逻辑风险低不侵入原有稳定程序灵活性好主调程序可以专注于新的业务处理。接下来详细聊聊实现这个目标的三种主流方法。2. 基础引用法最直接的数据抓取基础引用法顾名思义就是最基础、最直接的一种获取方式。它的核心思想是先告诉系统“我要抓数据了”然后运行目标程序最后从系统缓存里把数据引用拿过来。这种方法最适合被调程序的ALV输出结构固定、且主调程序明确知道这个结构的场景。2.1 核心三步曲SET、GET、CLEAR第一步SET - 设置捕获模式 这是最关键的准备动作。你需要使用CL_SALV_BS_RUNTIME_INFOSET方法告诉SAP内核“接下来运行的ALV请不要真的显示出来而是把它的数据和元信息准备好放在某个地方等我取。” 这里有几个参数需要特别注意DISPLAY ABAP_FALSE 这个最重要意思是“不要显示ALV界面”。如果设为ABAP_TRUE被调程序就会正常弹出ALV屏幕流程就中断了。METADATA ABAP_FALSE 是否获取字段目录等元数据。在基础引用法里我们只关心数据本身所以通常设为False。如果你想动态分析ALV有哪些字段可以设为True。DATA ABAP_TRUE 必须设为True表明我们需要获取数据。 1. 设置运行时信息准备捕获数据CALL METHOD cl_salv_bs_runtime_infosetEXPORTINGdisplay abap_false 不显示ALVmetadata abap_false 不获取元数据data abap_true. 要获取数据第二步GET - 提交并获取数据引用设置好之后就可以用SUBMIT语句来运行被调程序了。SUBMIT会让被调程序在后台执行当它执行到ALV显示函数如REUSE_ALV_GRID_DISPLAY时由于我们设置了DISPLAY ABAP_FALSE函数不会弹出界面而是将数据存入一个全局的缓冲区后直接返回。紧接着我们立刻用CL_SALV_BS_RUNTIME_INFOGET_DATA_REF方法去缓冲区里把数据的引用拿回来。 运行被调程序SUBMIT z_alv_lhy AND RETURN.TRY. 2. 从缓冲区获取数据的引用DATA ref_to_data TYPE REF TO data.CALL METHOD cl_salv_bs_runtime_infoget_data_refIMPORTINGr_data ref_to_data. 这是一个指向内表的通用引用CATCH cx_salv_bs_sc_runtime_info INTO DATA(lx_exception). 异常处理比如可能因为超时或未找到数据而失败MESSAGE lx_exception-get_text( ) TYPE E.ENDTRY.这里拿到的ref_to_data是一个泛型的引用它指向一个标准内表但具体是什么结构我们还不知道。第三步CLEAR - 清理现场与数据转换数据拿到后一个好习惯是立刻清理运行时信息缓冲区避免对后续其他可能使用该类的操作造成干扰。然后我们需要把泛型引用转换成具体可用的内表。 3. 清除运行时信息设置CALL METHOD cl_salv_bs_runtime_infoclear_all. 将通用引用赋值给一个字段符号Field SymbolFIELD-SYMBOLS lt_alv_data TYPE STANDARD TABLE.ASSIGN ref_to_data-* TO lt_alv_data.IF lt_alv_data IS ASSIGNED. 现在可以遍历 lt_alv_data 了 但它的行结构是动态的我们需要用 ASSIGNING 和 MOVE-CORRESPONDING 来转换LOOP AT lt_alv_data ASSIGNING FIELD-SYMBOL(ls_line). 假设我们预先知道被调程序ALV的结构DATA ls_my_structure TYPE ty_alvshow. 这个类型必须和被调程序ALV内表的结构一致MOVE-CORRESPONDING ls_line TO ls_my_structure. ... 对 ls_my_structure 进行处理ENDLOOP.ENDIF.2.2 实战中的坑与优化看起来很简单对吧但可没少踩坑。最大的一个坑就是结构匹配问题。MOVE-CORRESPONDING是按字段名匹配的如果主调程序定义的结构ty_alvshow和被调程序ALV实际的内表结构在字段名、类型、长度上不完全一致数据就会错位或者丢失。有一次因为一个日期字段的类型一个是DATS一个是TIMESTAMP导致整列数据都乱了。所以在使用基础引用法前一定要去被调程序里确认它传递给ALV函数的内表具体是什么结构最好直接把它的类型定义复制过来。如果被调程序不是自己开发的可以用SE11或SE80查看其内表定义。另外异常处理很重要。GET_DATA_REF可能会抛出CX_SALV_BS_SC_RUNTIME_INFO异常比如被调程序执行超时、或者它根本没有使用标准的ALV函数来显示比如用了OO ALV但没正确设置。不加TRY-CATCH程序就会短dump。3.动态字段映射法应对未知的ALV结构基础引用法要求“知己知彼”但现实中常常需要调用一个第三方或结构经常变动的程序无法预先知道其ALV的完整结构。这时候动态字段映射法就派上用场了。这种方法的核心是不仅获取数据还获取数据的“蓝图”元数据然后动态地创建匹配的数据对象来处理它。3.1 同时获取数据与元数据和基础法相比第一步的SET设置需要调整我们要把元数据也一并请求过来 设置以获取数据和字段元数据CALL METHOD cl_salv_bs_runtime_infosetEXPORTINGdisplay abap_falsemetadata abap_true 关键设为True以获取字段目录data abap_true.运行SUBMIT之后我们除了获取数据引用还需要获取字段目录引用。SUBMIT z_dynamic_alv AND RETURN.DATA: ref_to_data TYPE REF TO data,ref_to_components TYPE REF TO data.TRY. 获取数据引用CALL METHOD cl_salv_bs_runtime_infoget_data_refIMPORTINGr_data ref_to_data. 获取字段目录引用CALL METHOD cl_salv_bs_runtime_infoget_metadata_refIMPORTINGr_metadata ref_to_components.CATCH cx_salv_bs_sc_runtime_info INTO DATA(lx_error). 处理异常ENDTRY.CALL METHOD cl_salv_bs_runtime_infoclear_all.3.2 解析元数据并动态处理拿到字段目录的引用后我们需要将其转换为一个具体的内表来查看。字段目录通常是一个LVC_T_FCAT类型或者SLIS_T_FIELDCAT_ALV的内表。FIELD-SYMBOLS: lt_fcat TYPE lvc_t_fcat. ASSIGN ref_to_components-* TO lt_fcat. IF lt_fcat IS ASSIGNED. 现在 lt_fcat 里包含了所有字段的定义字段名、描述、数据类型、长度等 我们可以动态地根据这些信息来创建结构或者直接处理数据 ENDIF.有了字段目录有两种主要的动态处理思路思路一动态创建结构并转换数据 这种方法比较彻底适合需要对数据进行复杂操作或持久化保存的场景。你可以遍历字段目录使用RTTC运行时类型创建相关类如CL_ABAP_STRUCTDESCR, CL_ABAP_TABLEDESCR动态创建一个和被调程序ALV内表完全一致的数据类型然后用它来创建数据对象并转换数据。这种方法功能强大但代码稍复杂。思路二直接基于字段符号进行通用操作 对于很多场景比如只是简单筛选、计数、或导出到文件我们可能不需要一个具体的结构。我们可以直接使用字段符号来访问动态数据的每一行。FIELD-SYMBOLS: lt_data TYPE STANDARD TABLE, ls_line TYPE any, lv_field TYPE any. ASSIGN ref_to_data-* TO lt_data. CHECK lt_data IS ASSIGNED. LOOP AT lt_data ASSIGNING ls_line. 假设我们想打印每一行的第一个字段的值 首先从字段目录获取第一个字段的名称 READ TABLE lt_fcat INDEX 1 ASSIGNING FIELD-SYMBOL(ls_fcat). IF sy-subrc 0. ASSIGN COMPONENT ls_fcat-fieldname OF STRUCTURE ls_line TO lv_field. IF sy-subrc 0. WRITE: / lv_field. ENDIF. ENDIF. 也可以根据业务逻辑动态检查某个特定字段名的值 ASSIGN COMPONENT VBELN OF STRUCTURE ls_line TO lv_field. IF sy-subrc 0 AND lv_field 0000000123. 找到特定单据进行后续处理 ENDIF. ENDLOOP.这种方法非常灵活你不需要预先知道所有字段只需要关心你业务逻辑中需要用到的那些字段名即可。字段目录lt_fcat就是你探索未知数据结构的“地图”。4. 异常处理与性能优化实践无论用哪种方法健壮性和效率都是必须考虑的。这部分内容往往是新手最容易忽略但却是生产环境稳定运行的关键。4.1 构建坚固的异常处理框架直接调用SUBMIT和CL_SALV_BS_RUNTIME_INFO的方法可能会遇到多种异常不能简单地用一个TRY-CATCH包住就了事。1. 超时异常 (CX_SALV_BS_SC_RUNTIME_INFO) 这是最常见的异常之一。被调程序可能因为数据量巨大、逻辑复杂而运行超时。一旦超时GET_DATA_REF就会抛出异常。处理方式可以是记录日志、通知用户并考虑是否优化被调程序或分批次处理。2. 数据未就绪异常 有时因为被调程序的执行路径问题比如有条件分支跳过了ALV生成部分缓冲区里根本没有数据。GET_DATA_REF会抛出异常。我们应该检查异常文本并给用户明确的提示比如“目标程序未产生列表数据”。3.内存不足异常。 如果被调程序ALV数据量极大在获取引用或后续处理时可能引发内存不足CX_SY_MEMORY_ALLOCATION_ERROR。对于处理大数据量的场景一定要在代码中加入内存检查并考虑分页获取数据的策略而不是一次性抓取全部。一个相对完整的异常处理段落看起来是这样的DATA: lv_subrc TYPE sy-subrc. CALL METHOD cl_salv_bs_runtime_infoset EXPORTING display abap_false metadata abap_true data abap_true. lv_subrc 0. 使用SUBMIT ... AND RETURN 并捕获可能的系统异常 TRY. SUBMIT z_target_program VIA SELECTION-SCREEN AND RETURN. CATCH cx_root INTO DATA(lx_submit_error). lv_subrc 4. 记录错误日志 lx_submit_error-get_text( ) ENDTRY. IF lv_subrc 0. TRY. CALL METHOD cl_salv_bs_runtime_infoget_data_ref IMPORTING r_data ref_to_data. CALL METHOD cl_salv_bs_runtime_infoget_metadata_ref IMPORTING r_metadata ref_to_components. CATCH cx_salv_bs_sc_runtime_info INTO DATA(lx_salv_error). 专门处理ALV运行时信息异常 MESSAGE i398(00) WITH 获取ALV数据失败: lx_salv_error-get_text( ). RETURN. CATCH cx_sy_create_data_error INTO DATA(lx_create_error). 处理动态创建数据对象时的错误 MESSAGE i398(00) WITH 处理数据时发生错误: lx_create_error-get_text( ). RETURN. ENDTRY. ENDIF. 无论成功与否最后都执行清理 CALL METHOD cl_salv_bs_runtime_infoclear_all.4.2 提升性能的关键技巧当被调程序数据量很大时性能可能成为瓶颈。这里有几个我实践过的优化点1. 精准控制被调程序的输出 不要在被调程序里SELECT *然后全部输出。主调程序应该在调用前通过SUBMIT语句的WITH SELECTION-TABLE参数或者如果被调程序支持通过内存ID(EXPORT/IMPORT)传递更精确的选择条件让被调程序只查询和准备必要的数据。从源头上减少数据量是最有效的优化。2. 避免不必要的元数据获取 如果你使用基础引用法并且明确知道结构那么在SET时一定要将METADATA设为ABAP_FALSE。获取字段目录尤其是复杂的ALV是有开销的。3. 及时清理与引用释放 在数据处理完毕后除了调用CLEAR_ALL还要及时清空自己定义的字段符号(UNASSIGN)和引用变量。对于动态创建的大型内表如果不再使用可以将其赋初始值(CLEAR)并尝试触发垃圾回收虽然ABAP的GC是自动的但显式清空大对象有助于内存管理。4. 考虑异步与后台处理 对于极其耗时的操作可以考虑将主调程序本身设置为后台作业。或者更高级的做法是将被调程序的执行和数据获取过程封装到一个可后台执行的函数模块或类方法中主调程序通过作业调度来触发并后续读取结果。这能极大改善前端用户的体验。5. 三种方法对比与选型指南到这里我们已经详细探讨了三种方法。为了方便你在实际项目中快速选型我总结了一个对比表格并附上我的选型建议。选型经验分享新手入门或处理稳定内部程序毫不犹豫选择基础引用法。它简单可靠不容易出错能满足80%的跨程序数据获取需求。先把这种用熟。面对“黑盒”程序或需要通用工具必须使用动态字段映射法。比如你需要写一个通用的ALV数据导出工具或者对接其他团队开发的、文档不全的程序。这时动态能力是唯一选择。无论用哪种都必须加上“异常处理优化”我把这看作是一种必备的编程习惯而不是一个可选项。特别是当你开发的程序会给其他用户或系统使用时健壮性远比那一点点性能提升重要。生产环境的一个短DUMP带来的损失远超你多写几十行异常处理代码的代价。最后一点心得体会CL_SALV_BS_RUNTIME_INFO虽然强大但它毕竟是一种“拦截”机制依赖于标准ALV函数的执行流程。如果被调程序使用了完全自定义的屏幕输出或者非标准的OO ALV调用方式比如没有通过CL_SALV_TABLE等标准类这个方法可能会失效。因此在决定采用这个方案前最好先检查一下被调程序的实现方式。如果条件允许与被调程序的开发者沟通建立一个标准的函数接口来传递数据往往是更优雅、更稳定的长期解决方案。但在紧急需求、处理遗留系统或者没有修改权限时本文介绍的这三种方法绝对是你的得力工具。