Transaction Model

This part of the documentation deals with the following questions:

Transactions

A transaction is a Logical Unit of Work (LUW). Such a unit defines an inseparable sequence of database operation that transforms the database (DB) from one consistent state into another. This implies that when calling a transaction, the DB operations must be executed either completely or not at all ("all or nothing" principle). In this sense, transactions are atomic.

Transaction Model for BAPIs

When using BAPIs, you must consider the difference between BAPIs released before Release 4.0A and those released as of Release 4.0A.

Release 3.1

In the transaction model supported as of Release 3.1, there is exactly one transaction for each BAPI call.
All function modules that implement the respective BAPIs for Release 3.1 have a commit control mechanism integrated. At the end of each BAPI that causes database changes (writing BAPI) the system always calls the ABAP statement Commit Work. Therefore, all BAPIs up to Release 4.0A are atomic.

 

Release 4.0 A

Starting with Release 4.0A, the commit control mechnism was taken out of the writing BAPIs; it can now be taken over by the client program. Therefore, it is possible to combine several BAPI calls into one transaction (LUW) and terminate the transaction using an explicit commit. To trigger this commit, the client program must call method CommitWork.

Note

In the 4.X systems, both the new and the older BAPI versions (Release 3.X) are included. Therefore, we recommend that the client programmer checks which transaction model the BAPI in use supports. This information is included in the BAPI documentation.

Transaction Model for Remote Functions

The remote function modules of the function library can be based on both transaction models, independent of the release. Therefore, the programmer of the client application is responsible for checking for each remote function module whether the module uses the implicit commit control mechanism or not.

Using Method Commit Work

The client must explicitly call this method of the business object to terminate a transaction in the Release 4.X model successfully.

Calling CommitWork( ) has these effects:

In this case, the client implicitly triggers SetComplete( ).

Using Method SetComplete

Calling CSapBaseProxy::SetComplete ( ) has the following effects:

Calling SetComplete( ) frequently thus increases the efficiency of pooling.
This is the reason why we recommend to call SetComplete( ) in the C coding of the generated file ObjectType.cpp (see also Generation Process) immediately after implementing the method calls of a business object (CallFunction … EndCallFunction), that is, directly after method EndCallFunction.

However, if a business object directly calls SetComplete( ) with IObjectContext::SetComplete( ), the object is stateless for the MTS.
This has the following consequences:
After terminating the current method call, the MTS releases the business object. For the next method call, the MTS creates a new instance of the business object, which is not initialized ("just in time activation").
In particular, the new instance has neither a destination nor the key fields assigned to it. Therefore, after each call of SetComplete you must set the destination, the corresponding logon data, and the key fields of the business object again. This is the price the MTS asks for its services (remoting, security, pooling, transaction support).
Only if you want to increase the application scaling by using stateless objects in the MTS (that is, by explicitly calling SetCcomplete( )), you should generate the proxy objects against the RFC interface rather than the BOR interface. See also Including Several BAPIs Into One Transaction.
Then you do not need the round trips to set the respective key fields again. Programming with stateless objects becomes easier if these objects have a fully specified default destination (with predefined userID and password) as it is usually the case in the WEB scenario. See also Scenarios and User Mapping.

Using Method SetAbort

Method SetAbort is called if an error occurred that cannot be corrected. If, for example, the DCOM Connector determines standard exceptions in the RFC communication with the R/3 system, SetAbort is called implicitly. Calling SetAbort deletes the assignment between resource and object and returns the resource to the pool. In addition, it deletes the current R/3 user context in the application server and triggers an ABAP Rollback Work. All data changes made within the transaction are then rolled back.

Including Several BAPIs Into One Transaction

The Release 4.0A transaction model allows you to combine several BAPI calls of one business object into one transaction and to terminate the transaction by explicitly calling method CommtWork. The generation process of the DCOM proxies in this case deviates from the standard generation process of the BOR proxies using the DCOM Object Builder.

Procedure

To include several BAPIs into one transaction, proceed as follows:

  1. Check for all business objects to be generated whether the BAPIs you want to use in the client contain an implicit commit control mechanism.
  2. If all relevant BAPIs contain an implicit commit, in the DCOM Object Builder choose the R/3 component Business Objects to use the procedure for the standard generation of BOR proxies. See Using the DCOM Object Builder.
  3. Otherwise, in the DCOM Object Builder choose the R/3 component Function Groups to generate all required BAPIs directly from the underlying function modules. Then flag the relevant function modules for generation.
  4. Combine all function modules you want to include into one transaction into one RFC proxy.

Result

The corresponding MTS business object supports all methods required for a transaction.
However, note that for RFC proxies no InitKeys method is generated, so that for each BAPI call you must set the appropriate key attributes again.