In order to ensure data consistency when a database error occurs, the application tables must be posted in the same logical unit of work as the IDoc status table. Otherwise a database error, such as "no tablespace", could lead to the following:

• Application tables update correctly, IDoc status update fails: the IDoc has the status "ready to be passed to application" and would be processed a second time, although the data has already been processed.

• IDoc status update succeeds, application update fails: the IDoc has the status "successfully processed" although the application tables were not updated. The IDoc cannot be processed again, so the data never gets to the application.

To ensure that only one logical unit of work is used, the application function module must not commit the data to the database. The data is committed by the ALE layer after the function has been called and the IDoc’s status records have been updated.

This is not possible when the application data is updated via a Call Transaction, since a Commit Work is automatically set at the end of every Call Transaction. In this case the transaction itself needs to be modified, as shown later.

A Call Dialog instead of a Call Transaction avoids the Commit Work, but can only be used if the dialog step contains no PERFORM ON COMMIT statements - since the commit is set via ALE after the dialog has ended, all global variables set during the dialog are lost. Hence a Call dialog should be used with extreme caution!

When the IDocs contain master data (e.g. customer data) the problem is not so acute, since missing data can always be sent again if need be, and processing an IDoc twice does not lead to duplicate documents being created.