Transaction Support 

Prerequisites

You must be familiar with J2EE transaction concepts. For more information, see Introduction to Transactions in J2EE Engine.

Support for External Services

Web Services (WS)

Transactions are not supported for Web services. You can however execute a Web service in one of the following ways:

●     indirectly via a CRUD or findBy operation

●     directly via generated proxies

Contrary to the transaction commit, the WS execution takes effect immediately for all other users of the represented remote storage. Also, if the transaction is rolled back you do not have any control on the WS calls which have happened during the transaction lifetime.

Remote Function Calls (RFC)

For RFCs, transactions are supported only for BAPI calls. For more information on the BAPI transaction model, see Transaction Model for Developing BAPIs.

Database Integrity

When you work with external services, you must ensure database integrity. To do this, always include the CRUD (create, read, update and delete) operations in transactions.

It does not matter if you are encapsulating the BAPI calls as business entity services or you call them directly from application services. According to the transaction ending, BAPI calls are either committed or rolled back.

Remote Persistency Restrictions

When you use BAPI calls for remote persistency, it is highly recommended to access only one SAP system per transaction, because BAPI calls do not support the two-phase commit (2PC) scenario. For more information on 2PC, see Two-Phase Commit.

Assume that you commit changes to several SAP systems (SAP System 1, SAP System 2 ...) in one transaction. It is possible to commit the changes to SAP System 1 successfully. Since CAF does not have direct control over the storage, if the commit to SAP System 2 fails, you cannot rollback the changes made in SAP System 1.

For local persistency, CAF has full control over the storage and the rollback can be done without problems.