使用自開發程序來處理業務邏輯時，處理過程通常是個黑箱，業務顧問和業務用戶不知道程序的具體運行方式，要依賴文檔和頻繁的溝通來確認實際情況。
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 `00000000000000000000000000000000`. 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 1. GET PARAMETER ID 'ZBRF_TRACE' FIELD l_trace. IF l_trace = 0. 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+對象的情況。
參考內容：
Tracing in SAP Decision Service Management