個人BRF+自學教程（二）：跟蹤模式（trace mode）

使用自開發程序來處理業務邏輯時，處理過程一般是個黑箱，業務顧問和業務用戶不知道程序的具體運行方式，要依賴文檔和頻繁的溝通來確認實際狀況。

BRFplus能夠經過配置的方式實現業務邏輯，使得業務人員把業務邏輯的實現掌握在本身手中，此外，跟蹤（tracing）功能的存在使得業務邏輯應用的執行狀況也變得清晰可見。

 

本文連接：http://www.javashuo.com/article/p-rgazwduy-bt.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+