How to implement a retry mechanism in BusinessWorks 6.X and BusinessWorks Container Edition

This is quiet common in Integration projects to connect to remote applications or systems that are sometimes unreachable or slow for a few minutes, as for example an highly loaded REST API, a remote database or a file system mounted on a remote server.

This blog article explain how to implement a periodic retry mechanism in BusinessWorks to make such errors as much as possible transparent to the BusinessWorks process logic.

Note that the same pattern can also be used in BusinessWorks 5.X.

Creation of properties to manage the retry mechanism

To configure the retry mechanism it is recommended to create two properties:

. One to manage the number of attempts

. One to manage the delay between attempts

It is generally recommended to have a few attempts, say between 3 and 5, and to a delay of a minute between attempts.

Example of properties defined to manage a retry mechanism

In the example above note that the best practice to include the related unit of measure in the property name is enforced for the ‘RetryDelay’ property.

These properties then need to be added in all Processes implementing a retry mechanism:

Adding the properties to the Process context

Use of a Repeat on Error group

The activity connecting to the remote resource then needs to be included in a ‘Repeat on Error’ group, a Sleep activity added and the group configured.

The general structure to use is the following:

Repeat on Error group structure

The Repeat on Error group is configured to exit when the number of attempts is reached:

Repeat on Error group configuration

A conditional transition and a ‘Success with no matching condition’ transition are added to differentiate the first attempt from the following ones:

Transition to manage the first attempt

‘Success with no matching condition’ transition to manage further attempts

Then the Sleep activity is configured with the defined delay:

Configuration of the Sleep activity with the property defining the delay between the attempts

Further error management

Once the specified number of attempts is reached the group ends with an error that is to be managed with an error transition or a ‘Catch’ activity according to your error management strategy.