with importing parameter IT_CHANGESET_REQUEST containing a list of changeset operations. Each entry of this list contains the technical request context IO_TECH_REQUEST_CONTEXT as usual but also a message container for error or information message that happened during the processing. Response data of a changeset operation including HTTP custom headers and ETag (if it exists) must be returned in changing parameter CT_CHANGESET_RESPONSE. At the end of a changeset, the framework will call method CHANGESET_END as usual.

 

Content ID Referencing

By using the Content ID referencing, you can refer the items with the resource navigation path “$100/ToItems”. $100 indicates the header entity by using Content ID. The service implementation has to use the aforementioned concept of deferred processing.

 

A sample implementation can be found in the service GWSAMPLE_BASIC.

 

 

“Content ID” is nothing new, it has been defined in the standard OData specification for a while. The content id concept is for example used if a resource shall be created and updated in the same $batch request. A typical example is hierarchical data such as headers and items.

 

Though also deep insert could be used in such a case this doesn’t work in offline scenarios. To add related child entities to a parent entity, you need to know or be able to reference the parent entity’s ID.  The “Content ID” acts as a reference or placeholder to the parent entity’s ID. As you see, a Content ID “$100” has a prefixed value with a “$” character.