OData Integration on SAP NetWeaver Gateway : Batch Operation Usage
There may be certain scenarios wherein instances may logically bind together and requires to be handled or processed in conjunction within the same logical unit of work. Take for instance a sales order, wherein an update of two or more related firm entries may be required and ought to be processed together in a single request (all or none).
SAP NetWeaver Gateway can be used to process such scenarios possessing the power to accomplish multiple operations in a single request.
It’s a known fact that Gateway provides an OData API into a SAP system (assuming that you had worked earlier with SAP Gateway). This uniform interface supports a given set of operations like Create, Read, Update and Delete and lets you process a single operation per HTTP request.
However, based on the business requirements, it may become pertinent for clients to send multiple operations in a single HTTP request. Commencing with SP04, SAP NetWeaver Gateway offers the capability for client operations to batch multiple operations into a single HTTP request, enabling a sequence of retrieve operations and/or modify operations with only one request.
In order to start batching multiple operations, you need to understand few pre-requisites, which are outlined as follows:
- Access to SAP NetWeaver ABAP 7.02 SP7 or system with higher configuration, having SAP NetWeaver Gateway ABAP add-ons installed.
- Availability of SAP delivered RMTSAMPLEFLIGHT service or other Gateway services that are configured to accept requests.
- Installation of backend SAP ECC 6.0 or higher version along with the IW_BEP Gateway add-on (optional, in case the service data arrives from a separate backend).
- Configuration of connections between SAP NetWeaver Gateway system and backend SAP application (optional, in case the service data arrives from a separate backend).
- Google Chrome with “Advanced Rest Client” extension or other compatible REST client that can send RAW HTTP requests.
- Basic understanding of ABAP development.
OData batch requests enables binding of multiple operations into a single HTTP request payload. Certain parameters like components of a batch request, how the request gets handled and the components of the batch response have major differences with respect to the components and processing of a simple and single operation of OData request.
There is one major difference between OData batch request and a normal OData request. In OData batch request, the batch request is represented as a Multipart MIME v1.0 message as specified in RFC2046 (MIME networking protocol). This standard format enables multiple parts of various content types to be denoted within a single overall request.
Components of a Batch Request
Batch request consists of two components:
- Batch request header
- Batch request body
Batch request header
Batch requests are sent as a single HTTP POST request to the batch endpoint of a service. The batch endpoint of a service serves as a base service URL attached with “$batch”. Let’s take an example. The batch endpoint for the sample RMTSAMPLEFLIGHT service is:
The batch request must consists of a Content-Type header that specifies a content type of “multipart/mixed” and a “boundary” specification. The boundary specification is inserted in the body of the request to mark the commencement and termination of each part of the batch request – segregating the different operations contained in the request.
While using HTTP POST method, a CSRF (Cross-Site Request Forgery) token is required when sending the request
Batch request body
The body of a batch request is comprised of an ordered series of retrieve operations and/or change sets. Retrieve operations are generally Query or Read operations executed with the HTTP GET method. When you modify such operations, they are referred as “Change Sets” in OData batch processing terms. Change Sets can consist of Create, Update or Delete operations executed using the POST, PUT and DELETE methods.
In the batch request body, each retrieve request and change set is denoted as a different MIME part and is separated by the boundary marker defined in the Content-Type header of the request. The contents of the MIME part that represents a change set is itself a multipart MIME document with one part for each operation, making up the change set. Each MIME part denoting a retrieve request or change set within the batch includes both Content-Type and Content-Transfer-Encoding MIME headers. The batch request boundary is the name specified in the Content-Type Header for the batch.
Batch response consists of two components:
- Content Type Header that specifies the content type of multipart/mixed.
- Batch boundary specification that may be different from the batch boundary used in the corresponding request.
A body of the batch response consists of a response for each retrieve request and change set, as existed in the associated batch request. The order of responses in the response body tally with the order of requests in the batch request. Each response consists of a Content-Type header with application/http value and a Content-Transfer-Encoding MIME header with a binary value. The formatting of response for a retrieve request is exactly the same as it would have been displayed outside a batch.
The body of a change set response could be:
- A response pertaining to all the successfully processed change requests within the change set.
- Formatted exactly as it would have been displayed outside a batch.
- A single response denoting a failure of the complete change set.
However, at present, content ID referencing in a change set is not supported for $batch.
How are operations handled in batch requests?
Retrieve operations and change sets are handled differently by Gateway.
Each retrieve operation like Query or Read within a $batch request will be transferred separately from SAP NetWeaver Gateway hub system to the provider application at the backend for processing.
On the contrary, since every change set is to be treated as a single logical unit of work (LCW), all operations of a change set will be sent at a single instance from Gateway to the provider application at the backend system for processing. The Gateway system collects results from all the operations and subsequently sends these results as one HTTP response to the OData consumer.
Additional Application API for $batch
For executing retrieve operations, there is no requirement of special handling. However, in order to ensure the “all or nothing” character of a change set, there are two additional methods for changing set handling in interface /IWBEP/IF_MGW_APPL_SRV_RUNTIME. The two additional methods are:
All operations within a change set must be considered as a logical unit of work. Hence, a provider must not issue COMMIT WORK or ROLLBACK WORK while processing the change sets. Otherwise, the framework will terminate the change set processing. In case the change set consists of only one operation, the check of Commit or Rollback is deactivated.
The provider can update the database only if it updates all modifications of a change set within the internal tables. A COMMIT WORK will be issued by the framework at the end of this API.
If you would like a demo of Innovapptive’s portfolio of Native or Web based mobile solutions, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at firstname.lastname@example.org or you can reach a sales representative at (713) 275-1804.