BAPI calls in BOPF Actions how-to ?

[Attila]

Hello Experts,

could you pelase clarify, what is the proper way to call BAPIs from BO actions ? I'm doing a BAPI call in my action, which creates a document. After in AFTER_COMMIT determination when saving the transaction, I want to start a workflow, and add GOS attachments to the document created by the BAPI call, but this document not become persistent. What I know, that BOPF does the commit work automatically and the changes to BOPF data are done in an UPDATE task.

May I call BAPI_TRANSACTION_COMMIT in my BO action, or maybe use SET UPDATE TASK LOCAL statement before calling the BAPI? I do not want to "crash" the BOPF phase model with my own commits. The slave transaction manager is for the opposite case as far as I understood, where we do not want to allow the BOPF to commit, so does not apply. Any advice is welcome .

Thank you

Attila

[cyclingfisch_]

Hi Attila,

first of all, yes, you are right, the slave transaction is for the opposite case when BOPF should not control the transaction and the commit is done outside BOPF.

You cannot call BAPI_TRANSACTION_COMMIT in your BO, because BOPF would recognize the commit and would throw an exception as the commit would destroy your BOPF transaction.

It sounds as the data are not commited when your AFTER_COMMIT determination runs. So the SET UPDATE TASK LOCAL might help.

How does your BAPI do the commit handling? Is there an update module called? If yes, how exactly?

In such cases I often place a break-point at the command COMMIT and also activate update debugging. I already found some BAPIs which do an internal COMMIT and therefore caused some problems...

There are also some reasons why the FM BAPI_TRANSACTION_COMMIT should be called: https://wiki.scn.sap.com/wiki/display/ABAP/BAPI_TRANSACTION_COMMIT+versus+COMMIT+WORK

But to be honest, I never did that so far.

Cheers,

Martin

[Attila]

Hi Martin,

I've just seen this, in one of the BOs, that SET UPDATE TASK LOCAL is applied, but probably due an update module was executed. In my case there is no such, but I will debug like you suggest. At the moment this is solved calling the BAPI using an RFC destination pointing to the same system/mandant, bacause the BAPI have to be executed with higher priviliges, than the user who is processing the BO. But I want to understand, and come back with the results after debugging.

Thanks,Attila