Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
Hello ,

This blog will walk you through the concept of


Performance Improvement: $batch Parallelization

The performance optimizations for $batch processing described here are only available for a hub system NW release 7.0x or 7.3x SP08 or NW release 7.4x SP06 and backend system NW release 7.0x or 7.3x SP08 or NW release 7.4x SP06.

In older support package stacks, the SAP NetWeaver Gateway framework issues one separate Remote Function Call (RFC) for each retrieve operation or each change set.

In the newer support package stacks described above only one RFC is used to send all operations contained in a batch request to the backend system (batch at once). Due to the till now implementation of the etag handling in the REST/OData library and gateway framework, all modifying operations using etag in a batch request are delivered separately to the backend system. Based on the configuration settings in the backend system (via IMG, transaction SPRO see below), all consecutive retrieve operations are parallelized to improve the processing performance. The parallelization is active per default.

The processing performance increases with more number of consecutive retrieve operations in a $batch request.

The following performance trace summary shows the performance statistics and also illustrates how a $batch request is processed in the backend system.

The $batch example contains

  • 3 consecutive retrieve operations

  • 1 changeset with create, update and execute action

  • 2 consecutive retrieve operations

  • 1 changeset with delete

  • 1 single retrieve operation


From within a backend system you can use the SAP project reference object (transaction SPRO) to activate or deactivate the parallelization as follows:

SPRO -> SAP Reference IMG -> SAP NetWeaver -> Gateway Service Enablement -> Backend OData Channel -> Configuration Settings -> Define Parallelization of Batch Queries.

Changesets in Multiple Origin Composition

Changeset is a collection of one or more modifying operations having the feature "all or nothing" when processing (same meaning as Logical-Unit-of-Work in an ABAP system).

Multiple Origin Composition (MOC) is the ability to collect data from different backend systems, aggregate them in one single service and updating different backend systems while using the same user. Thus a service can be made available for several system aliases.

In the context of multiple origin composition, not only retrieve operations such as read entity, read entityset but now also changesets are supported. All operations of a changeset must be defined for one and the same system alias (SAP__Origin=<xx...x>). They are collected and sent to the backend defined by the system alias and via one RFC. You can find an example in SAP Note 1890049.

A changeset containing operations for different system aliases will be terminated with error text "Changeset containing different system aliases not supported".

SAP Fiori Apps are based on OData Services, One SAP Fiori application shall have one dedicated OData Service.

We continuously thrive to optimize Fiori applications/. functionality to run within sub-second timeframe which generates huge value addition to our customers when using SAP software to run their critical business scenarios

Developers who wish to develop new OData can easily run performance tests on their local Env to validate prior to pushing it into new/existing development or publishing it to SAP API Hub. During the test/delivery phase this solution/framework will have flexibility to configure the tests and then ODATA services are fired according to the user scenarios.

To independently measure the Performance of an OData for S4HANA to build faster optimized applications : this solution approach through an application facilitates to automatically identify and performance test OData independently during a release. It can further be leveraged to be used only by Developers who are interested to test only API class use cases. The results of performance metrics are validated against the defined thresholds


The parameters used in sap-statistics=true ( response headers of the HTTP request)

  • SAP NWGateway (OData request processing)

  • GW Total = gwtotal

  • GW DB= gwappdb

  • App time = gwapp

Other metrics

  • E2E Client time = Client specific time

  • Content length

Status: Calculated after the excel is generated

Sample values:



Solution (iTOP 1.0)

iTOP : independently test OData Performance

As users constantly need to validate the performance of an OData prior to deployment/during development our implementation addresses this requirement. The solution works together seamlessly and offers a consistent end-to-end experience.

OData calls are executed for these iterations = Main runs (10) + Buffered runs (3)

To test an OData call which leads to Performance identification, developers can start with this solution which helps them in identifying or pointing towards RCA

  • The proposed model captures ODataServices automatically under test

  • Users have a provision to add new OData/modify any existing

  • The resulting performance metrics are validated against the thresholds and rendered back to UI and downloaded as an Excel

Identify and Report OData behaviour across releases