BAPI_TRANSACTION_COMMIT with WAIT = 'X' within a BADi

Question

What would be the effect of using the 'BAPI_TRANSACTION_COMMIT' with 'WAIT' parameter when equals to 'X' inside a BADi? Should I expect that SAP will commit the data when LUW commits?

I'm aware that inside 'BAPI_TRANSACTION_COMMIT' it happens 'COMMIT WORK' or 'COMMIT WORK AND WAIT' if you specify parameter 'WAIT' = 'X'.

I'm also aware that it's not correct to make a 'COMMIT WORK' inside a BADi, but if I use 'COMMIT WORK AND WAIT' via the BAPI?

The SAP documentation regarding to COMMIT 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.

My confusion arises because we have a BADi implementation where there's a call to the mentioned function with parameter 'WAIT' = 'X' and we have found a SAP Notes where it prohibits the use of 'COMMIT WORK' inside that BADi, however it says 'COMMIT WORK' and not 'COMMIT WORK AND WAIT'.

So I could think that the implementation is right because that data would be commited when LUW finishes ... or not. Any comments?

Plumbery

Answer 1

Actually the LUW finishes when you call COMMIT WORK or COMMIT WORK AND WAIT. The only difference is that COMMIT WORK is asynchronous and COMMIT WORK AND WAIT is synchronous.

The BAPI_TRANSACTION_COMMIT with WAIT parameter set is equal to COMMIT WORK AND WAIT. Without the parameter set it is equal to COMMIT WORK.

And it is true. You must not commit in a BAdI. What if there is a rollback after the BAdI has already executed? It could leave your data in a totally inconsistent state.

Heid

The last part is not entirely correct. Whether it is safe or not to use COMMIT in a BAdI implementation depends entirely on the program that calls the implementation. – Receiver

And how do you tell whether there is commit in the program (that is usually an SAP standard) or not? It is better and safer not to commit or rollback in a BAdI. – Heid

@Heid could you elaborate on this please: "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." – Plumbery

@nmiranda It is about update function modules. Those are called with a sentence IN UPDATE TASK. Look at the first tab called Attributes for any function module in transaction SE37. There you have an option Update Module and suboptions start immediately and start delayed. If the function module is marked as start immediately it means it has high priority and will be executed in VB1. The latter will be executed in VB2. Look at the processes in SM50 you will find at least two processes marked as UPD and UP2. UPD is VB1 and UP2 is VB2. – Heid