Commit Handling

When using the Integration Engine , transactions are processed as follows:

1. The application temporarily writes application data to its database tables.
2. The Integration Engine is called in the same transaction to inform the communication parties about the changes with a message.

   The message is temporarily written to the Integration Engine database. The Integration Engine is called with quality of service Exactly Once (corresponds to tRFC ) or Exactly Once In Order (corresponds to qRFC ).

3. The application ends the transaction with an explicit COMMIT WORK (or ROLLBACK WORK in case of error).

   This saves all temporary data (application data, recorded messages of the Integration Engine) to the database. Furthermore, the message data for sending and processing by the Integration Engine is released (separated asynchronously). In the case of rollback, all temporary database entries are discarded.

Database Commit for Synchronous Calls

Synchronous Integration Engine calls are characterized by the quality of service Best Effort.

The Integration Engine behaves in the same way as RFC communication in an SAP system:

If a synchronous RFC is executed during a transaction, the system executes database commits (DB_COMMIT). A DB_COMMIT executes a final save for all data that was temporarily written to the database (as with COMMIT WORK). This data can no longer be reset by a ROLLBACK WORK later on.

Transport of Logical Unit of Work for Asynchronous Calls

Asynchronous Integration Engine calls are characterized by the quality of service Exactly Once (corresponds to tRFC) or Exactly Once In Order (corresponds to qRFC).

The Integration Engine behaves much in the same way as RFC communication in an SAP system:

As with tRFC or qRFC, temporary application data and Integration Engine calls are written together to the database with a COMMIT WORK.

However, unlike tRFC or qRFC, different Integration Engine calls within a transaction are sent in different messages. Each Integration Engine call generates its own, independent message.

The logical unit of work comprising the individual calls is not transported to the target system of the call. In contrast, with tRFC and qRFC the calls that took place within a transaction are also processed in a transaction at the receiver (if the target system of the calls is identical).

1. The application writes application data to its database tables.
2. Integration Engine is called for the first time

   (Exactly Once / Exactly Once In Order)

   Message M1 generated

3. Integration Engine is called for the second time

   (Exactly Once / Exactly Once In Order)

   Message M2 generated

4. Application ends transaction with an explicit COMMIT WORK.

The COMMIT WORK writes the application data from step a and the messages M1 and M2 to the local database. However, at the time of execution or sending (asynchronous call), M1 and M2 are always sent independently of each other and are also processed independently of each other in the target system (with a separate COMMIT WORK).

• Quality of service Exactly Once

  M1 and M2 are sent by the sender Integration Engine independently of each other and in parallel. In the target system, M1 is processed with a COMMIT WORK. Independently of this, M2 is processed with a separate COMMIT WORK. The processing sequence of M1 and M2 at the receiver cannot be determined in advance.

• Quality of service Exactly Once In Order

  M1 is sent by the sender Integration Engine. Only when message M1 has been successfully persisted (for example, in the receiver Integration Engine) is M2 sent by the sender. This sequence is maintained, including application calls.

  Message M1 is transferred to the application in the target system, and is completed with a COMMIT WORK.

  If an error occurs in the application for M1, then the processing of further messages (M2 and all subsequent messages in the queue) is blocked. When M1 has been saved, M2 is transferred to the application and is saved with its own COMMIT WORK.

Transactions and Synchronous Communication Using the Integration Engine

Synchronous Integration Engine Calls Within a Transaction

The principles shown above define the behavior of synchronous Integration Engine calls (quality of service Best Effort) within transactions. The way the Integration Engine responds corresponds exactly to the way we know synchronous RFCs respond when used within transactions. In other words, inconsistencies may occur.

1. The application writes application data to its database tables.
2. The Integration Engine is called with quality of service Best Effort.

   The message M1 is generated and sent synchronously, in other words, an answer is expected.

3. The application ends the transaction with an explicit COMMIT WORK (or ROLLBACK WORK in case of error).

The implicit DB_COMMIT saves the application data from step a in the database after step b (as described in Database Commit for Synchronous Calls above).

If the synchronous Integration Engine call should fail (due to a Return with application or system errors), the application data from step a can no longer be rolled back with ROLLBACK WORK. Consequently, this causes inconsistencies.

Synchronous Integration Engine Call with Actions at Receiver

If you execute write or change actions at the receiver within a synchronous Integration Engine call, this can cause inconsistencies.

Synchronous calls (both RFC and Integration Engine calls) cannot guarantee that the database inserts or updates are unique. If the synchronous call does not receive a response (for example, due to a communication error), the caller does not know whether the call was successfully completed at the receiver or not.

A repeat call (if successful) will make the change again in the database in each case. This may cause DUPREC errors (Duplicate Record), in other words, when the system attempts to write a second database record with an identical key. This can cause system crashes (RABAX), or data inconsistencies.