Skip to Content

This blog contains useful dos and don’ts for SAP NetWeaver Gateway Consumers with focus on Performance aspects. This information is supposed to help developers to consume Gateway services in a most efficient way from performance point of view.

Dos

  • Do use JSON format to reduce client and SAP NetWeaver Gateway server time and reduce network traffic
  • Do use GZIP to compress data.

OData query options that optimize performance and end-to-end resource consumption:

  • Do use delta query in case the end users trigger the same query calls with the same options very often. This will fetch only the data from the SAP Business Suite that was created/changed/deleted since the end-user last asked.
  • Do use $select to specify the fields returned in the result set.
  • Do use $top and $skip (client-side paging) to reduce the returned items in the result set.
  • Do use $filter to fetch a subset of the entities in the entity set.
  • Do use $skiptoken (server-side paging) to fetch a subset of the entities in the entity set starting from the first entity at the index identified by the value of the $skiptoken query option.
  • Do use $count to fetch only the count of a collection of entities.
  • Do use $inlinecount to fetch the count of a collection of entities together with the queried entities.
  • Do use $expand/deep insert for associated entity types when you need to fetch or create deep data. Translated into the ODBC–language, $expand is the possibility of OData to make ‘joins’. Deep inserts are the possibility to make updates on views.
    • Do consider using parallel calls in case of one association if it is beneficial to show the results of the faster call. Use $expand/deep insert for one association call. For parallel calls this option is not possible.

    • Do use $expand/deep insert for more data which contains more than one association call.
    • Do implement and use basic $expand. Basic $expand is a central feature to provide the possibility to the application to read and return entities deeply (entity set and entity).  Consider not to use default (generic) $expand.

$expand performance optimization, in comparison to single calls, includes the following:

  • $expand reduces roundtrips from the client to the SAP NetWeaver Gateway server as well as the SAP NetWeaver Gateway server to the SAP Business Suite. As a result, network time is reduced.
  • $expand reduces SAP NetWeaver Gateway server response time and the consumption of resources.
  • Basic $expand implementation can reduce the SAP Business Suite times, because the number of database operations and the application logic can be reduced.

Do use $batch to send the data of several requests in a single HTTP request from the client to the SAP NetWeaver Gateway server for entity types that are not associated:

  • Do use parallel calls in case of two Read calls or two Update calls with multiple atomic units of work (different change sets). As an alternative to two parallel calls, you can consider using $batch.
  • Do use $batch in case of more than two calls without associated entity types (do not make too many client – SAP NetWeaver Gateway server roundtrips).

$batch performance optimizations and considerations (compared to single calls):

  • $batch reduces the number of roundtrips between the end-user and the SAP NetWeaver Gateway server. As a result, network time is reduced.
  • $batch reduces the number of roundtrips from the SAP NetWeaver Gateway server to the SAP Business Suite to one in case of Update calls with a single atomic unit of work.
  • $batch reduces SAP NetWeaver Gateway server response time and the consumption of resources.
  • $batch reduces CPU time of the SAP Business Suite in case of Update calls with a single atomic unit of work.
  • Consider the balance between the number of roundtrips and the payload size.  A payload sizie which is too big can affect the network time due to bandwidth constraints.
  • Consider using $batch because it can have a negative impact on the response time since SAP NetWeaver Gateway calls SAP Business Suite/s in sequential order (in case of Read calls or  Update calls with multiple atomic units of work). 

The following table can help to choose the required option between $expand, $batch and parallel calls.

Number of Calls from the Client to SAP NetWeaver Gateway

Operation Two Calls More Than Two Calls
Association Read

$Expand/ parallel calls

$Expand
Read without Association parallel calls $Batch
Update with Multiple Atomic Units of Work

Asynchronous (parallelized calls)/$Batch

$Batch
Update with Single Atomic Units of Work $Batch $Batch

Don’ts
  • Do not trigger more than two roundtrips from the client to the SAP NetWeaver Gateway server per single operation.
  • Do not use $batch for associated entity types. Use $expand instead.
  • Do not fetch more data than will be presented. Use OData query options to reduce the result set to fit data to be presented.
  • Do not call more than two parallel calls per single operation. Use $batch for more than two parallel calls. More than two parallel calls consume more server resources and network bandwidth.
  • Do not use generic (default) $expand functionality provided by the SAP NetWeaver Gateway framework. The generic expand function will not be ideal with regard to performance since it only represents a feature to provide functional completeness automatically. Implement and use basic expand to optimize performance and reduce SAP NetWeaver Gateway server and SAP Business Suite response time and the consumption of resources.

Whether a specific $expand is better than the generic one depends on the database / data access function design.

More information about OData features supported by SAP NetWeaver Gateway is decribed here.

Best Regards,

David

To report this post you need to login first.

20 Comments

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

  1. Sascha Wenninger

    Hi David,

    very cool blog and the first one I have seen which addresses good practices around Gateway performance.

    One question though: Why is “2” the magic number when it comes to parallel/async requests? Why not more?

    Regards,

    Sascha

    (0) 
    1. David Freidlin Post author

      Hi Sascha,

      2+ parallel calls usually consume more Gateway server resources and network bandwidth than $batch or $expand. However, number 2 is not constant and can be increased. This is very depends on the use case you have.  The main point is that we do not recommend to use many parallel requests and suggest to use $batch/$expand instead.

      Thanks,

      David

      (0) 
  2. Brad Pokroy

    Hi David,

    Great blog! Thanks!

    I have recently been running some tests to see the difference between the response size for the exact same query of a really large result set in XML vs JSON.

    The XML response was 6.82MB and the same results in JSON was 3.64MB. Which is almost half the size. So its very apparent that JSON is the best choice.

    Only problem is that the SDMParser class (Version 2.2.3) of the SAP OData SDK for Android only supports parsing of XML. Any idea if JSON parsing will become available in the SAP OData SDK, or possibly already is in a later version?

    Cheers,

    Brad

    (0) 
    1. Dharani Karthikeyan

      Hi Brad, Support for parsing JSON feeds in currently being added to oData SDK and it is currently planned to be available with the next release of oData SDK.

      Thanks, Dharani

      (0) 
  3. Aradhyula Naga Punnarao

    Hi David,

    Is it possible to return multiple entities (more than 3) in a single service call.

    I have Created 1 header and 4 Items ..am able to insert data using create_deep_entity,

    the same way is it possible to return all the entities in expanded entity?

    Thanks in Advance……

    (0) 
      1. Aradhyula Naga Punnarao

        Dear Syam,

        Thanks for quick reply.

        I have tried Expand entity set by following the blog you mentioned in your reply…

        Facing a problem in that…My requirement is Depending on the country selected in UI (Drop down) I have to return all the states ….Expand deep entity set is looping the line items and returning duplicates…Could you suggest any solution to avoid this…

        (0) 
        1. Vijay Vegesana

          Purna,

          you can delete the duplicates by writing syntax “delete adjacent duplicates from itab comparing <field>” inside your get_expanded_entityset.

          Thanks..

          (0) 
  4. Syam Babu

    Hi David,

    As you suggested i am performing the Update with Multiple Atomic Units of Work.


    Here my doubt at any point of time back-end throws BAPI error does will collect from multiple error from Batch operation?

    BR,

    Syam

    (0) 

Leave a Reply