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:
- Successfully. Any associated services receive a successful notification and can commit their work with any external resources with which they are associated.
- General Failure. The associated services receive notification and perform a rollback as required.
- Fail Service Execution. A Fail object can be included in the process flow to signal a failure, which is handled as a general failure, but under program control.
Note that the use of a Catch object in a process flow provides error handling, and thus the outstanding failure is ignored. The process flow can use a Fail object to terminate the flow from within the catch handling if desired.
There is also a Retry object available, 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.
The Retry and the Fail objects are available in the process flow palette under the Exceptions section as shown in the following image. The Catch object is available under Flow Control section.
