Show TOC

Performance Best PracticesLocate this document in the navigation structure

This section contains useful dos and don’ts for developers with a special focus on performance aspects.

Dos

  • Do use JSON format to reduce client and SAP 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 Gateway server as well as the SAP Gateway server to the SAP Business Suite. As a result, network time is reduced.
  • $expand reduces SAP 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 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 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 Gateway server. As a result, network time is reduced.
  • $batch reduces the number of roundtrips from the SAP Gateway server to the SAP Business Suite to one in case of Update calls with a single atomic unit of work.
  • $batch reduces SAP 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 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 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
Don’ts
  • Do not trigger more than two roundtrips from the client to the SAP 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 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 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.

RFC Bypass

If a SAP Gateway system and the backend system are located on the same computer, a shortcut should be used to speed up performance during the communication between the SAP Gateway framework on both systems. Using this shortcut, a serialization and deserialization and also a Remote Function Call from SAP Gateway to the backend system is no longer necessary. This speeds up the performance significantly.

Note that this shortcut is not available for multiple origin composition (MOC).

To activate or deactivate the shortcut communication an IMG activity is available: In transaction SPRO open the SAP NetWeaver reference IMG and navigate to Start of the navigation path SAP Gateway Next navigation step OData Channel Next navigation step Configuration Next navigation step Connection SAP Gateway to SAP System Next navigation step Manage SAP System Alias End of the navigation path. In the System Alias entry customized for your service(s) you can mark or unmark parameter Local SAP GW to activate or deactivate the shortcut communication.