Commit work query

[mrudularane]

Hello Experts ,

We are having SOAP to PROXY asynchronous scenario . In which we have provided the web service to third party .

We have written all logic in proxy receiver side .

My query is if we are not writing commit work at the end of the code , then data is not getting saved in table .

So is it mandatory to write commit work at the end for asynchronous scenarios or do we have any alternative ?

Regards ,

Mrudula

[ravicarpenter]

Hi Mrudula,

1. Put an external debug point in your inbound proxy (the user id mentioned in the menu option for external debugging must be same as the service user used for the proxy call)

Once done, trigger your message and check whether insertion is successful or not.

2. Commit work is not required in case of inbound proxy. Commit taken care by the implicit database commit.

[iaki_vila]

Hi all,

I think Mrudula should trace the inbound proxy as Vadim explained, may be there is happening any exception, Mrudula can check the st22 for exceptions or to check the inbound queue on ECC and the sxi_monitor if the monitoring is enabled. Like a first step to try to identify the problem i think it is the better option.

Regards.

[former_member185537]

Hi Mrudula,

Commit work is necessary. Yes. Any kind of update it is necessary.

[vadimklimov]

Hello all,

I'm still concerned regarding general necessity of explicit commit in the described case.

I replicated scenario in one of internal systems - inbound asynchronous proxy call that inserts entries to a custom table - and it works finely well for me without committing them explicitly from proxy interface implementing class, but relying on transaction handling done by proxy runtime for an entirely processed XI message.

Here is a sample code I used in implementing class - as seen, no commit work follows table entry insert:

METHOD zii_test_objects_in~test_objects_async_in.

     DATA:
       gs_json_test TYPE zhr_json_test.

     gs_json_test-data_id = cl_system_uuid=>if_system_uuid_static~create_uuid_x16( ).
     gs_json_test-json_data = 'Test'.

     INSERT INTO zhr_json_test VALUES gs_json_test.

ENDMETHOD.

And here is an outcome, when checking table content:

From an SQL trace for this call, it can be seen that an entry was inserted into a table (highlighted in blue colour) - which is outcome of custom logic originating from interface implementing class, and then commit work was conducted on XI message LUW level (highlighted in red colour):

So if an XI message (and corresponding RFC LUW) was processed successfully, commit is already triggered by proxy runtime. It may be that table entry insertion is not persisted in case further processing of a message failed and proxy runtime triggered rollback work for the entire XI message LUW. And to me, it looks to be a consistent behaviour: if LUW was rolled back, the whole transaction has to be rolled back. If explicit commit is inserted in proxy interface implementation and is triggered successfully at completion of proxy logic execution, but followed by failure in further message processing (and corresponding rollback), rollback will not be able to reverse already committed part of transaction.

Regards,

Vadim

[former_member185537]

Hello Vadim,

Have a look at this 3.0 Inbound ABAP Proxy not executing | SCN

Are you calling the method any where else where there is a commit work that is getting executed ?

[vadimklimov]

Hi Pras,

Thank you, this is definitely good to go through replies in the referred SCN thread, very similar case as we discuss. But I would rather take SAP best practices (described in earlier mentioned SAP Notes 1954060 and  2268877) as a starting point, and any deviation from that shall be a subject for justification and analysis, why it has to be done differently and why approach recommended by SAP didn't work. It doesn't look correct to me to set commit work at the end of inbound proxy logic in case it makes any updates on a regular basis.

From a developer perspective, tracing of proxy call execution shall give pretty detailed information for analysis of commit / rollback occurrence. And an example that I provided above, was supposed to be an illustration that normally explicit commit work is not required in inbound proxy implementation, and transaction gets committed by proxy runtime in case message processing was successful.

I didn't call any commits from elsewhere in the example - code snippet that I provided, was the complete coding of an implemented proxy class. And in SQL trace I posted, it is seen that highlighted commit originates from proxy runtime, after proxy implementation logic is already completed.

So, my suggested idea was to firstly investigate if commit / rollback happened for the processed XI message, and then analyze why it didn't get committed normally (in case that commit coming from proxy runtime is missing).

Regards,

Vadim

[former_member185537]

Hi Vadim,

I agree with you. There should be a commit work at the end of the inbound proxy call which the SAP takes care some where else when passing data to PI. Like in case of outbound where a commit work is mandatory after calling the method without which the data is not passed on to PI from ECC. In the inbound case we are not writing the commit work side by side as against the outbound case. I saw your logs that's detailed enough. Now this becomes the normal activity for the inbound without a doubt.

[iaki_vila]

Hi Mrdula,

It is not necessary to do the commit work, but sometimes when you work with the ECC standard some BAPIs need to do the commit work, i mean, the commit work depends of the functionality that you are dealing.

Regards.

[vadimklimov]

Hi Mrudula and Iñaki,

Explicit commit / rollback work in implementation of inbound proxy logic is not somewhat generally recommended by SAP (see SAP Notes 1954060 and  2268877 that describe reasons behind this and enhanced functionality for proxy runtime that can track commit / rollback occurrences). Proxy runtime is responsible for handling LUW associated with a processed XI message, so explicit interference in XI message LUW commit / rollback within inbound proxy logic may bring transactional inconsistency to a processed inbound proxy message.

Having this in mind, I would suggest figuring out why data is not persisted in tables - for example, by performing ABAP and SQL trace of an inbound proxy message processing and checking if there were any preceding rollback work statements and if commit work statement was triggered during message processing.

Regards,

Vadim

[mrudularane]

Hi Vadim/Inaki ,

Thanks .

But then in that case could you please advise what can be done , if without commit it is not saving the data ?

Regards ,

Mrudula

[iaki_vila]

Hi Vadim,

Thank you for sharing your valuable comment but i've just remember that i needed one time to call the function bapi_transaction_commit because the call a standard bapi didn't do the update, may be i was wrong in any other thing.

Mrudula,

But then in that case could you please advise what can be done , if without commit it is not saving the data ?

If you enter to the ECC with the same user that you have set in your receiver channel in PI, you can set an external breakpoint in your proxy code and to debug if there is any problem.

Regards

[vadimklimov]

Hi,

I agree with you, SAP standard BAPIs don't have transaction commit / rollback - this is done intentionally, because commonly those BAPIs will be called as a part of a more complex LUW logic, and transaction handling is to be done by a caller program, not by a called BAPI. In case of inbound proxy, transaction handling shall be done by proxy runtime. Thus, in my opinion, the most precise way to identify if it worked well or not, is to have an ABAP/SQL trace of a proxy call (e.g. using transaction ST12) and then search for commit work / rollback work. From there, it will be possible to identify if commit work / rollback work was called at all, and if so, track its call stack (and figure out where commit work / rollback work was called from).

Regards,

Vadim