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
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.
The parameters used in sap-statistics=true ( response headers of the HTTP request)
Other metrics
Status: Calculated after the excel is generated
Sample values:
"totalTime":"44","count":1,"elapsedTime":249,"icmTotal":"58","wdTotal":"63","gwapp":"10","gwappdb":"","contentLength":"556"
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
Identify and Report OData behaviour across releases
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:
"totalTime":"44","count":1,"elapsedTime":249,"icmTotal":"58","wdTotal":"63","gwapp":"10","gwappdb":"","contentLength":"556"
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
- SAP Managed Tags:
