Mapping Flow transactions

In integration engine terminology, a transaction is a set of operations that is considered as a single consistent block and is completed or canceled as a whole.

A good example of a transaction is the transfer of funds, let’s say 500 USD, from a customer's savings account to a customer's checking account. From the bank point of view, this is a single operation, but it involves at least two separate actions: debiting the savings account, and crediting the checking account. If either one of these actions does not succeed, the books of the bank cannot balance at the end of the day. Aggregating both actions into a single transaction ensure consistency: the whole transaction is canceled if either one of the action fails, the whole transaction is completed if both actions succeed.

The processing in a Mapping Flow is composed of at least three transactions:

  • Start transaction that covers the operations performed by the start event
  • Instance transaction where data processing takes places
  • End transaction that is composed of end-event actions

These three transactions are independent of each other: data generated by the start trigger is sent to output whenever the input data processing completes successfully or not.

Furthermore, input data processed by the Mapping Flow can be composed of several chunks of data called instances. Usually, all instances are processed within a single transaction (the instance transaction) but when error recovering is active, a transaction is created for each processed instance. Error recovering is a feature of the Mapping Flow that you activate by checking continue on error in the Flow properties window in the Axway Mapping Services.

The following graphic shows when transactions are started, completed or canceled in several situations:

Messages for transactions that are started, completed or canceled

Although all situations in this graphic show both start and end transactions, this is not mandatory: start events and end events are optional.

Another key point in this diagram is the way the error event acts (situations 4 and 5). When the error occurs, the current instance transaction is canceled. In those situations, only operations related to the processing of instance #2 are discarded because recovering is active. Then, the operations related to the error event are performed as part of the current transaction, and therefore, an empty instance transaction. According to the results of the error event, these operations might be completed successfully or, again, canceled.

Basically, actions performed by the engine inside a transaction are output data generation. When a transaction is completed, output data is kept in a permanent storage area with the aim of being sent to the next activity.

The action of completing a transaction is called committing (or simply commit) in computer terminology. The opposite action, that cancels a transaction and therefore destroys generated data, is called rolling back (rollback).

Related Links