Hi Experts,
I have recently come across a situation, where bad performance of one of my custom developed OData service caused a lot of issues, and where I was forced to think out-of-the-box to come up with ways to perform detailed tracing. And now I want to share these with you guys.
In this blog post I will show some tools for logging and tracing OData calls in the Gateway as well as in the SAP Backend. Furthermore, I will show how OData calls can be captured in the ABAP Runtime Analysis tool (SAT) in the SAP backend for very detailed analysis of all steps being carried out in the backend.
The Runtime Analysis Tool is known by most ABAP developers, but I will show how a capture can be scheduled, so an OData call from a browser can trigger the creation of a measurement for further analysis.
In SAT it is possible to view things like: Which DB tables are being updated, which coding blocks are being called, and how many times, as well as runtime in microseconds for each call, and much more.
SAP Gateway Tracing
When working with SAP gateway OData services, most people come across the two most commonly used transactions for logging and tracing in SAP Gateway.
In environments where the SAP Gateway and the SAP Backend system are in two distinct systems (using a Gateway Hub), these utilities are used on the SAP Gateway Hub (not the backend).
The Error Log is a continuous log, that will display framework errors.
Traces, which are user specific, must be enabled before they can be displayed.
The login user will be selected by default, but other users may be added by using the marked button.
Traces are active for a period of two hours, after which they will automatically be inactivated.
Payload Trace is an excellent tool for displaying the raw OData requests (and responses) being performed on the system.
In case of $batch calls being used one http request may contain multiple OData requests. This makes it harder, in error situations, to pinpoint where the problem is.
In the above call 3 separate GET calls are being carried in one request.
In this view we see the raw data being passed from (request) and to (response) the client.
The corresponding Performance Trace display the 3 GetEntitySet calls, but with no details from the backend. Only the total processing time for each call
SAP Backend
In the backend system there are 2 similar utilities for logging and tracing.
These will show similar info from the SAP Gateway framework, but in the backend system.
Note:
I have found that, on older SAP versions, these may not start properly from the startscreen, but for some weird reasons they can be started from SE93 or by adding them as favorites.
It is important to understand the way the Gateway framework works, to understand what we can use these tools for. When the SAP Gateway receives an OData request from a client it validates and de-serialize the JSON request data into ABAP data. Then it identifies which Backend system the call should be routed to and calls the backend system via an RFC (function module), passing data in a mapped format. On the backend system, the Data Provider Class is called to execute the request.
The Backend Traces can be enabled the same way as on the SAP Gateway.
In the backend Payload Trace we will see separate measures for each OData call contained in $batch multi requests. This will give us a little more detailed info than we got on the SAP Gateway. Requests of type $batch with only a single measure in this list contains only one OData request.
When the payload is examined, we will now see request payloads in XML format. This is the data format being passed to the RFC Function Module from the SAP Gateway, after the json request has been deserialized.
In the Performance Trace, we will also see distinct measures for each OData sub request of a $batch request containing multiple requests.
By double clicking an entry we can examine the path to the Data Provider Class executing the request call.
But still we cannot get detailed analysis data on what is happening in the Data Provider Class.
ABAP Runtime Analysis (SAT)
To get very detailed runtime analysis data, of what actions are being performed in the Data Provider Class we can use the ABAP Runtime Analysis tool.
This is done in transaction SAT in the backend system.
In SAT you can analyze code being executed from a Transaction, Program or a Function Module. In Gateway context we don’t really have any of these directly. But since SAP Gateway calls are always being passed to the backend system via an RFC (Function Module) call, even when the Gateway is located on the backend system, we can use this to enable the Runtime Analysis.
For this we use the scheduling utility (marked in red).
Click the create icon.
Enter the Function Module ‘/IWBEP/FM_MGW_HANDLE_REQUEST’ and other values as shown above or change to suit your needs. (See below how to find this Function Module).
Press Enter.
From the overview, we now see an old measurement already executed, and our new one in status ‘In Process’, which means it is ready for capture.
How to find the Function Module:
Previously we saw the call stack of the Backend Performance Trace. As explained earlier, the call stack on the backend always starts with the RFC Function Module, so from here we can find it in the Method column.
Start capture
Go to your browser or other client and make the OData call.
The status is now changed to ‘Executed’
Now go to the Evaluate tab of SAT, to find your measurement.
Double-click it.
Now you can make a deep dive into the measurement, and see how many times each coding block has used, as well as examining which coding blocks have been called, and much more.
This tool is a very advanced tool, providing very detailed info about the runtime details in the backend system.
Debugging an Odata call
For completeness I will also show how you can debug an Odata call.
To perform external debugging in ABAP both the debug user (performing the debug) AND the debugee (user being debugged) must BOTH have debug authorizations, as displayed above.
It is not necessary to have authorization for all above activities, but I am not sure which are the minimum needed activities.
Go to transaction SE80, and choose Utilities -> Settings.
Set the user you want to debug and press Enter.
Find the Data Provider Class method you want to debug, and position the cursor on the line where the breakpoint should be placed.
Click the icon for External Break Point to set it.
When the user executes the call, the debugger will open once the Break Point is hit by the user.
In the above screen dump, it is shown where the RFC Function Module is located in the call stack. It can also be seen, that this system is a hybrid system, where the SAP Gateway and Backend is in the same system, since the call stack includes all the Gateway calls as well.
I hope some of these insights are useful for some of you guys.
Søren Hansen, Senior Mobile Consultant, 2BM A/S, Denmark
I have recently come across a situation, where bad performance of one of my custom developed OData service caused a lot of issues, and where I was forced to think out-of-the-box to come up with ways to perform detailed tracing. And now I want to share these with you guys.
In this blog post I will show some tools for logging and tracing OData calls in the Gateway as well as in the SAP Backend. Furthermore, I will show how OData calls can be captured in the ABAP Runtime Analysis tool (SAT) in the SAP backend for very detailed analysis of all steps being carried out in the backend.
The Runtime Analysis Tool is known by most ABAP developers, but I will show how a capture can be scheduled, so an OData call from a browser can trigger the creation of a measurement for further analysis.
In SAT it is possible to view things like: Which DB tables are being updated, which coding blocks are being called, and how many times, as well as runtime in microseconds for each call, and much more.
SAP Gateway Tracing
When working with SAP gateway OData services, most people come across the two most commonly used transactions for logging and tracing in SAP Gateway.
- /IWFND/ERROR_LOG: Displays erroneous OData calls to the Gateway
- /IWFND/TRACES: Display Performance and Payload traces
In environments where the SAP Gateway and the SAP Backend system are in two distinct systems (using a Gateway Hub), these utilities are used on the SAP Gateway Hub (not the backend).
The Error Log is a continuous log, that will display framework errors.
Traces, which are user specific, must be enabled before they can be displayed.
The login user will be selected by default, but other users may be added by using the marked button.
Traces are active for a period of two hours, after which they will automatically be inactivated.
Payload Trace is an excellent tool for displaying the raw OData requests (and responses) being performed on the system.
In case of $batch calls being used one http request may contain multiple OData requests. This makes it harder, in error situations, to pinpoint where the problem is.
In the above call 3 separate GET calls are being carried in one request.
In this view we see the raw data being passed from (request) and to (response) the client.
The corresponding Performance Trace display the 3 GetEntitySet calls, but with no details from the backend. Only the total processing time for each call
SAP Backend
In the backend system there are 2 similar utilities for logging and tracing.
- /IWBEP/ERROR_LOG: Displays erroneous OData calls to the Gateway
- /IWBEP/TRACES: Display Performance and Payload traces
These will show similar info from the SAP Gateway framework, but in the backend system.
Note:
I have found that, on older SAP versions, these may not start properly from the startscreen, but for some weird reasons they can be started from SE93 or by adding them as favorites.
It is important to understand the way the Gateway framework works, to understand what we can use these tools for. When the SAP Gateway receives an OData request from a client it validates and de-serialize the JSON request data into ABAP data. Then it identifies which Backend system the call should be routed to and calls the backend system via an RFC (function module), passing data in a mapped format. On the backend system, the Data Provider Class is called to execute the request.
The Backend Traces can be enabled the same way as on the SAP Gateway.
In the backend Payload Trace we will see separate measures for each OData call contained in $batch multi requests. This will give us a little more detailed info than we got on the SAP Gateway. Requests of type $batch with only a single measure in this list contains only one OData request.
When the payload is examined, we will now see request payloads in XML format. This is the data format being passed to the RFC Function Module from the SAP Gateway, after the json request has been deserialized.
In the Performance Trace, we will also see distinct measures for each OData sub request of a $batch request containing multiple requests.
By double clicking an entry we can examine the path to the Data Provider Class executing the request call.
But still we cannot get detailed analysis data on what is happening in the Data Provider Class.
ABAP Runtime Analysis (SAT)
To get very detailed runtime analysis data, of what actions are being performed in the Data Provider Class we can use the ABAP Runtime Analysis tool.
This is done in transaction SAT in the backend system.
In SAT you can analyze code being executed from a Transaction, Program or a Function Module. In Gateway context we don’t really have any of these directly. But since SAP Gateway calls are always being passed to the backend system via an RFC (Function Module) call, even when the Gateway is located on the backend system, we can use this to enable the Runtime Analysis.
For this we use the scheduling utility (marked in red).
Click the create icon.
Enter the Function Module ‘/IWBEP/FM_MGW_HANDLE_REQUEST’ and other values as shown above or change to suit your needs. (See below how to find this Function Module).
Press Enter.
From the overview, we now see an old measurement already executed, and our new one in status ‘In Process’, which means it is ready for capture.
How to find the Function Module:
Previously we saw the call stack of the Backend Performance Trace. As explained earlier, the call stack on the backend always starts with the RFC Function Module, so from here we can find it in the Method column.
Start capture
Go to your browser or other client and make the OData call.
The status is now changed to ‘Executed’
Now go to the Evaluate tab of SAT, to find your measurement.
Double-click it.
Now you can make a deep dive into the measurement, and see how many times each coding block has used, as well as examining which coding blocks have been called, and much more.
This tool is a very advanced tool, providing very detailed info about the runtime details in the backend system.
Debugging an Odata call
For completeness I will also show how you can debug an Odata call.
To perform external debugging in ABAP both the debug user (performing the debug) AND the debugee (user being debugged) must BOTH have debug authorizations, as displayed above.
It is not necessary to have authorization for all above activities, but I am not sure which are the minimum needed activities.
Go to transaction SE80, and choose Utilities -> Settings.
Set the user you want to debug and press Enter.
Find the Data Provider Class method you want to debug, and position the cursor on the line where the breakpoint should be placed.
Click the icon for External Break Point to set it.
When the user executes the call, the debugger will open once the Break Point is hit by the user.
In the above screen dump, it is shown where the RFC Function Module is located in the call stack. It can also be seen, that this system is a hybrid system, where the SAP Gateway and Backend is in the same system, since the call stack includes all the Gateway calls as well.
I hope some of these insights are useful for some of you guys.
Søren Hansen, Senior Mobile Consultant, 2BM A/S, Denmark
- SAP Managed Tags:
9 Comments
