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

Change set C01

Change set C02

 Response:

C01 POST response

C01 PUT response

C02 POST response

C02 PUT response

$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

Request:

C01 GET request

C01 POST  &  C02 PUT request

Response is as below:

GET response

C01 POST response

C01 PUT response

The time taken is :

Time taken for default processing mode

Looking at tcode /IWFND/TRACES, we see the GW time taken is 395 milliseconds (ms)

Frontend trace

Frontend trace details

Another good Gateway statistics tool (tcode /IWFND/STATS) will show the overall results as below:

Gateway Statistics tool

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.

Request:

GET request

C01 POST  & PUT request

Response :

GET response

GET  & C01 POST response

C01 PUT response

The time taken is:

Time taken for defer mode

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.

Odata model

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.

Runtime relation between operation

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.

Content-ID request

 Response :

Content-ID response

When the framework calls CHANGESET_BEGIN, we see it has collected two change set operations along with the Content-ID references

Debug – CHANGESET_BEGIN method

Further when CHANGESET_PROCESS is called, the two operations are executed.

Debug – CHANGESET_PROCESS method

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.