Skip to Content
Technical Articles
Author's profile photo Neha Khandagade

Batch Call Processing in SAP NetWeaver Gateway


There can be a scenario where multiple operations need to be performed in one call. To do so, we all know what to use that is ‘Batch Call Processing’. $Batch collects all fixed number of operations (retrieve, create, update, delete) of an OData service in one single HTTP post request.

Recently, I came across the same scenario, & I did some research on the workflow of batch call in SAP NetWeaver gateway and thought of sharing the same with all of you folks!!


In this blog post, I have tried to keep all the basic & important aspects of $batch at one place & into simpler terms. This blog post will give you some insights on below points with some practical examples:

  1. What $batch request means in Odata.
  2. $batch request implementation in SAP NetWeaver Gateway.
  3. Different ways to perform changeset operations.
  4. How to implement CHANGESET_PROCESS.


  1. Basics on service creation in SEGW or Odata enabled CDS.
  2. How to register & test the service.

So, let’s get started…

In context with the SAP NetWeaver gateway, there are two important things in $batch call processing:

  1. Batch Request
  2. Batch Response

Batch Request:

Here you define all the operations which need to be performed, in one payload. Once, you defined it, these requests are now submitted as a single HTTP POST request.

Why POST request only??

$batch works as an intermediate between multiple calls coming from UI & handling of calls in the backend, which is somehow different from a scenario where a single request is handled.

For a single request, it works as:

  1. The request coming from UI.
  2. Request handled in the backend.
  3. Response from the backend.

So, for ‘CREATE’ we use ‘POST’, for ‘UPDATE’ we use ‘PUT’ & so on, that means we have dedicated methods for each operation.

But in case of multiple requests, we need to handle all the operations into one request, and since we are only submitting those requests, that is why we use HTTP POST for $batch calls.


Figure 1


Batch Response:

It tells you the response of all of your requests, the response will be in the same sequence as that of sequence maintained in requests.

The batch response comprises of Content-Type header specifying a content type of multipart/mixed and a batch boundary specification, which may be different from the batch boundary that was used in the corresponding request.

If the set of HTTP request headers of a batch request are valid, the HTTP response status code is always 202 (Accepted). This is irrespective of whether some retrieve operations or changesets within this batch request fail or not. But if an operation within a changeset fails, the batch response body contains only one single response for this changeset indicating the failure of the entire changeset.

$Batch Behaviour:

Method ‘GET’ is the default property of the batch call. To perform ‘GET’ operations, nothing needs to be done explicitly. But for changeset operations, you have to either redefine & write a code in respective methods or You have to enable defer mode & handle it in ‘CHANGESET_PROCESS’ method. Let’s take some practical example:


Create one custom table:

Figure 2. Custom Table ‘ZTEST_TABLE’

Figure 3. Add some entries in a custom table

On top of this, create simple I-View & C-View:

Figure 4. I-View & C-View

Create an OData Project in ‘SEGW’ & consume the above C-View in a project using SADL Framework. Generate runtime Object. Register the service & open gateway client.

Now, we are ready to test the $batch for retrieve operation in the gateway client:

  1. Go to SAP gateway client.
  2. Click on ‘Add URI Option’ ->select ‘$batch’

Figure 5

Figure 6. A default HTTP request has been added with a content header

In figure 5, You can see a default HTTP request has been added with retrieval & changeset operation. And one header with content type is also added. Plus, the HTTP Method by default selected as ‘POST’.

Since we have not written code for changeset operation, it will only allow for retrieve operation. Now, modify the payload as per requirement. I will remove the changeset part from the payload and replace the entity set name ‘XYZ’ with ‘ZTEST_C_BATCH’ & execute.

Figure 7. HTTP response in right side as successful

Since we have passed the entire entity set & not specific key fields, it has fetched all the entries, you can check in below screenshot. Two entries are there:

Figure 8

To fetch specific entries, pass key values as shown in below screenshot:

Figure 9

Now, to perform changeset operations, we have two ways:

  1. To redefine respective operations & handle all operations there itself.
  2. Enable defer mode & handle all changeset operations in one place.

Let’s take a practical example of creating an entity using the first approach:

Step 1: Redefine ‘CREATE_ENTITY’ method of an entity set & replace the commented code with below code:

