使用自開發程式來處理業務邏輯時，處理過程通常是個黑箱，業務顧問和業務使用者不知道程式的具體運作方式，要依賴文檔和頻繁的溝通來确認實際情況。
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
SAP Document
Trace mode in BRF+