As mentioned by title, this blog does not introduce the OData trace functionality itself, but shows the way how to find and figure out the usage of trace functionality by yourself, for example, find the corresponding transaction code or report name to launch the trace.

Actually this approach is not dedicated to gateway but generically applies to any other scenario:

– You have found switch or flag evaluation in some ABAP source code which dynamically controls the enablement of certain functionality. You need to know where and how you can access this switchable function.

For example, in gateway system, I found there are two flags which enable or disable the OData trace:

/wp-content/uploads/2015/07/clipboard1_737412.png

I need to find out how to perform the OData trace by the source code, without any debugging in the runtime.

Step1: perform where-used-list on mv_perf_level:

/wp-content/uploads/2015/07/clipboard2_737413.png

7 hits. Based on experience, I can judge that the line 100 is fill it with value fetched from DB table via open SQL.

Double click the line 100.

/wp-content/uploads/2015/07/clipboard3_737444.png

Step2: Now I found the configuration table which stores the trace configuration information. Perform where-used-list on the table again:


/wp-content/uploads/2015/07/clipboard4_737445.png

The second report, /IWFND/SUTIL_TRACE_CONFIG, is what I am looking for, the one to launch OData trace UI.

/wp-content/uploads/2015/07/clipboard5_737446.png

To verify, simply execute it. And that’s it. After I made the following setting and click save button:

/wp-content/uploads/2015/07/clipboard6_737450.png

There is corresponding entry persisted in the table I found in this step.

/wp-content/uploads/2015/07/clipboard7_737451.png

Step3: I am also curious about at what time the other flag, mv_odata_trace_active, could become true. Still the same approach.

Check the result. Based on experience, only the first method ENABLE_ODATA_TRACE performs the write access on the flag, all the left are read access such as IF mv_odata_trace_active = abap_true. ….

/wp-content/uploads/2015/07/clipboard10_737453.png

Double click on ENABLE_ODATA_TRACE, and we get to know the flag will become true if io_context->debug is true.

/wp-content/uploads/2015/07/clipboard11_737454.png

So now research /IWCOR/IF_DS_CNTXT instead:

/wp-content/uploads/2015/07/clipboard12_737455.png

Again the attribute DEBUG of interface only has the opportunity to be true in the constructor method of the implementation class, all other 41 hits are the read access on it and could be ignored.

/wp-content/uploads/2015/07/clipboard13_737459.png

so perform the where-used-list on constructor method:


/wp-content/uploads/2015/07/clipboard14_737460.png

Here we are very near to the target:

/wp-content/uploads/2015/07/clipboard15_737462.png

Just scroll up, and we get the result. The other flag could only become true when the two prerequisites are met:

1. There is query parameter sap-ds-debug defined in the OData request url.

2. The current user should have debug authorization, that is, should pass the check by function module SYSTEM_DEBUG_AUTHORITY_CHECK.

/wp-content/uploads/2015/07/clipboard16_737464.png

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply