Confusion with 2 changeset begin and end method In ODATA DPC_EXT Class

[Former Member]

Hi Experts,

for batch batch update,create and delete call i am using two methods

/IWBEP/IF_MGW_CORE_SRV_RUNTIME~CHANGESET_BEGIN

/IWBEP/IF_MGW_CORE_SRV_RUNTIME~CHANGESET_END

/IWBEP/IF_MGW_CORE_SRV_RUNTIME~CHANGESET_BEGIN{

      mf_batch = abap_true.  //  this one is an custom attribute i have created for my DPC_EXT class
       EXIT.

}

/IWBEP/IF_MGW_CORE_SRV_RUNTIME~CHANGESET_END{

         CHECK mf_batch EQ abap_true.
  commit work.
CLEAR mf_batch.

}

first of all i am not getting why we write EXIT in changeset_begin method.

Including this also i am getting other 2 method of different interface in my DPC_EXT

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END

So could you please tell me what is the purpose of extra 2 methods?

Regards

Saumya

[ChandraMahajan]

Hi,

Reason for 2 methods --> As the DPC_EXT class implements 2 interfaces /IWBEP/IF_MGW_APPL_SRV_RUNTIME and /IWBEP/IF_MGW_CORE_SRV_RUNTIME hence you will see 2 methods. This is also true for other methods such as get, read, create entity etc.

But to redefine CHANGESET_BEGIN and CHANGESET_END, you need to redefine

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END

Regarding EXIT statement, if the methods do not contain any code ie virtually empty then you could just redefine it with EXIT statement means just exit with empty implementation.

I will suggest to read this document http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40546820-3ea7-2f10-dfab-be373c0da... for more explanatiion.

Regards,

Chandra

[Former Member]

Hi Chandra,

first of all thanks for your reply.Let me explain one example .....

Suppose i have to create 10 entity, so that time i will use batch.And my batch will contain 10 POST

request.For each request of above batch first changeset_begin will call then create_entity then changeset_end will call.As per above sequence changeset_end will call 10 times. if i will put commit work statement inside changeset_end then after creation of each entity commit will happen.

but i want to commit after completion of all  POST request of a given batch.

So my question is, can i calculate or identify total no of request present inside one batch from server side.

Then only for last request i can write commit.

Please Help me.

Regards

Saumya

[Former Member]

Hi Soumya,

Changeset begin will be called at begin of your batch requests.. so there you can declare one global variable and assign value X to it.

In your create entity method you can check for this variable is it 'X'?? if yes then do not commit anything.

In Changeset end method , that will be called at the end of your batch request, you can clear this variable and can commit your work.

hope this helps.

Thanks,

Saurabh

[Former Member]

Dear Saurabh,

Can you explain how you would create this global variable and check for this variable in the create entity method?

As by my understanding (and experience) of the framework, this variable will only be initialized during the first batch request, because only then the method lo_runtime->~changeset_begin is called and because the lo_runtime gets destroyed and is recreated for each batch request.

Also in SAP PRESS  "OData and SAP NetWeaver Gateway", this is mentioned: "In the change-set-begin method, you can, for example, set a member variable to indicate that a change-set processing is taking place. This information can be used inside an UPDATE method to only store changes in memory in order to avoid a commit-work."

This is exactly what I'd like to do, being able to differentiate between batch request or not in the ENTITYSET_UPDATE method, but I don't see how this is possible because of the runtime is reinstantiated and cleared for each batch request and thus that member variable as an indicator is only instantiated for the first batch request, since only then the change-set-begin method has been called..

Any ideas what I'm missing?

Thanks in advance!

[Former Member]

Hi Saumya,

The last time I did a batched update, it was not actually possible to commit in the changeset end. The reason for this is that the batch processor engine counts the number of update calls and if there is more than 1 it will issue the commit itself. This means that the developer or consumer is not required to manage the LUW.

Trying to COMMIT resulted in a runtime error from GW unless there was only one update in the batch.

All of your 10 posts should be in the same changeset. Once all ten are correctly processed, the batch engine will know that it is at end (that's why and when it goes to the changeset_end method) and do the commit. Normally you don't need to redefine the begin/end methods, you certainly shouldn't need a counter.

Can you explain why you felt you needed to do this? Misinformation on the web?

Regards

Ron.

[Former Member]

Hi Ron,

Thanks for your response.  I followed section "Handling of a Batch Request in Gateway" of the SAP guide "How To... Batch Multiple Operations into a Single Request" which states:

The $batch functionality delivers two additional methods to the

/IWBEP/IF_MGW_APPL_SRV_RUNTIME data provider interface.

• CHANGESET_BEGIN

• CHANGESET_END

I tried this because without redefining the BEGIN/END methods I get the following error: "Default changeset implementation allows only one operation." which is raised by the standard implementation of the CHANGESET_BEGIN method.

When implementing this methods as in the example /IWBEP/CL_MGW_RT_SFLIGHT, my implementation of ENTITYSET_UPDATE is called multiple times which is good (skipping the HR function module which triggers the commit via debugger), however because it triggers a commit off course during the first call it raises an error because of the LUW controlled by the CHANGE SET..

Kind regards,

Bjorn