In some cases it is required to integrate BOPF business objects into existing applications. The invocation of logic implemented in BOPF business objects can easily be achieved by the help of service manager. However, the transactional behavior of the BOPF and the existing application must be also taken into account. For that reason BOPF offers a special Master/Slave transaction manager concept, that is described in the following sections. In the second part, a concrete example shows the implementation of an integration scenario.
In a standalone BOPF application, the consumer ends the current transaction by the help of the standalone transaction manager. It provides the option to make the current transaction undone (called “cleanup”) or to save all changes since the last save to persistency (called “save”).
DATA(lo_transaction_manager) = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ).
While executing the save, BOPF registers by default an update task to write the modifications done in the current transaction from buffer into the database tables. Finally, a COMMIT WORK is executed. However, there are situation that do not allow BOPF to raise a COMMIT WORK. For instance, if the BOPF application is integrated into an existing application or foreign application framework.In that case, a slave transaction manager can be used by the foreign application to prepare the BOPF objects of the current transaction for the saving and afterwards to execute the COMMIT WORK. The foreign application is called master transaction manager as it invokes the COMMIT WORK and ROLLBACK WORK – and not the BOPF:
The master transaction manager (called “Legacy Application” in the picture) has to call Finalize/CheckBeforeSave/… on the slave transaction manager before triggering the COMMIT WORK. This triggers for instance the execution of the finalize determination of the participating BOPF BOs.
DATA(lo_slave_transaction_manager) = /bobf/cl_tra_trans_mgr_factory=>get_slave_transaction_manager( ).
lo_slave_transaction_manager->finalize( … ).
After the COMMIT WORK, the BOPF BOs shall be invoked via the slave transaction manager’s AfterSuccessfulSave core service. This is in principle only necessary if the the participating BOs have AfterCommit determinations configured and it is intended to continue with the next transaction in the same session.
In this document the concept of integration of BOPF business objects and existing applications is decribed. In the second part, an implementation example is provided.