Best practices for cluster environment development

The way a message is processed in B2Bi is determined by a sequence of processing steps that are defined in a "flow" for that message. In B2Bi, processing flows are specified for different message types in Service objects.

When a cluster changes (that is, when the node that is processing the message fails) the integration message processing flow automatically restarts on an alternative node in the cluster, from the last processing step that is part of the execution sequence.

For each B2Bi processing step in a flow, the integration engine:

  • Reads input queues
  • Executes a processing activity
  • Stores the output of the activity processing in internal queues
  • Commits the message read

Any processing step that is not fully completed is automatically restarted from the beginning, starting with polling the uncommitted message again from the internal queue.

Because these steps are started from the beginning, it is important to follow a basic programming principle: (using a DB insert as a sample)

It is important to perform the commit of all changes at the VERY END of the processing activity. If the node fails before the end of the activity, the process restarts the activity, and the uncommitted database mutation from the first try is automatically rolled back. A more limited risk remains if the node fails between the database commit and the activity commit.

The following example illustrates a database write activity structure, with the placement of the commit at the end of the activity.

Related Links