When you send a message to a service and you get success back, you can expect that everything went find. But what if the return message informs you about a problem? What if you do not get any message back at all?
In the optimal world, a change should be made only in case we geet a success message. In all other cases the transactions should be rolled back. For this, a technology called 2-Phase Commit (short: 2PC) was developed. It is just one handshake more. Before sending the success message all data gets "prepared to commit", then the success message is sent and the receiver acknowledges its receive so the data can be finally committed. Do use this technology, there is one important requirement: The target systems have to support it. While it is quite standard for RDBMSes, for ERP systems, WebServices etc it is not. Since DI was build with the focus of ERP systems, we do not use 2PC at all. But this does not mean we do not care about guaranteed delivery at all!
If we look at the previous example, we did load the Order into a target table. Could it be that we returned a success message while the data was still waiting to be inserted? No, the return message is only sent at the very end, when all processing is done. So even if there are two none related branches of processing. If a processing error occurs the Flow will raise an error and no success message is sent at all.
Could it be that the data is inserted in one table but not the other? Theoretically yes, depending on the commit size and the number of inserts to be made. However, the table loader supports a flag "Include in Transaction" for that. In this case all SQLs of all tables of one datastore(!!!) are executed via one transaction.
Could it be that we commit the data but failed to return the success message? We commit the data at the very end, right before sending the response message. So it could happen, it is just very unlikely.
Can it be that we take the input message, fail to process it and do not put it back for retry - thus effectively loosing a message? No, a message is taken out of the queue only once the result message is returned. Inside the Access Server we do support full guaranteed delivery.
So at a summary, we do support Guaranteed Delivery on a "at least once" bases. We can guarantee that no message is lost, but it might happen a message is retried to be processed although is was inserted into the database already. Unlikely but it could happen. So set AutoCorrect load turned on or do anything to deal with that case and you do not have any problem - if that's possible.
btw, EAI tools work exactly the same way in case the target system does not support 2-Phase Commits.