Figure 10

Step 2: Go to gateway client, add URI option: $batch, replace the payload as per your requirement & execute.

Figure 11. POST request to create an entity

Step 3: To cross verify, go & check the table entry:

Figure 12. A new entry has been created in a table

Similarly, for other changeset operation, you can follow the above steps.

Now, let’s see the second approach for changeset operation:

Go to DPC_EXT class, and redefine below methods:


Significance of above methods: In SAP Gateway, by default, only one operation per changeset is allowed. To allow multiple operations in a changeset, the default implementation must be overwritten using the above methods.

Step 1: In the method, IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN of DPC_EXT class, set the flag cv_defer_mode = abap_true.

Figure 13

Step 2: In the method, IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END of DPC_EXT class, replace the commented with ‘COMMIT WORK’.

Figure 14

Step 3: Redefine method IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_PROCESS’. In /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_PROCESS we have one importing parameter IT_CHANGESET_REQUEST, where we get all the changeset requests.

In an internal table, IT_CHANGESET_REQUEST, there is one field OPERATION_TYPE, which tells the type of operation needs to perform.

Fig.15 Operation types & descriptions

Please refer below code for changeset operation – ‘Update entity’:

Figure 16

Step 4: Go to gateway client, add URI option, replace the payload as shown below & execute:

Figure 17

Step 5: To cross verify check table entries:

Fig.18 Before update

Fig.19 After update

Note: Now we have code written for ‘CREATE’ in method: ‘ZTEST_C_BATCH_CREATE_ENTITY’ & for update entity, code has been written in ‘CHANGESET_PROCESS’ method. Try to create entry through batch call, it will not allow, since the Defer mode has been enabled.

Figure 20


If Defer mode is not being used, $batch call will follow the normal process, it will trigger the respective methods as per the request in the payload. But if Defer mode is enabled, instead of following the normal process of hitting separate methods of CRUD, it will directly hit to CHANGESET_PROCESS method.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Gaurav Karkara
      Gaurav Karkara

      Thanks for such a detailed blog. Well explained!

      Author's profile photo Neha Khandagade
      Neha Khandagade
      Blog Post Author

      Thank You Gaurav!!

      Author's profile photo Suketu Dave
      Suketu Dave

      Nicely explained!!!

      Author's profile photo Neha Khandagade
      Neha Khandagade
      Blog Post Author

      Thanks Suketu!!

      Author's profile photo Mohit .
      Mohit .

      Thanks for the detailed blog!!

      Author's profile photo Ravi Singh
      Ravi Singh

      Very Informative blog.

      Was wondering how many requests can be clubbed together in a batch call ?

      Any upper limit to it ?


      Author's profile photo AMAN ANSARI

      Very informative and well explained.

      Author's profile photo Vishal Kwatra
      Vishal Kwatra

      Good blog Neha, however to further clarify "All or Nothing principle applies to all the operations put together in one changeset" provided you have enabled the cv_defer flag. Each changeset can be considered as one single LUW. This scenario comes into picture when we are doing mass updates in the backend.

      Hence, if you have multiple changesets in your batch call, all of them are independent LUWs and if one changeset fails other changesets are not impacted.


      Author's profile photo Gretchen Horn
      Gretchen Horn

      Great blog!   You made it so easy to understand, thanks so much!

      Author's profile photo Priyadharshini Vitoba
      Priyadharshini Vitoba

      Very informative blog...Neatly explained..

      Author's profile photo Anil Lahori
      Anil Lahori

      Hi Neha,

      I am a newbie in Fiori /UI5 Developments.

      First , just walk me thru wth Batch concept  as i am unable to understand the explanations given by many   in google /and other websites .

      How $batch wraps all multiple requests into one single $batch call in the backend system ?

      & how deep insert entity is different from $batch ?


      Waiting to hear from you on this






      Author's profile photo Balaraju Pandiri
      Balaraju Pandiri

      Thank you Neha Khandagade for Batch call explanation with screenshots. I have one query that if defer mode is enabled, It is not posting every time we request but when all these requests are posted and creat entries in table if defer mode is enabled

      Author's profile photo JATIN SINGHAL

      Very Informative blog. Thank you for sharing.