Commit Handling 

If the Integration Engine is being used, then transactions are basically processed as follows:

...

       1.      The application temporarily writes application data to its database tables.

       2.      The Integration Engine is also called in the same transaction to inform the communication partners about the changes with a message, M.

The message M is temporarily written to the Integration Engine database.  The Integration Engine is called with QualityOfService = ExactlyOnce (corresponds to tRFC) or QualityOfService = ExactlyOnceInOrder (corresponds to qRFC).

       3.      The application ends the transaction with an explicit COMMIT WORK (or ROLLBACK WORK if an error has occurred).

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 (separated asynchronously) is released. In the case of rollback, all temporary database entries are discarded.

Comparison with RFC-Based System Procedure

How does communication using the Integration Engine compare with the RFC-based system procedure?

Database Commit for Synchronous Calls

Synchronous Integration Engine calls are flagged using QualityOfService = BestEffort.

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 saves all previously temporary data to the database (just like for a COMMIT WORK). This data can no longer be reset by a ROLLBACK WORK later on.

Transport of Transaction Parentheses for Asynchronous Calls

Asynchronous Integration Engine calls are flagged by QualityOfService = ExactlyOnce (corresponds to tRFC) or QualityOfService = ExactlyOnceInOrder (corresponds to qRFC).

The Integration Engine behaves in much (but not entirely) the same way as RFC communication in an SAP System.

As with tRFC or qRFC, both temporary application data and Integration Engine calls are first written in the database together with a COMMIT WORK (as an atomic transaction).

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

This means that the individual calls do not transport the transactional parenthesis to the target system of the call. This contrasts with tRFC and qRFC, because if the target system of the calls is identical, then the calls that took place within a transaction can also be processed in a transaction by the receiver.

Example scenario:

...

       1.      The application writes application data to its database tables.

       2.      Integration Engine is called for the first time:

(QualityOfService = ExactlyOnce / ExactlyOnceInOrder)

Message M1 generated

       3.      Integration Engine is called for the second time:

(QualityOfService = ExactlyOnce / ExactlyOnceInOrder)

Message M2 generated

       4.      Application ends transaction with an explicit COMMIT WORK.

The COMMIT WORK writes the application data (from step 1) and the message data (from step 2 and step 3), in other words the messages M1 and M2, to the local database. At the time of execution, or sending (asynchronous call), M1 and M2 are always sent independently of each other and are also processed independently in the target system (with a COMMIT WORK for both M1 and M2).

·        QualityOfService = ExactlyOnce

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. Later (or even beforehand because of parallel processing), M2 is processed with its own COMMIT WORK. The processing sequence of M1 and M2 at the receiver cannot be determined in advance.

·        QualityOfService = ExactlyOnceInOrder

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. 

This means that message M1 is sent 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 calls that write as well as synchronous calls within transactions (both in the Integration Engine and also in RFCs) can lead to data inconsistencies.

Synchronous Integration Engine Calls Within a Transaction

What happens if synchronous Integration Engine calls are executed within a transaction?

The principles shown above clearly define the behavior of synchronous Integration Engine calls (QualityOfService = BestEffort) 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 develop.

Scenario:

...

       1.      The application writes application data to its database tables.

       2.      The Integration Engine is called with QualityOfService = BestEffort.

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).

This action means that the implicit DB_COMMIT saves the application data from step 1 in the database after step 2 (see Database Commit for Synchronous Calls above).

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

Synchronous Integration Engine Call with Actions at Receiver

What happens if you execute, write, or change actions at the receiver within a synchronous Integration Engine call?

Inconsistencies can also occur in this case. Synchronous calls (both RFC and Integration Engine calls) cannot guarantee that the write or change process is unique (database inserts or updates). If the synchronous call does not return (for example, due to a communication error), the caller does not know whether the call was successfully completed at the receiver end or not.

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

Asynchronous logs (QualityOfService = ExactlyOnce corresponding to tRFC or QualityOfService = ExactlyOnceInOrder corresponding to qRFC) avoid data inconsistencies. Furthermore, these logs trigger the renewed attempt at communication and execution independently, as long as the receiver does not confirm that the call has been successful.  Therefore, write calls and calls within transactions must only be executed with asynchronous Integration Engine logs.