Introduction:
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!!
Content:
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:
Prerequisite:
So, let’s get started...
In context with the SAP NetWeaver gateway, there are two important things in $batch call processing:
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:
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.
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:
Scenario:
Create one custom table:
On top of this, create simple 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:
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.
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:
To fetch specific entries, pass key values as shown in below screenshot:
Now, to perform changeset operations, we have two ways:
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:
Step 2: Go to gateway client, add URI option: $batch, replace the payload as per your requirement & execute.
Step 3: To cross verify, go & check the table entry:
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.
Step 2: In the method, IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END of DPC_EXT class, replace the commented with ‘COMMIT WORK’.
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.
Please refer below code for changeset operation – ‘Update entity’:
Step 4: Go to gateway client, add URI option, replace the payload as shown below & execute:
Step 5: To cross verify check table entries:
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.
Conclusion:
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.
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!!
Content:
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:
- What $batch request means in Odata.
- $batch request implementation in SAP NetWeaver Gateway.
- Different ways to perform changeset operations.
- How to implement CHANGESET_PROCESS.
Prerequisite:
- Basics on service creation in SEGW or Odata enabled CDS.
- 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:
- Batch Request
- 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:
- The request coming from UI.
- Request handled in the backend.
- 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:
Scenario:
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:
- Go to SAP gateway client.
- 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:
- To redefine respective operations & handle all operations there itself.
- 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:
- /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN
- /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGE SET_END
- /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_PROCESS
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
Conclusion:
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.
- SAP Managed Tags:
13 Comments
