webMethods Flow Service Error Handling Tutorial

A couple of years ago I was withdrawing money from the bank’s ATM machine and I got a message ‘Transaction failed. please try again later!’, so I searched for another ATM machine, and I was surprised that my account balance is missing the amount i was withdrawing in the failed transaction! I don’t want to judge technically as I don’t know if there were better ways to handle this error or not, but it was not a pleasant experience as a customer.

In this tutorial we will try cover the most common ways of error handling for webMethods flow service.

We will cover the following points:

  1. Try-catch block/sequence.
  2. Try-finally block/sequence.
  3. Exception handling for the child services.

Before using any type of error handling you have to decide what is the outcome of the exception handling, for example: to inform the customer/support with the error to take action, or to log the error to investigate later, or to change the direction of the code to fix the problem. Knowing the desired system behaviour will help you choose the right exception handling method.

  1. Try-catch block

The try-catch block works the same way as Java. You execute a sequence of steps, if you faced unexpected exception/error you skip the processing and execute the catch block.

To define the Try-Catch block, follow the following steps:

  • Create a new flow service using SoftwareAG designer.
  • Create a new sequence and call it ‘Main’.
  • Create another two sequence under the ‘main’ sequence, call them, ‘Try’, and ‘catch’.
  • Go to the properties of each sequence and configure the ‘exit on’ as follows:

* ‘Success’ for the ‘Main’ sequence.
*’Failure’ for the ‘try’ sequence.
* ‘Done’ for the catch sequence.

The main sequence has the try, and Catch sequences. So by defining the ‘exit on’ parameter of for the main to ‘Success’, this means that if the first sequence (Try) finished successfully then exit the sequence ‘Main’ and the ‘Catch’ Block/sequence will not be executed.

The ‘Try’ sequence is configured to ‘exit on’ = ‘failure’, which means if one step failed, all the steps following the failed step in the ‘Try’ block will not be executed, and the code will jump to execute the ‘Catch’ block/sequence.

The ‘Catch’ block is configured to ‘exit on’ = ‘done’ which means that each step in the ‘Catch’ block must be executed regardless of the result of each step.

So let’s apply the rules on the following example:


In the example we have childService1, and childService2 in the main ‘Try’ block. If the service childService1 generated an exception, then the service childService2 will not be executed, and we will execute the steps in the ‘Catch’ block in sequence.

In the ‘Catch’ block, we are calling two services ‘getLastError’, and ‘debugLog’ both services are developed by webMethods.

‘getLastError’: is responsible get getting the last exception generated in the flow service. It MUST be the first step in the catch block otherwise it will not return the error.

‘debuhLog’: is used to write the error in the Integration server Log.

This is  a very simple way to handle the errors, and we are assuming that we will log all the error in the Integration server log file. You might save the errors in custom database table or file, you choose the suitable way to store the errors.

2. Try-finally block.

It works the same way as Java. And we use it when we want to execute some steps before terminating the execution regardless of the result of the service. For example you want to make sure to close an open connection before terminating the service.

Here are the step to create try-finally block:

  • Create a new flow service using SoftwareAG designer.
  • Create a new sequence and call it ‘Main’
  • Create two sequences under the ‘Main’ sequence,  call them ‘try’, and ‘finally’.
  • Go to the properties of each sequence and configure the ‘exit on’ as follows:

* ‘Done’ for the ‘Main’ sequence.
* ‘Failure’ for the ‘try’ sequence.
* ‘Done’ for the ‘Finally’ sequence.


The Main will exist only when all the sub-steps(Try, Finally) are executed regardless of the status of execution (success\failure).

The ‘Try’ block will skip the processing if an exception was generated, and all the steps followed the failed step will not be executed.

The ‘Finally’: it will be executed after the execution of the ‘Try’ block/sequence regardless the result of the execution. We configure it to exit on ‘Done’ to make sure that we execute all the steps of the sequence/block.




As you see in the above service ‘SendCommand’, the finally block is:

  • Calling the service ‘getLastService’. It MUST be the first step in the sequence.
  • We are checking if the ‘lastError’ document (the output of getLastError) is present in the pipeline or not, because to log the error happened in the ‘Try’ sequence/block if applicable. Then we call the service ‘closeConnection’ to close the opened connection in the ‘Try’ sequence regardless of the result of the transaction.


3. Exception handler for child services

Rule: the exception is caught only once. So let’s check the following example to clarify this sentence:




In this example we have created the flow service ‘myService’, we are using Try-Catch sequence, in the try sequence/block we are calling the services ‘childService1’, and ‘childService2’.

Here is the code of ‘childService1’




Here is the code of ‘childService2’:



The only difference between the two service is that ‘childService1’ is calling the publish service directly without catching the exception. In ‘ChildService2’ the publish service was called from inside Try-catch block.

Now let’s compare between the following scenarios:

case Expected Behaviour
publish failed in childService1
  • the service will exit the ‘try’ block.
  • childService2 will not be executed.
  • The catch sequence/block will be executed
publish failed in childService2
  • The exception will be caught and handled in the catch block/sequence of childService2
  • The processing of the ‘Try’ block will continue (if there were other steps after calling childService2, it will be executed).
  • The catch block/sequence of the service ‘myService’ will not be executed.
No errors in childSerivce1, or childService2
  • The ‘try’ block will be executed.
  • The ‘catch’ block will not be executed.


This was a quick idea of the most common ways to handle the errors of webMethods flow service.


Thank you for visiting our website. We are looking forward reading your comments and questions.
Follow us:

on twitter: @WM_Expert

Group on LinkedIn: webmethodsExpert.com

(C) 2015 Hossam Elsharkawy. All rights reserved.


7 thoughts on “webMethods Flow Service Error Handling Tutorial

  1. Mahesh says:

    This is useful and also you should have covered using exit from flow and signal failure after the debugLog in the catch block.

    • Dear Mahesh,
      Good point. We are planing to explain it with one of our coming tutorial which will discuss the error handling for business process. The exit step with signal failure is a very important tool if you want to raise exception in the business process or if you want to generate SOAP fault as an output from web service.

      Best regards ,

  2. Sarika says:

    Hi Hossam,

    Having a doubt regarding getLastError service…
    1.Why we need define it as first step in catch block?why cant second step?
    2.If we define getLastError service 2 times in catch block?will both steps executed?

    Would feel happy if i get answers and it would b helpful everyone.


    • Hi Sarika,
      The ‘getLastError’ service will return the error of the last executed step only. So if it is not the first step in the catch block it will not return the error occurred in the try block.

      You can confirm this behaviour by doing a test service.


  3. Sarika says:

    HI Hossam,

    One more doubt…

    In the topic, how to handle exception in child services-
    In second case i.e. when publish failed in childService2, the catch block will be executed right?

    I have seen it practically too that when any child service got failed, the control will be sent back to parent service alongwith the error document and then catch block will be executed.

    Waiting for your response.


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 )

Facebook photo

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

Connecting to %s