In this blog, we will look into batch call processing in OData services, many times 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:
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.
Prerequisite:
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.
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:
1.
Go to SAP gateway client.
2.
Click on ‘Add URI Option’ ->select ‘$batch’
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:
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:
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:
1.
/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN
2.
/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGE SET_END
3.
/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.
2 comments
Click here for commentsVery well explained. Thanks for sharing this valuable concept in details.
ReplyWell explained,if some examples of batch POST and PUT operations from Ui5 also that would complete this tutorial
ReplyConversionConversion EmoticonEmoticon