When using a self-development program to process business logic, the process is usually a black box, and business consultants and business users do not know how the program is run, rely on documentation and frequent communication to confirm the situation.
Brfplus can be configured to implement business logic, so that business people in the implementation of the business logic in their own hands, in addition, the existence of tracking (tracing) function makes the implementation of business logic applications also become clearly visible.
This article link: www.cnblogs.com/hhelibeb/p/9556478.html
Objective
The trace pattern has the following uses:
- Helps to find out why the brf+ application run results are inconsistent with expectations.
- To understand the effects and risks of rules adjustment by counting the usage of the rules.
- The distribution of statistical output results.
Tracking information can help people understand the actual performance of the business, determine which scenarios are common, which are accidental or even never occur, and further optimize the business logic implementation.
Realize
While the tracking pattern can be used to service the business, the implementation is partially related to ABAP because the brf+ application needs to be called through the ABAP code.
I created a simple brf+ application that, based on the purchase order number entered, queries the purchase group and the purchase order type in the database table Ekko, depending on the combination of the two fields, to determine whether approval is required. Involves 2 expressions, one is database lookup (DB Lookup), and the other is a decision table (decision tables)
Call
ABAP calling code,
ReportZtest_brf3.PARAMETERS: P_ebelnTYPEEbeln.start-of-selection.*get a function instanceDATA(lo_fuction) =CAST cl_fdt_function (cl_fdt_factory=if_fdt_factory~get_instance ()->get_function ('005056A4CCA61ED8AAF183894A92CC2B' ) ).*Get a Context instanceDATA(lo_context) =CAST Cl_fdt_context (lo_fuction-If_fdt_function~get_process_context ()).*Enter the purchase order number into the contextLo_context->if_fdt_context~set_value (: Iv_name='Ebeln'Ia_value =P_ebeln).*processing, getting results and tracking dataLo_fuction->if_fdt_function~process (ExportingIo_context =Lo_context Iv_trace_mode= if_fdt_constants=>Gc_trace_mode_leanImportingEo_result =DATA(lo_result) eo_trace=DATA(Lo_trace)).
As shown in the code, the tracking mode can be controlled by the Iv_trace_mode parameter of the If_fdt_function~process method . Trace information is stored in the system database and can be viewed at any point in time. The trace feature only writes the least amount of data to the system database. This is done by recording object references and data changes instead of explicitly writing down all available information about a given object at a specific point in time. This policy makes database content less and reduces the negative performance impact.
If you want to get trace results directly in memory, you can see it in the property If_fdt_lean_trace~mts_record that returns the object Lo_trace
The ID is the id,parent_id of each object in the brf+ application to represent the hierarchical relationship between them, and the REF field is a reference to the value of the result of each step's run.
Read and display of traces
You can add some code to get the description text of the Brf+ object corresponding to the ID, making the tracking record more readable:
DATA: Lo_admin_dataTYPE REF toCl_fdt_admin_data, Id_initialTYPEIf_fdt_types=>id VALUE '00000000000000000000000000000000'. Data:l_resultTYPE string.Field-symbols: <data>TYPEAny .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 atLo_fdt_trace->if_fdt_lean_trace~mts_record into DATA(Ls_record). DATA(l_id) = CONV If_fdt_types=>id (ls_record-ID).IFl_id <>id_initial.*Query the type of the Brf+ object and get a descriptionLo_brf_query->Get_object_type (Exportingiv_id =l_idImportingEv_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 (ImportingEv_text=DATA(DESC)). out-begin_section (DESC). ASSIGNls_record-ref->* to<data>. IF<data> isASSIGNED. out->write (<data> ). ENDIF. ENDIF.Endloop. Lo_result->get_value (ImportingEa_value =l_result). out->begin_section ('Results'). out-Write (L_result). Out->display ().
Run the program again and you can see that
This is just a simple example, the effect is far less than the Brf+ Workbench's trace results output,
If you want to achieve a better track record output, try using the front-end class library. Of course, the actual application is on-demand, perhaps you just need to get a trace of the results of a piece of data, and then show or store it in the database.
Apply tracking Mode level
You can see the trace levels and their descriptions in the constants of the interface if_fdt_constants.
Commonly used are lean trace and technical trace,
- In lean trace mode, the system only records those steps that directly lead to the end of the process. For example, if a program contains a case statement where the input value can be tested against five different values, and only the last attempt can match the result, the lean trace does not log four unsuccessful attempts, only the fifth attempt is recorded .
- Instead, thetechnical trace Records each step of the process, regardless of whether the step is causing the process to end. For example, if a program traverses 20 different steps and finally proves that this is the wrong path, you can see the entire process in technical trace mode, and these steps will not be displayed in Lean trace mode.
Technical Trace causes the brf+ app to run in interpreted mode and should not be used in a production environment.
Flexible control of trace levels with parameter ID
Readers with SAP CRM development experience may know that in CRM, you can set the parameter ID to control whether the detailed technical information for a message is presented in the Web UI interface. This is a flexible control, and we can also apply it to the control of the brf+ tracking mode.
Maintenance Tpara in transaction code SM30
Create a new Set/get PARAMETER
Maintain it in the transaction code SU3,
Gets and determines the value of the parameter ID in the code to determine the calling method,
DATA: L_traceTYPEC LENGTH1. GET PARAMETER ID 'Zbrf_trace' FIELDL_trace. IFL_trace =0. Lo_fuction-if_fdt_function~process (ExportingIo_context =Lo_contextImportingEo_result =DATA(Lo_result)). ELSE. Lo_fuction-if_fdt_function~process (ExportingIo_context =Lo_context Iv_trace_mode= if_fdt_constants=>Gc_trace_mode_leanImportingEo_result =Lo_result Eo_trace=DATA(Lo_trace)). ENDIF.
Other
It is important to note that the use of the trace feature has a precondition that the brf+ object is all versioned, or that the timestamp of the Brf+ object is earlier than the timestamp of the trace. Because the parsing of the trace data depends on the metadata of the Brf+ object. If the Brf+ object has changed before and after the trace, determine the Brf+ object at the time of the trace based on the version or timestamp.
Reference content:
Tracing in SAP decision Service Management
SAP Document
Trace Mode in brf+