Error Handling > 10.3

In general, an exception is an event that interrupts the normal flow of the program’s instructions. Exceptions occur during the execution of a program and terminates the program.

In webMethods, failures can occur in a flow service when an invoked service throws an exception, an EXIT operation executes and signals failure, or the flow engine throws an exception because of a flow definition error. The flow language includes facilities that you can use to handle these failures.

Beginning with Integration Server and Designer version 10.3, the webMethods flow language includes specific flow steps named TRY, CATCH, and FINALLY that you can use to try a sequence of flow steps, catch and handle any failures that occur, and then perform any cleanup work.

Prior to version 10.3, the webMethods flow language did not include flow steps designed for the specific purposes of trying logic and handling any failures that occurred. Instead, some degree of failure handling could be accomplished using steps like SEQUENCE and REPEAT. By nesting and combining SEQUENCE steps with different exit conditions of failure, success, and done, a flow service could provide a limited form of try-catch behavior.

TRY Step

The TRY step contains the sequence of flow steps that you want Integration Server to attempt. The TRY step contains the logic for which you want to provide exception handling via a CATCH step and cleanup work via a FINALLY step.

CATCH Step

The CATCH step contains the sequence of steps that you want executed in the event the preceding TRY step fails. Often, the CATCH step contains recovery logic.

The CATCH step can be configured to handle all failures, specific failures, or all failures except specific failures.

FINALLY Step

The FINALLY step contains logic that Integration Server executes regardless of whether the TRY step succeeds or fails.

FINALY step contains clean up logic that needs to execute regardless of the outcome of the preceding TRY or CATCH steps, such as releasing resources or closing sockets.

Common Patterns for Failure Handling:

• TRY-CATCH
• TRY-FINALLY
• TRY-CATCH-FINALLY

TRY-CATCH

The TRY-CATCH usage pattern consists of a single TRY step followed by one or more CATCH steps. The TRY step contains any number of child steps to be executed. The CATCH step contains any number of child steps to be executed if the TRY step fails.

TRY-FINALLY

The TRY-FINALLY usage pattern consists of a single TRY step followed by a FINALLY step. The TRY step contains any number of child steps to be executed. The FINALLY step contains any number of child steps to execute regardless of the outcome of the TRY step. The TRY-FINALLY usage pattern does not handle any failures that occur in the TRY step.

TRY-CATCH-FINALLY

The TRY-CATCH-FINALLY usage pattern is a combination of TRY-CATCH and TRY-FINALLY.

A TRY-CATCH-FINALLY consists of a TRY step that contains logic to be attempted, followed by one or more CATCH steps to handle any failure that occurs and execute recovery logic. This is followed by a single FINALLY step to perform any clean up.

Now, let's see a example in Designer..

On Catch step - > Properties

Failures : specify expected exceptions classes, basically it's a array. You can specify many classes

Selection : EXCLUCE / INCLUDE  - Whether you want to include / exclude exception classes specified in Failures field.

Eg: Here, the excepted error class is > com.wm.app.b2b.server.ServiceException

Based on your flow, include HTTP, DB, FTP related classes here.

Source: documentation.softwareag.com

Thanks for reading :-)