Webmethods Flow Service

Error Handling Tutorial
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
 the service will exit the ‘try’ block.
 childService2 will not be executed.
publish failed in  The catch sequence/block will be
childService1 executed
 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).
publish failed in  The catch block/sequence of the
childService2 service ‘myService’ will not be executed.
No errors in
childSerivce1, or  The ‘try’ block will be executed.
childService2  The ‘catch’ block will not be executed.
 

Above were the quick idea of the most common ways to handle the errors of
webMethods flow service.