The main focus of OData and SAP Gateway is to provide a slim and lightweight protocol for data consumption. In the majority of use cases, CREATE operations are performed for single entities only. However, there are valid scenarios where it’s necessary to create multiple entities simultaneously.

As an example, we will create a new service “ZGWSAMPLE_MASSINSERT_SRV” as a redefinition of the existing “GWSample_Basic” service, which is available as part of SAP Gateway Foundation (component SAP_GWFND) NW Release 7.40 SP09 and later. This service uses the EPM data model and we will create new products for an existing business partner. Assuming we need to create 100 new products with one single call, the easiest way would be to use a $batch request to combine all 100 POST calls into a single service call:

/wp-content/uploads/2015/09/figure01_783809.jpg

Adding the sap-statistics=true option at the end of the URI provides more details on how much processing time was required in the different SAP Gateway related layers. The table below shows the runtime in milliseconds for the creation of 1 to 2500 products:

products

gwtotal

gwhub

gwbe

gwapp

1

284

98

18

168

10

804

292

80

432

100

6456

2384

641

3432

500

33699

11952

3169

18578

1000

73870

25032

6515

42323

2500

252835

81069

17288

154478

Let’s have a look at what is happening behind the scenes when creating 100 products that way:

– 100 times de-serializing the JSON-payload while parsing the request-payload

– 100 times single request processing in the SAP Gateway Hub system

– 100 times single request processing in the backend system

– 100 times serializing the JSON-payload to generate the response-payload

All these steps are necessary because each changeset operation has to be handled separately!

This becomes even more obvious once we look into the SAP Gateway performance trace (Transaction: /n/iwfnd/traces):

/wp-content/uploads/2015/09/figure02_783810.jpg

In this example, we’ve created 10 new products and can see that for each new product the CREATE_ENTITY method is called.

/wp-content/uploads/2015/09/figure03_783811.jpg

The table shows that roughly 40% – 45% of the overall runtime per service call is SAP Gateway related overhead. Assuming that the application related coding is already optimized, the critical key figure to improve performance further is to minimize the SAP Gateway related overhead.

This can be achieved by modelling an additional entity set that will receive a list of products and create them via the deep-insert feature. Therefore, we will create a new entity named “ProductMassInsert” with the respective entity set “ProductMassInsertSet”. Furthermore, we’ll also need an association defined by the principal entity “ProductMassInsert” and the dependent entity “Product” and the cardinality 1:M. The association is needed to create the deep-insert functionality and will be named “ToProducts”. All we need to do now is redefine the CREATE_DEEP_ENTITY method inside the *DPC_EXT class to handle the creation of the products.

/wp-content/uploads/2015/09/figure04_783815.jpg

The call to create the list of products using the deep-insert mechanism will look like this:

/wp-content/uploads/2015/09/figure05_783816.jpg

This is what is now happening behind the scenes when creating 100 products within one deep-insert request:

– only 1 time de-serializing the JSON-payload while parsing the request-payload

– only 1 time single request processing on the SAP Gateway Hub

– only 1 time single request processing on the backend system

– only 1 time serializing the JSON-payload to generate the response-payload

products

gwtotal

gwhub

gwbe

gwapp

1

299

104

19

176

10

507

104

23

381

100

3186

190

68

2929

500

16048

553

252

15244

1000

36517

1016

490

35011

2500

128848

2345

1211

125292

As to be expected, the application runtime in the backend is similar as the coding hasn’t been further optimized.

The effective performance boost in the given scenario is about 90% performance increase in the SAP Gateway Hub and about 90% in the backend system, already starting at 100 entities. As performance follows a linear pattern in the non-optimized scenario, it will even improve with a higher amount of entities to be created. This won’t have any effect on the performance of the backend application itself, but importantly reduces the SAP Gateway overhead to a minimum.

/wp-content/uploads/2015/09/figure06_783817.jpg

Looking again at the SAP Gateway performance trace (Transaction: /n/iwfnd/traces) we can see that no matter how many products are being created with this deep-insert approach, the CREATE_DEEP_ENTITY method is only called once.

/wp-content/uploads/2015/09/figure07_783821.jpg

In the given example we could reduce the overall runtime in the CREATE scenario by 50% !!!


Worth reading: Details about some new features in SAP Gateway 2.0 SP09Performance Improvements on $batch (Change Set at Once/Change Set in Defer Mode)

To report this post you need to login first.

5 Comments

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

  1. Krishna Kishor Kammaje

    Nice stats Tobias.

    About the solution: The drawback is that we are are circumventing the OData standards to suit us.This is similar to doing a deep update (which OData does not support) using Deep Entity. This way every changeset can be converted into a Deep Create, but I am not sure if that is your recommendation.

    In such cases, I would not recommend using Gateway, rather a simple REST service would ideally suit.

    (0) 
    1. Tobias Griebe Post author

      Hi Krishna,

      thanks for your response.

      Above solution focuses on the SAP Gateway framework and the options/challenges we have at hand.

      I didn’t do any comparison to a simple REST service, which might indeed be a even faster in processing such a request. OData as such is not taylored for mass change/update scenarios, but I have seen similar thing being implmented in several projects.

      So if you still want to use OData with SAP Gateway this would be one option to consider.

      (0) 
  2. sivaraman Thiru

    Hi Atanu Malik,

    Hi Arun,

    I am getting status code 202  during my POST create operation using $batch, but not getting any other info in response area …even I put a external break point at create_entity …but still execution  was not stopped there  as well..

    Appreciate your help ..I paste below request

    -batch
    Content-Type: multipart/mixed; boundary=changeset

    –changeset
    Content-Type: application/http
    Content-Transfer-Encoding: binary

    POST SorditemSet HTTP/1.1
    Content-Type: application/atom+xml
    Content-Length: 588

    <?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>
    <atom:entry xmlns:atom=”http://www.w3.org/2005/Atom“
    xmlns:d=”http://schemas.microsoft.com/ado/2007/08/dataservices“
    xmlns:m=”http://schemas.microsoft.com/ado/2007/08/dataservices/metadata“>
    <atom:content type=”application/xml”>

    <m:properties>
    <d:Erdat>20161115</d:Erdat>
    <d:Netwr>    94.35</d:Netwr>
    <d:Waerk>GBP</d:Waerk>
    <d:Kunnr>0000001066</d:Kunnr>
    <d:Posnr>000010</d:Posnr>
    <d:Matnr>90251178</d:Matnr>
    <d:Kwmeng>    1.000</d:Kwmeng>
    <d:Status>UNAU</d:Status>
    <d:Vbeln>40000336</d:Vbeln>
    </m:properties>
    </atom:content>
    </atom:entry>

    –changeset–
    –batch–-

    (0) 

Leave a Reply