Technical Articles
abap-fm-logger: A tool to trace the Function Module (RFC) parameters
Many SAP systems provide some Remote-Enabled Function Modules (RFC) as interfaces to external systems. To trace the issues of system integration. We often need log tables to store the exporting/importing parameters’ values..
It is a dull work to create lots of log tables for FM. And given the complex and interdependent nature of an SAP system, it may be imperative to carefully manage the log code and tables, in order to avoid duplication. And there may be several background jobs to make sure that the outdated logs be archived/cleaned.
To simplify the log work of FM, I created a tool: abap fm logger.
With abap fm logger, we can save logs of different FM in just ONE table. Search logs in a general report program, like this,
The importing/exporting values are not store in separate table fields, but in 4 special fields with JSON format.
We can also reprocess records by log id (like WE19 for IDoc).
And it is very easy to use. Benefit from a unified JSON field format, we don’t need to write special code for the different interface definition. Here is an example,
FUNCTION z_fm.
**initialize logger. It should be always on the top of the FUNCTION.
/afl/log_init.
**optional, you can specify at most 3 fields for search.
/afl/set_custom_fields 'cust field1' 'cust field2' 'cust field3'.
**optional, you can save a status code and message text for search.
/afl/set_status 'S' 'message'.
**save logs. It should be always on the bottom of the FUNCTION.
/afl/save.
ENDFUNCTION.
In the most cases, we may just need two macros /afl/log_init and /afl/save. It is enough.
You can access https://github.com/hhelibeb/abap-fm-logger for more details of abap fm logger and install it by abapGit.
Feel free to comment the tool.
Thanks
Excellent work, this is perfect for my project
Thanks for your continuous support. In fact I'm using it in some new projects and not go-live yet. So if you find any issue or requirement, please tell me :）
UPDATE: I just got a response which indicates that the macros is not necessary. I think it is right. So later I will provide the OO-based interface, and keep the macro interface remaining.
And I also think it is an advantage of the open source: when we do something wrong/right, we can get comments from others to help us understand what we really did.
Initially, I didn't read your blog post because of the title "abap-fm-logger: A general log tool for Function Modules (RFC)", I thought it was yet another general message logger, like https://github.com/epeterson320/ABAP-Logger.
Maybe a title like "rfc-call-logger to trace the RFC parameters" could be more attractive or at least right at the point.
Nice job, thanks !
Make sense. Let me update the title.
An interesting utility.
Thanks for sharing.
Please review also FBGENDAT, a tool developed by SAP sales development team, which allows to generate automatically function test data.
I just review the code in fbgenmac, it is very helpful to develop an oo-based api for abap-fm-logger. Thanks for your help.
By the way, people may wonder whether there is a standard mechanism to trace the values of parameters. There is one, far from being as good as yours: the RFC trace. It can be activated at RFC destination level (SM59), but not at level of RFC function module. In the RFC developer trace, you'll then see the detailed contents of bytes passed in the raw format of the RFC protocol, which can be more or less be interpreted by human. Example after calling RFC_READ_TABLE with parameter QUERY_TABLE='T000':