Performance Trace API for Applications

Performance has always been a key aspect of any kind of application. As we are moving towards complex application stack, involving multiple technologies, performance analysis has become inevitable and rather a mainstream topic. Every good technology comes with its own mechanism to capture the performance statistics and the ability to run some kind of analysis on top of it.

SAP Gateway is no exception and it offers Performance Trace tools (transaction /IWBEP/TRACES and /IWFND/TRACES), which enables developers, administrators, support consultants and end users to monitor system performance at service call level. This is great.

We have an amazing blog by Carlos Rogganhttp://scn.sap.com/docs/DOC-70335, which explains the performance statistics for SAP Gateway.

Today, applications comprise of multiple layers. These layers interact with each other to achieve a common goal. For example behind a simple looking application there may exist a validation layer, an authorization layer, a data access layer, a third party interaction layer and any more. In the orchestration of multiple layers, performance factor becomes very important, so becomes the “tracing”.

Today in this blog, I shall speak about a little known API of SAP Gateway that helps to enable performance trace. From SAP Gateway 2.0 SP9 onwards, SAP Gateway offers API defined in class /IWBEP/CL_DIAGNOSTICS_FACADE to enable a data provider to measure the performance when calling external or internal components during the request processing in the same way as the gateway framework.

This blog talks about this API and its use through a simple example.

Scenario

In this scenario, I have an OData service, which is used to create a Business Partner. Internally the service will perform authorization check, validation of data, creation of Business Partner and creation of partner account in Salesforce using a wrapper class.

Gateway Project

The following project is created keeping the above scenario in mind. Internally within Data Provider class,  I am calling function module SEPM_GWS_BP_CREATE to create the BusinessPartner.

Here is the Model Definition in SEGW

Backend Classes

To keep the DPC logic clutter free and modularised, I have created a class ZCL_BP_WRAPPER that has all the methods required in the scenario. This class has a public static method BUSINESS_PARTNER_CREATE, which is called by the CREATE_ENTITY method of the Data Provider Class.

Method BUSINESS_PARTNER_CREATE internally calls other private methods from the same class.This picture shows the list of methods in the class.

Execution

Now we want to analyze the performance of Business Partner creation process.

First, we enable the trace in transaction /IWBEP/TRACES by selecting Performance Trace checkbox.

Then we fire the call to create a Business Partner from Gateway Client (transaction /IWFND/GW_CLIENT).

Next, to see the trace, we go back to transaction /IWBEP/TRACES and select the Performance Tab.

Then double click on the first line to drill down to more details.

Now this is what we are looking for. Gateway framework traces the backend calls. Line no 15 is something which is interesting for us. From line no 15, we can derive the following critical information.

• This is the trace of the CREATE_ENTITY method of DPC
• It is 3^rd level in the call stack
• It is not making any additional Sub calls ( at least at this moment )
• This method takes 9104 milliseconds which is pretty high.

So far so good except the Duration and Net time. 9104 milliseconds seems to be an expensive figure in terms of performance. We would like to analyze it further, but the Question is HOW ?

Analyzing the Issue

The screenshot from /IWBEP/TRACES is something to think back

In my project, I am using methods of class ZCL_BP_WRAPPER to do my work beyond DPC. The following picture shows the flow diagram beyond the CREATE_ENTITY method of Data Provider Class.

                                                                 [Control Flow]

Here, I would like to capture the performance trace at every individual method level, which is beyond the obvious CREATE_ENTITY call.

SAP Gateway framework does not capture trace beyond DPC calls by default, so everything is aggregated at CREATE_ENTITY level without pointing to the actual time consuming method.

Performance Trace API comes handy in this case and helps us to address this issue.

Performance Trace API for Applications

Class /iwbep/cl_diagnostics_facadeoffers two useful methods for tracing 

performance_start: This method needs to be called before every method or function module call that needs to be captured in the trace. This will initiate the trace related calculations.

This method returns a HANDLE which is nothing but an integer.

performance_stop : This method needs to be called for a methods/function module when the call is finished. This will complete the trace related calculations for the method/function under consideration.

Now I shall make use of these APIs for every method/function module call from method CREATE_ENTITY of DPC and all further calls beyond DPC.

The following snippet shows the coding in CREATE_ENTITY method. We are starting the performance start before calling ZCL_BP_WRAPPER=>BUSINESS_PARTNER_CREATE and stopping the trace after the call.

DATA lv_perf_handle TYPE i.
lv_perf_handle = /iwbep/cl_diagnostics_facade=>performance_start( iv_class_name  = 'ZCL_BP_WRAPPER'                                                                   iv_method_name = 'BUSINESS_PARTNER_CREATE' ).     zcl_bp_wrapper=>business_partner_create(      IMPORTING        et_return               = et_return      CHANGING        cs_businesspartner_data = cs_bp_header      ).   /iwbep/cl_diagnostics_facade=>performance_stop( lv_perf_handle ).

We shall do the same within ZCL_BP_WRAPPER=>BUSINESS_PARTNER_CREATE and further down the line.

Re-visiting Trace

Now we re-run the test from Gateway Client (transaction /IWFND/GW_CLIENT) and revisit the trace (transaction /IWBEP/TRACES). The latest trace looks like

The difference between the current trace and the previous trace is highlighted above. We can see Trace for individual methods and function module even beyond method CREATE_ENTITY of DPC.

Let’s revisit the flow diagram once again in the context of the new trace. The previous flow diagram can be interpreted as the below diagram. This shares the very same information with respect to Subcalls, Level, Class and Method columns of the captured trace.

Now if we focus on Line 17(from the current trace), we see method BP_VALIDATE takes 5000 milliseconds (Net time). Which is the maximum net time taken by any method / function in this flow.

Let’s look into the code of BP_VALIDATE.

We can see that there is a WAIT statement in the code. This line is the reason behind the performance bottleneck.

This is how you can trace the performance of your custom modules using the Gateway trace APIs.