使用自开发程序来处理业务逻辑时，处理过程通常是个黑箱，业务顾问和业务用户不知道程序的具体运行方式，要依赖文档和频繁的沟通来确认实际情况。
BRFplus可以通过配置的方式实现业务逻辑，使得业务人员把业务逻辑的实现掌握在自己手中，此外，跟踪（tracing）功能的存在使得业务逻辑应用的执行情况也变得清晰可见。
本文链接：https://www.cnblogs.com/hhelibeb/p/9556478.html
目的
跟踪模式有以下用处：
- 有助于找到BRF+应用运行结果与预期不一致的原因。
- 统计各规则的使用情况，从而理解规则调整的影响和风险。
- 统计输出结果的分布情况。
跟踪信息可以帮助人们进一步理解业务的实际执行情况，确定哪些场景是常见的、哪些是偶然的甚至永不出现的，从而进一步优化业务逻辑实现。
实现
虽然跟踪模式可以服务业务，但是因为BRF+应用需要通过ABAP代码来调用，所以实现部分会是和ABAP相关的内容。
我创建了一个简单的BRF+应用，其功能是根据输入的采购订单编号，到数据库表EKKO中查询采购组和采购订单类型，根据这两个字段的组合，来决定是否需要审批。涉及到2个表达式，1个是数据库查找（DB lookup），还有一个是决策表（decision table）
调用
ABAP调用代码，
REPORT ztest_brf3. PARAMETERS: p_ebeln TYPE ebeln. START-OF-SELECTION. *获取function实例
DATA(lo_fuction) = CAST cl_fdt_function(
cl_fdt_factory=>if_fdt_factory~get_instance(
)->get_function( '005056A4CCA61ED8AAF183894A92CC2B' ) ). *获取context实例
DATA(lo_context) = CAST cl_fdt_context(
lo_fuction->if_fdt_function~get_process_context( ) ). *将将采购订单号输入到context
lo_context->if_fdt_context~set_value(
: iv_name = 'EBELN' ia_value = p_ebeln ) . *处理，获取结果和跟踪数据
lo_fuction->if_fdt_function~process(
EXPORTING io_context = lo_context
iv_trace_mode = if_fdt_constants=>gc_trace_mode_lean
IMPORTING eo_result = DATA(lo_result)
eo_trace = DATA(lo_trace) ).
如代码所示，可以通过IF_FDT_FUNCTION~PROCESS方法的IV_TRACE_MODE参数控制跟踪模式。跟踪信息会存储在系统数据库中中，可以在任何时间点进行查看。 跟踪功能仅将最少的数据写入系统数据库。 这是通过记录对象引用和数据更改而不是在某个特定时间点显式写下有关给定对象的所有可用信息来实现的。 此策略可使数据库内容较少，并降低性能上的负面影响。
如果要在内存中直接获得跟踪结果，可以在返回对象lo_trace的属性IF_FDT_LEAN_TRACE~MTS_RECORD中看到
ID是BRF+应用中的各个对象的ID，PARENT_ID用来表示它们间的层级关系，REF字段则是各步骤的运行结果的值的引用。
跟踪的读取和显示
可以增加一些代码，获取ID对应的BRF+对象的描述文本，让跟踪记录的可读性更好些：
DATA: lo_admin_data TYPE REF TO cl_fdt_admin_data,
id_initial TYPE if_fdt_types=>id VALUE ``. data: l_result TYPE string. FIELD-SYMBOLS: <data> TYPE any. DATA(lo_fdt_trace) = CAST cl_fdt_trace( lo_trace ). DATA(lo_brf_query) = CAST if_fdt_query( cl_fdt_factory=>get_instance( )->get_query( ) ). DATA(out) = cl_demo_output=>new( ). LOOP AT lo_fdt_trace->if_fdt_lean_trace~mts_record INTO DATA(ls_record). DATA(l_id) = CONV if_fdt_types=>id( ls_record-id ). IF l_id <> id_initial. *查询BRF+对象的类型，并获取描述
lo_brf_query->get_object_type(
EXPORTING iv_id = l_id
IMPORTING ev_object_type = DATA(l_type) ). lo_admin_data = NEW #(
iv_id = l_id
iv_object_type = l_type ). lo_admin_data->if_fdt_admin_data~get_texts(
IMPORTING
ev_text = DATA(desc) ). out->begin_section( desc ).
ASSIGN ls_record-ref->* TO <data>.
IF <data> IS ASSIGNED.
out->write( <data> ).
ENDIF. ENDIF. ENDLOOP. lo_result->get_value( IMPORTING ea_value = l_result ). out->begin_section( '结果' ). out->write( l_result ). out->display( ).
再次运行程序，可以看到，
这只是个简单示例，效果远远不如BRF+工作台的跟踪结果输出，
如果想要实现更好的跟踪记录输出效果，可以试试使用前端类库。当然实际的应用情况是按需的，也许你只需要获取到跟踪结果中的某一条数据，然后展示或者把它存储到数据库里。
应用
跟踪模式级别
在接口IF_FDT_CONSTANTS的常量中可以看到跟踪级别和它们的描述，
其中常用的是lean trace和technical trace，
- 在lean trace模式下，系统只记录直接导致过程结束的那些步骤。 例如，如果程序包含CASE语句，其中输入值可以针对五个不同的值进行测试，并且只有最后一次尝试可以匹配到结果，则lean trace不会记录四次不成功的尝试，只会记录第五次尝试。
- 相反，technical trace则记录了流程的每个步骤，无论步骤是导致过程结束。 例如，如果程序遍历20个不同的步骤，最后证明这是错误的路径，则在technical trace模式下可以看到整个过程，而在lean trace模式下这些步骤不会被显示。
technical trace会使BRF+应用在解释模式下运行，不应在生产环境下使用该模式。
使用parameter ID来灵活的控制跟踪级别
有SAP CRM开发经验的读者可能知道，在CRM中，可以通过设置parameter ID来控制消息的详细技术信息是否在Web UI界面展示。这是一种灵活的控制方式，我们也可以把它应用在BRF+跟踪模式的控制上。
在事务代码SM30维护TPARA
创建新的SET/GET PARAMETER
在事务代码SU3中维护它，
在代码中获取并判断PARAMETER ID的值，从而决定调用方式，
DATA: l_trace TYPE c LENGTH .
GET PARAMETER ID 'ZBRF_TRACE' FIELD l_trace. IF l_trace = .
lo_fuction->if_fdt_function~process(
EXPORTING io_context = lo_context
IMPORTING eo_result = DATA(lo_result) ).
ELSE.
lo_fuction->if_fdt_function~process(
EXPORTING io_context = lo_context
iv_trace_mode = if_fdt_constants=>gc_trace_mode_lean
IMPORTING eo_result = lo_result
eo_trace = DATA(lo_trace) ).
ENDIF.
其它
需要注意的是，跟踪功能的使用存在前提条件，那就是BRF+对象全部版本化，或者BRF+对象的时间戳早于跟踪的时间戳。因为跟踪数据的解析依赖于BRF+对象的元数据。如果在跟踪的前后BRF+对象已经发生了变化，那么要依据版本或时间戳来确定跟踪时的BRF+对象的情况。
参考内容：