Post implementation in changeset_end method. How to populate response body?

[Former Member]

Hi Experts,

I have a scenario that requires me to implement post operation in changeset_end method. If the post operation is implemented in Create_<entity> method, system automatically does a read after create and populates the response body. How do I populate the response body if my create operation is part of batch request where the backed call happens in changeset_end method?

Regards,

Seetharam

[kammaje_cis · Accepted solution]

Seetharam,

You should not try to populate the response body inside the changeset_end method,

But I see your problem. I do not see a way to send back the data, like a regular CREATE. Check Ron's response here.

@

Since a regular CREATE sends back a created entry, same would be expected out of $batch create as well. What do you think? In a case where keys are generated in backend, I will not even be knowing the keys beforehand to place a read query at the end of $batch.

Regards

Krishna

[Former Member · Accepted solution]

Hi guys,

According to the SAP documentation, the response does/should go partway towards providing the entity in the response.

The URI's of created entities should be present, if not the full content. As stated in the other thread, I would GET these again in any case to be confident of the true state. It can be the case that the backend populates certain properties such as timestamps and userids  or results of secondary processing which you would need to reinstate on the client side to get the true state.

regards

Ron.

[Former Member · Accepted solution]

Hi Ron,

The URI of the created entity is not present in the response when Post operation which is part of Batch request is implemented in Changeset_end method.

Regards,

SeethaRam.

[kammaje_cis · Accepted solution]

Ron,

How does the GW framework know the new keys to create the URL?. (Since backend uses internal number range and key is not passed from the client).

regards

Krishna

[Former Member · Accepted solution]

I believe this is why the create method does a read - it's more for the benefit of OData parsing than the consumer getting a response.

When the backend receives the POST payload, the key properties should be blank. The backend logic applies values to these properties, e.g. assign a guid. These operations are carried out on the entity container and the persistent store. If you pass this container back in the response, the OData parser will know how to form the new URI since it has the metadata informing it of the key. Hence it can log the new URI in the changeset response.

Seetharam, you haven't indicated if you are actually giving the entity back in the response of each call to the CREATE method - are you doing that?

[Former Member · Accepted solution]

Hi Ron,

Can you please explain in detail the following comment of yours - may be with an example please -

it's more for the benefit of OData parsing than the consumer getting a response.

I do the following in my DPC_EXT class:

a) In Create_<entity> method, I collect the data from post request into an internal table.

b) In changeset_end method, I access the data collected in #a and call the backed API that actually does the create. This create operation creates the sales order id.

Now, how do I populate the response body to include sales order id so that I can pass it to front end. The end user will have to make a note of sales order id in my scenario.

Regards,

SeethaRam

[Former Member · Accepted solution]

I have also tried the below code in changeset_end method, but I have no luck. I'm unable to populate sales order id to response header.

data:  ls_header TYPE ihttpnvp.

ls_header-name = 'SalesOrderId' .

ls_header-value = ex_Order_id.

/iwbep/if_mgw_conv_srv_runtime~set_header( ls_header ).

I'm assuming because my system is on Sp4 for SAP_GWFND component. Is there a workaround?

Regards,

Seetharam

[Former Member · Accepted solution]

Seetharam,

As Krishna pointed out, do not POST in the changeset end. When you create an order that should still occur in the respective CREATE_ENTITY method. You then pass back the entity body. It's no wonder that you don't get any response content.

In your abstract scenario above, you didn't specify that is was an order creation scenario. Is this just one order with various segments and items or is it multiple orders?

Assuming that you might be doing one order with some lines, it should be something like this.

• Open changeset
• Post item 1
• Post item 2,
• etc.
• Post order header
• End changeset.
• When the DPC runs, you can pre-cache the items in the item creation method each time it is called. You can write out a simple generic order key with a sequential differentiator (item counter) to the entity return. This will serve to fill the batch response, you don't really need this.
• When the order entity is created, you pull all the cached data, create the order and get the ID back from the API. Finally push the order entity back.

All of this happens before the changeset end method.

p.s. "it's more for the benefit of OData parsing than the consumer getting a response.", essentially means that a key is required to provide the URI for the resource just created. The full entity is sent back but the OData parser is really only uses that in order to extract the contents that provide the canonical key. Getting it back in the return is a bonus and I personally think that is error-prone as it is not the true state.

[Former Member · Accepted solution]

Hi Ron,

Thanks for the detailed answer. Just one question : If the requests are sequenced in the batch like you have listed, is it guaranteed that  post methods are called in same sequence? My fear is would Post order header not trigger before post item1 ?

• Open changeset
• Post item 1
• Post item 2,
• etc.
• Post order header
• End changeset.

It could be that I am not understanding SAP documentation correctly here, but I'm referring the below underlined statement which makes me ask the above question. Thanks for your patience.

A change set is an atomic unit of work that is made up of an unordered group of one or more of the insert, update or delete operations. Change sets cannot contain retrieve requests and cannot be nested, that is, a change set cannot contain a change set.

Regards,

Seetharam

[Former Member · Accepted solution]

Hi Ron,

Do you have any feedback on the clarification I requested above with sequencing. I'm trying to confirm if the sequence in which Methods in DPC class are triggered is always going to be same as the individual requests appear in the request body of Batch request.

I'm inclined to follow your suggestion and cache data in the create_item method and finally create try to create the order in Create_header method. I just want to be 100% sure about the sequencing.

Regards,

Seetharam

[Former Member · Accepted solution]

Hi,

I do not know why they say "unordered", as a LUW can require a certain order of operations. While there may be a feature now or in future that could paralellise the operations, it should not do so within a LUW.

I am pretty certain from my own observations that the payload is deserialised so that the operations occur in the order provided. Doing it another way would actually be harder to implement in the GW engine.  If that's not the case, you'll soon find out. Experiment!

Ron.