Odata $batch processing part 2
This is the 2nd part of this Odata $batch processing chapter. Click here for Odata $batch processing part 1
So far we have seen :
1) The default behavior of a change set within a $batch .
2) How the change set can contain only one operation and where each change set is treated as single LUW
3) In order to have more than one operation in a change set, SAP GW framework provides a defer mode. This will change the default processing mode. This is done by flagging defer mode = X in changes et begin method.
For defer mode:
1) Method CHANGESET_BEGIN is redefined with cv_defer_mode = abap_true
2) Method CHANGESET_PROCESS is redefined to have logic to create material + extend material to the plant
3) All operations in a changeset is treated as one LUW
$batch Use case 8: Change set in defer mode
Below $batch request has 2 change sets:
Change set C01 – 1 POST (for material creation) and 1 PUT (material update)
Change set C02 – 1 POST and 1 PUT
$batch Use case 9: Default processing vs Deferred processing
Deferred processing is meant to achieve performance gain. Allows more than one operation in a change set (single LUW). Let’s compare the time between default & deferred processing.
To check the time consumed in postman, add header parameter “sap-statistics = true”
Below request for default processing mode contains:
1) Two retrieve operations and
2) Two change sets as below:
C01 contain 1 POST operation
C02 contain 1 PUT operation
Response is as below:
The time taken is :
Looking at tcode /IWFND/TRACES, we see the GW time taken is 395 milliseconds (ms)
Another good Gateway statistics tool (tcode /IWFND/STATS) will show the overall results as below:
More details on GW performance & measuring time can be found here.
Moving to the defer mode processing. The change set begin and change set process methods are implemented as mentioned before. Let’s run earlier operations now in defer mode.
The time taken is:
Default behavior processing took 395 ms.
Deferred processing mode took 249 ms.
We see a performance gain factor of around 36%. The performance also depend on other factors like : system + network resources. For more number of operations, the deferred processing will have good performance due to its single LUW handling for a change set
$batch Use case 10: Content-ID usage
If there are multiple operations, one operation can refer to another using Content-ID reference instead of using entity key which may not be known at run time.
Say for example in our model, we have been using MaterialSet and MaterialPlantSet.
Now if MaterialSet has a POST operation. Say MAT1 is newly created out of it. If I we were to run a POST on MaterialPlantSet for the newly generated MAT1, the MaterialPlantSet need to know about the newly created material at runtime. That is achieved through Content-ID referencing.
Using Content-ID the 2nd operation can refer to the material generated in the 1st operation. Let’s run the example.
Content-ID can be used only in defer mode ie where more than one operation are present within a change set.
When the framework calls CHANGESET_BEGIN, we see it has collected two change set operations along with the Content-ID references
Further when CHANGESET_PROCESS is called, the two operations are executed.
Content-ID use will useful with scenarios like Sales Order header/Item or more like Purchase order/Item.
So we pretty much covered the basics & advanced features of $batch requests using json.
We did see the difference between default vs deferred processing. That will be all with the $batch request experiments. Hope the concepts will be clear and will prove beneficial to those using $batch requests. Thank you.