Understanding iWay Service Manager Transaction Management

iWay Service Manager (iSM) manages transactions to ensure that multiple actions either all complete or none complete. This is standard transaction management for servers. iSM uses concentric transaction control, addressing the different requirements for a listener or a process flow. Naturally, actual transaction control is influenced by the protocol and external resources themselves, and so, this general discussion must always be considered in light of the environment.

Listener transactions (attempt to) ensure that messages are processed one time only, but are not lost. To this end, messages are read under transaction control. Completion of processing of the message, regardless of outcome, completes the transaction and the message is deleted from the source. For example, the message is picked from an MQ queue and then deleted at the end. On the other hand, if the server should fail during mid-processing, then the transaction does not complete and the message is made available by the original source for re-execution.

Once read, the message is processed by the channel itself. This includes the process flow. During the execution, specific services, such as SQL, can associate themselves with the transaction and receive notifications in a two-phase commit manner as the process flow ends.

The process flow itself can end in one of three ways:

Note that use of a Catch in the process flow provides error handling, and thus the outstanding failure is ignored. The process flow can use a Fail service to terminate the flow from within the Catch handling if desired.

The Fail service can also trigger a Retry, which for supporting protocols causes the original message to be resubmitted following a configured delay. This can be continued until the message succeeds or a configured retry limit is reached. If the retry limit is reached, then the message is considered to be permanently failed. However, this can be reset by configuring a failure event flow.