Triggering a second transaction

[Former Member]

Hi experts,

Is there a way to trigger a second save transaction from within a determination?  We are facing a situation where, when saving to a BOPF table, another standard table has to be maintained. 

In a normal situation we can control the two updates via the BOPF commit, but because of some unfortunate circumstances, the standard table has to be updated via an RFC call.  This means that the update of the standard table is already committed before the BOPF commit has succeeded, leaving room for inconsistencies between the two tables. The user should receive an error message if any of the two updates failed.

The current idea is to work with a status variable in the BOPF node:

- transaction 1 = BOPF update + commit; status = update pending;  for changed made by user

- transaction 2 = standard table update + commit; status = active; via determination after load, for all records where status = update pending.

I could trigger the second save via the transaction manager instance from the FPM application controller, but the BOPF model should also work from outside the FPM application.

I'm aware that this approach is not optimal.  Any other strategies to tackle this problem are welcome

Thanks in advance!

Kind regards,

Bjorn

[former_member190794]

Hello Bjorn,

if I get you right, the after loading shall trigger the second transaction in that proposal. This would be some kind of lazy execution of the second transaction. An alternative would be to trigger the second transaction out of an AFTER_SUCCESSFUL_SAVE determination. Those determinations are immediately invoked after the BOPF's save phase (here the save phase of transaction 1) is successfully done.

Best regards

Tilmann

[Former Member]

Hi Tilmann,

Again thank you for your response! Using an after successful save (after commit) determination was also my first idea. But when I use the factory class to obtain the transaction manager, the framework detects my BO instance is still in state after successful save, and only the interaction state is allowed as next state:

    lo_txn_mngr = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ).

     lo_txn_mngr->save( ).

A similar check occurs in the after load case, when obtaining a new transaction manager instance. (method callstack restriction)

Would you happen to know if there is another way to access the existing transaction and service manager from within an after load determination? I tried with io_modify-->do_action( "save" ) but I suspect this is only possible for custom actions, having an action class.

At the moment I'm looking at the option to obtain the transaction manager from a new process, via a 'starting new task' function module.

Please let me know if you see other options

Thanks!

Kind regards,

Bjorn

[thomas_deubel]

Hi Bjorn,

did you find an option?

Kind regards,

Thomas