Skip to Content

Use DB table logs for the function parameter

When we implement the SAP ERP project, we often develop the RFC function to provide data services for the non-sap system. This program design to provide log function in the RFC Function Module.

Source code url: GitHub – gaovv2000/ABAP-log4function: logs for the function parameter and result

  1. Create the DB table of logs header,the name is “ZTBCLOGS_RLGK”, and activate it./wp-content/uploads/2016/06/1_980360.jpg
  2. Create the DB table of logs contant, the name is “ZTBCLOGS_RLGD”, and activate it./wp-content/uploads/2016/06/2_980361.jpg
  3. Create the DB table to set enable the log function, and activate it./wp-content/uploads/2016/06/3_980362.jpg
  4. Create the DB structure for report show data, Name is “ZSFUNCPARAS”, and activate it. /wp-content/uploads/2016/06/4_980369.jpg
  5. Use transaction code SE38 to create the include program, the name is ‘ZBCLOGSINC’.
  6. Use transaction code SE38 to create the executable program, the name is ‘ZBCLOGSREP’.
  7. Copy the code into the corresponding program, And then activate them.
  8. When you want to record the data for function parameter, Just goto function group “TOP include” program to  insert a row statements and in function module call a macro. Goto “Top Include” program Insert “include” statement./wp-content/uploads/2016/06/8_980370.jpg/wp-content/uploads/2016/06/8_2_980371.jpg
  9. Call the marco at the Function Module first row.                                                                                          /wp-content/uploads/2016/06/8_3_980372.jpg
  10. Set DB table “ZTBCLOGS_ACT” to enable log function./wp-content/uploads/2016/06/9_980373.jpg
  11. Excute the Function Module to test the function./wp-content/uploads/2016/06/10_980374.jpg
  12. Use the transaction code  SE11 to view the data ./wp-content/uploads/2016/06/11_980375.jpg
  13. We have a reporting program “ZBCLOGSREP”,  more easily view the logging contents.So let’s goto the transaction code SE38 to try it ./wp-content/uploads/2016/06/12_1_980376.jpg/wp-content/uploads/2016/06/12_2_980377.jpg /wp-content/uploads/2016/06/12_3_980378.jpg /wp-content/uploads/2016/06/12_4_980379.jpg /wp-content/uploads/2016/06/12_5_980390.jpg /wp-content/uploads/2016/06/12_6_980391.jpg
You must be Logged on to comment or reply to a post.
    • I would recommend to use standard LOG-POINT instead.

    • I understand Application Log records the message that resembles bapiret2 contents, customers want to record inbound Function Module parameter data, when an error occurs, easy to diagnose source of error from which system .

  • I don't understand the business case. Why should we trace parameters all the time, at least there should be an external switch to activate/deactivate the trace. (table “ZTBCLOGS_ACT”  to set the switch .)

    Usually, in case there's a problem, a simple external debug is sufficient (from there it's also possible to save the parameters as a standard test data, that you may then play from SE37).

  • This resembles the "FBGENDAT" functionality of the ERP MM BAPIs (e.g. BAPI_PO_CREATE1), see note 539978, automatic generation of BAPI test data directory.

    It seems as if it could also be implemented into own Z-function modules, have not tried yet. Big advantage is that a SE37 test data directory entry is written, so you can start SE37 and debug using the actual data that was sent via RFC. This comes in handy for very complex interfaces and when the RFC-user is not a dialog user, so cannot be used for debugging.

    What it is missing there is a nice list like yours displaying all the test data that has been written, so maybe you can combine the two benefits somehow?