BAPI_TRANSACTION_COMMIT with WAIT = 'X' inside a BADi

[nmirandaghn]

Hi experts, what would be the effect of using the 'BAPI_TRANSACTION_COMMIT' with 'WAIT' parameter equals to 'X' inside a BADi? Would I expect that SAP will commit the data after a final commit later?

Documentation says:

This executes all high-priority (VB1) update function modules in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating), but instead is resumed immediately after COMMIT WORK. However, if the addition AND WAIT is specified, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).

When all high-priority update function modules are completed successfully, the statement executes the low-priority (VB2) update function modules in the order of registration together in a common database LUW.

Best regards

[alessandroieva]

Hi,

the bapi_transaction_commit with wait = 'X' is same use the COMMIT WORK AND WAIT,

then, will wait that the db will be changed for continue.

Ciao,

AI

[nmirandaghn]

That's right however does it commit regardless of a rollback later?

[alessandroieva]

Hi,

yes because this instruction is like the commit work. then, when you call the rollback, you don't have any effect on db.

AI

[alessandroieva]

the difference from the commit is that the "wait" wait before continuing.

AI

[Private_Member_7726]

Actually, there is a nuance (an exception), which I find somewhat "maddening" (because one has to constantly refer back to documentation to be 100% certain):

"In a program called using CALL DIALOG, COMMIT WORK does not initiate the processing of subroutines or updated function modules registered using PERFORM ON COMMIT and CALL FUNCTION ... IN UPDATE TASK and does not close the current SAP LUW. At the earliest, the SAP LUW can be closed by the statement COMMIT WORK in the calling program. Only transactional remote function calls or background remote function calls registered using CALL FUNCTION ... IN BACKGROUND within a dialog module are also started there using COMMIT WORK. Any bgRFCs, tRFCs, or qRFCs registered in a dialog module and not started there usingCOMMIT WORK are not executed."

So in some special/rare cases the behavior may be "context dependent"...

cheers

Janis

[Private_Member_7726]

Hi,

I'm afraid I don't quite understand the question... But no, why would you think that 'BAPI_TRANSACTION_COMMIT' is not a real commit, with or without the WAIT addition?

BAPI_TRANSACTION_COMMIT is basically a wrapper, whose main purpose besides comitting, I believe, is to trigger the refresh of BAPI internal "buffers" (release of resources) by calling the routines registered using BUFFER_SUBSCRIBE_FOR_REFRESH function during by BAPI processing. A "stone age" method of "triggering" all kinds of cleanup and resources release functionality on "after end of transaction". Nowadays BAPIs could, I believe, achieve the same by setting up the CL_SYSTEM_TRANSACTION_STATE=>TRANSACTION_FINISHED handlers.

cheers

Janis

[nmirandaghn]

Yes, maybe I can't explain myself. There's a BADi implementation that I've found where there's a 'BAPI_COMMIT_TRANSACTION' with 'WAIT' = 'X' and there's a SAP Notes which prohibits the use of 'COMMIT WORK' specifically for that BADi.

However I'm confused because the function is called with 'WAIT' ='X' and according to the documentation:

When all high-priority update function modules are completed successfully, the statement executes the low-priority (VB2) update function modules in the order of registration together in a common database LUW.

So, I understand that if I use the 'COMMIT WORK AND WAIT' instead of 'COMMIT WORK' then it's ok to implement the commit that way and I don't violate the SAP Notes.

Hope I'm clear now.

Best regards

[Private_Member_7726]

Ok, that explains. But no, the rules are being violated, I believe (which Notes are those?). The way I would try to work around the limitation:

1) if the DB changes done by BAPI need to be committed regardless of what the SAP standard logic calling the BADI does afterwards, try to call the BAPI from within new SAP LUW (a nested LUW);

or

2) if the BAPI changes need to be committed in SAP standard LUW, remove BAPI_TRANSACTION_COMMIT, switch on synchronous updating using SET UPDATE TASK LOCAL, and register CL_SYSTEM_TRANSACTION_STATE=>TRANSACTION_FINISHED handler method where BUFFER_REFRESH_ALL FM would called.

The way to build a nested LUW is awkward to say the least - one needs to call a program using CALL TRANSACTION or SUBMIT.. AND RETURN. So, if the BAPI call needs anything that is not passable using report PARAMETERS or SELECT-OPTIONS (like internal tables?), one needs to think of a way to pass the necessary data (normally shared memory objects or export to shared memory, where the former is the more complicated but preferred way).

cheers

Jānis