Handling Integration Exceptions

Follow

Overview

One of the challenges in using IBM BPM Standard is determining the correct pattern for handling exceptions encountered when you are calling external systems from a system service running in the background.  This article is intended to provide one pattern for handling this situation.  We will have a followup article to address some of the short comings of this approach.

Note that this is not the only viable approach but it is one the we have found works well for a majority of cases.

Use Case

The primary use case here is an integration where the target system may periodically be down or unreachable causing our Business Process to fail if we don't handle the exception elegantly.  The overall goal is to design an approach that will allow for all of the following requirements:

  1. We do not want the integration failure to cause the BPD to fail.
  2. We would like to wait for a period of time and retry the integration service.
  3. If the service call fails more than a certain number of times we would like to create a task for an administrator.
  4. We want to be able to force a retry of any integrations that failed and are waiting to re-attempt
  5. We would like to be able to handle bulk reattempts so that if a large number of integrations failed during a system outage we don't need to address them singly.

Solution

This diagram shows the overall process we will follow: (Click the diagram for a larger view.)

BPM Diagram for handling integration exceptions

Here are the important details working from the Integration Call out - 

  • An exception handler on the integration call that will catch the integration failure.
  • A decision gateway that will deterring if we have failed more times than is permitted for automatic retry.
  • A message gateway that will wait until either there bulk retry signal is sent, or a certain amount of time has lapsed.
  • An iterator of the retry counter.
  • A human service for the administrator in case this fails more times than permitted.
  • An IME on the human service so once everything is working, all the failed integrations can be told to proceed.

You might want to add a second IME in the message gateway to allow for a targeted retry of a single instance.

Conclusion

This approach meets all of our requirements.  Of course there is some detailed blocking and tackling that will need to be done by your BPM implementation team, such as the integration itself, the IMEs to allow bulk retry and the User Interface for the administrator screen.  However we hope this will help you understand how to make your BPM solution more bullet proof.

In our next article we will create an abstraction to help remove this technical detail from the business user and to allow us to use a common BPD for several integrations.

 

 

Have more questions? Submit a request

Comments

  • Avatar
    Paul Dunbar

    I look forward to the next article on this topic. I'm hoping to see additional patterns for managing these kinds of exceptions in the context of BPDs.

    I would also be thrilled to see get some new ideas for handling the same kinds of exceptions in the context of IBM BPM services where execution state has been saved just prior to the integration point (more specifically, human services).

  • Avatar
    Anders Vinther

    Great stuff... was the followup article posted somewhere?

Powered by Zendesk