Show TOC

Performance Best Practices Locate 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 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 data provider$expand. Data provider$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 (framework) $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.

  • Data provider$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
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 framework (default) $expand functionality provided by the SAP NetWeaver Gateway framework. The framework expand function will not be ideal with regard to performance since it only represents a feature to provide functional completeness automatically. Implement and use data provider 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 framework one depends on the database / data access function design.

More Information

For more information on performance best practices, see the SAP Community Network SCN under http://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=318672646.