The central idea of updating the database of the application is to do all necessary updates of the database during the final Save-process of each business transaction. Thus when saving a transaction all updates are executed and all files are created within one step and in one database transaction. For the unlikely event, that this business transaction will not run through the work flow (e.g. will not be released during control or release on another transaction that will itself not be approved ) the contract status before the transaction will be automatically reestablished by applying a contract before image for each contract that is stored or updated when saving the business transaction.

To control the logical consistency the transaction normally passes the following main steps and services, which control the overall sequence of the transactions.

1. Start of a business transaction
2. Save of a business transaction
3. Checking for complete signature
4. Check for predecessors
5. Make the transaction final (irreversible)
6. Cleanup the transaction specific data

Additional as many services as needed for the individual installation might be used. The handling of the sequence of the services is defined by the database table SRO which defines the logical dependency of the different services by predecessor rules.

During the startup of a business transaction the transaction logic checks for the existence of the affected contracts including subcontracts like document sets and optionally lock's them. If the logic detects any affected contract where there are non final transactions pending - these may be waiting for release or wait for the execution of other services - a warning is issued to inform the user, that the data used is not final. If a contract which should get locked is locked by another user or task an error message is issued and the transaction is terminated.

At first all logical checks of the business transaction are executed. If there are no error's the contracts are updated and all message files and other depending data is written. During this process the schedule of all services required for this pending transaction are evaluated and the stored transaction together with this schedule is passed to the workflow system to be handled. The user-id of the entering user is passed to the signature handling function and stored in the transaction data.
Depending on the implemented control & release method and the signature information of the current user the transaction might have all required signatures and the pending transaction could thus pass the release service on first try.

The purpose of the checking for complete signature service is to check whether all required signatures are applied to a pending transaction. When a combination of signatures is applied to a pending transaction which fit to the implemented control & release methods the pending transaction will pass the release service.

This service is independent to the release transaction visible to the user. The release function visible stores the release signature and call's the “checking for complete signature” service. The service itself checks whether the entered signatures of the pending transaction suite the release requirements. If so, the service is passed successfully. Otherwise the pending transaction keeps waiting for more and / or other signatures.

This service gives a possibility to serialize the execution of certain services to be able to guarantee the correct sequence. To do this the service checks whether there are any predecessing pending transactions which are not marked as final. If there are any, the service will keep waiting until all of them are marked as final. If all predecessors are marked as final, the service is successful and the succeeding services of the pending transaction might be executed.

With this service the pending transaction is marked as irreversible, to let succeeding services be executed. Thus other pending transaction which are depending on the affected contracts of this pending transaction could pass the check for predecessor service.

After having executed all services, a cleanup service could be entered in workflow to cleanup the before images and other pending transaction and/or transaction history data. The type of data to be cleaned could even include the created messages, if the bank really does not want to keep them in the system (which would be quite unusual).