Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member306391
Participant
A lot has been written on OData $batch processing. All those are knowledge enriching ones. This is an attempt to provide some more practical examples on $batch processing explicitly using json. This 2 part series, covers the basics & advanced features of $batch processing.

Topics covered are :

1) $batch wit GET, POST & PUT

2) $batch with $filter

3) Change set processing - default behavior

4) Change set processing - deferred processing

5) Comparing default vs deferred

6) Using Content-ID

Environment is :

1) Netweaver 7.4 EHP7 GWFND 740 SPS 22

2) POSTMAN Client

 

The Odata model taken is Material & its corresponding relation to plant

Below is the Odata model:

Odata model


Navigation and association


Get the POSTMAN client ready

 


Get X-CSRF-TOKEN


 

$batch Use case 1: GET request


Request body: Note that without the "Accept" the result will in xml

GET request


Response body:

GET response


Detail of the result:

json details


json details


These retrieve operations within a $batch are processed using parallelization by default. The setting to enable/disable parallelization for a particular service can be done via /IWBEP/CONF_SERVICE

Enable/disable parallelization


The setting is also available from /IWFND/MAINT_SERVICE via: Service Implemenation ->click configuration

 

$batch Use case 2: GET with navigation (Material to plant)


Request:

GET with navigation


Response:

GET response with navigation


Detail of json result:

json details


 

$batch Use case 3: GET with $filter


Request: Retrieve materials by "Created_On" date

GET with $filter


The remaining query options are pretty much the same as usual. Let's move to POST operation

Before we get in POST operations, its time to introduce Change set. As per SAP, $batch request is made up of ordered series of retrieve operations and/or Change sets.

1) A Change set is unordered group of one or more insert, update or delete operations. Retrieve operation is not a change set.

2) Every change set is treated as separate LUW ensuring the "ALL" or "Nothing" transaction behavior

If there are 2 Change sets with some operations within it, that implies processing of 2 LUW. When using $batch and change sets, the commit and rollback is done by the GW framework. Below are some example of change set operations.

Example: a change set containing 1 POST operation

Change set example


 

$batch Use case 4: Change set operation


The below $batch request contain a change set with one operation.

Request:

Change set with 1 POST operation


 

Response:

POST Response


The change sets internally are handled by 2 API methods :-

CHANGESET_BEGIN - by default allows only 1 operation per change set

CHANGESET_END - finalization of modification updates occurs here. The framework issue a commit work at the end of this method.

 

$batch Use case 5: Change set operations


Request body: Change set C01 has 2 POST operations


Change set C01


 


Change set C01


Response : More than one operation within a change set is not allowed

more than one operation not allowed


In order to have more than one operation, more than one change set is required

 

$batch Use case 6: Change sets with more than one operation


Below $batch request contains:

Change set C01 - 1 POST operation.

Change set C02 - 1 POST operation.

Remember each change set will treated as a separate LUW.

Request body:

Change set C01 POST


 


Change set C02 POST


Response:

Deep Insert POST response


Deep insert POST response


Assuming a case where, one of the change set gets aborted, that doesn't affect the other change set.

 

$batch Use case 7: 2 Change sets - one in error


Below $batch request contains two change sets. One of them is bound to fail.

Change set C01 - the LUW will be in error due to a wrong input

Change set C02 - this LUW will be success

Request body:

Change set with wrong value in operation


Change set with success operation


Response:

Response Change set C01 & C02


One operation is allowed per change set. That is the default behavior.

To process multiple operations within a change set, the default behavior must be changed. That is achieved using a defer mode. It's also known as deferred processing.

How do we do that? We re-define these methods of the backend data provider

DPC Change set methods


So essentially we change the default behavior with defer mode

1) Set the defer mode = 'X' by implementing CHANGESET_BEGIN. This is an indicator that backend data provider is able to handle more than one operations at once.

2) The backend data provider will process multiple operations using a new method CHANGESET_PROCESS. All updates & modifications are collected in this method. Ensure no commit is called within the LUW to respect ALL or Nothing principle.

3) At the end of change set, CHANGESET_END method is called. The framework issues a commit work to perform the database updates here.

The defer mode processing is introduced to achieve performance by handling multiple operations within a change set.

 

In the next part, we shall compare time spent between a default processing and deferred processing and also look at Content-ID use case example.
17 Comments
Labels in this area