[Ask The Community] Creating an Error Handler

I’m glad to start this category “Ask the Community” where I want to write it down all these question you asked me by email or twitter or so on. The idea is to share these questions (without any personal data revelead)  and this way together we can talk about the issue and comment our solutions and improve the one proposed. So, let’s the game begin!

Our first question is about how to create an Error Handler in Business Works, but not a “normal” error handler or any error handler. An error handler with these specifics requirements:

  • You need to provide a retry mechanism when you have an error talking with your DB.
  • You need to provide two different approach to retry:
    • First approach 10 times at 1 minute interval (maybe parametrized)
    • Incremental sleep time approach with no limit and time goes by one minute more than the last one.

Ok, so I’m going to start with my solution but you can collaborate too giving your own or even critize my solution. That’s right too. The idea is we can debate together to achieve the best solution for this concrete problem.

My solution is similar to the one you can see in this picture from the BusinessWorks Studio (version 6.2.1):


Ok, now I’m going to exaplain it a little:

  • First of all, we have the SQL Direct activity the one which is raising the exception we want to retry.
  • Then we have a Retry-On-Error group which is going to retry the operation while an exception have been raising inside the group and it is not catching.
  • And then, we have the most important part here, the Catching zone. If this is the first time you see a Catch zone you can notice some difference from the way you catch an error in TIBCO BW 5.x.

The Catching zone is where we are doing all the work. First we define a Process Variable with some data we need during the retry procedure. We are going to define the following properties inside the variable:


  • retryAttempt: Is the attempt number of the current retry.
  • error: In a flag to indicate if we need to raise an error or not.
  • lastSleepTime: The number of seconds we wait to do the last retry.

Inside the catching zone we have this activities:

  • Assign Activity: We add the value of the attempt number
  • Call Process: We have defined a Helper Process which is going to be responsible to calculate the sleep time and do the sleep activity. This process have this configuration:


Ok, we a Mapper activity to calculate the sleep time we have to wait depending on the current attempt and the last sleep time. Then, after that, we execute the sleep activity and return this information to the next Assign activity.

In this activity we store the sleep Time and the error flag which is going to decide if we raise an error or not.

And, that’s it. This is a simple error handler that meet all the requirements you have. In following posts I’m going to go deep with this approach and provide you the working code for this solution and make some improvements in this approach to be ready for our production environment.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s