How to preserve value across TRY-CATCH sequence?

I found out that variable value in Flow language couldn’t be preserved across Try-Catch sequence, for example:

[B]MAP -> set string variable "abc" to value "0"[/b]
    [B]MAP -> set string variable "abc" to value "1"[/b]
    [B]EXIT from $parent and signal Failure[/b]
    [B]Invoke: pub.flow:debugLog  (I print the value of variable "abc" here)[/b]

Description of code flow:

  • I set the variable “abc” to value “0”.
  • In TRY sequence, I set the variable “abc” to value “1”.
  • Then, I call Exit from $parent and signal failure. This will make the execution flow goes to CATCH sequence.
  • In CATCH sequence, I call pub.flow:debugLog to print out the value of variable “abc”. Guess what, the value is still “0”. It should be “1” if follow the execution flow.

Why is it like that? Does the TRY Sequence that the scope of value “1” from variable “abc” ?

How to preserve value “1” of variable “abc” from TRY sequence to CATCH sequence?

So far, I think the most possible solution is to put/get the value into static variable in shared java code, thus creating a java service. But I want to try to stay away from java code, so I hope I can meet a solution in just FLOW code.

are there any other steps that can cause the flow to go to Catch before the value is set to ‘1’ ?

you can also try the debugLog just after the value is set to 1 in Try block to check if the value was actually set to 1(whether the step was executed)

Absolutely no.

The point is: if you call EXIT from $parent and signal Failure in TRY sequence, all of value that were set in TRY sequence are removed/missing in CATCH sequence.

Check this first →

Thanks very much for the thread :slight_smile:

I got a better solution from reamon:

Create a java service that accept a string and throw ServiceException, call the java service instead of EXIT from $parent and signal Failure. In CATCH sequence, you can call getLastError to retrieve the variables set in TRY sequence which reside at lastError/pipeline document.

Thus, for the example above, the variable “abc” can be accessed from %lastError/pipeline/abc% by using variable substitution.

Let’s say the java service is com.mycompany.util.throwException. So the code should be like this:

MAP -> set string variable "abc" to value "0"
    MAP -> set string variable "abc" to value "1"
    [B]Invoke: com.mycompany.util.throwException[/b]
    [B]Invoke: pub.flow:getLastError[/b]
    Invoke: pub.flow:debugLog  (I print the value of variable "abc" with %lastError/pipeline/abc%)

The message for ServiceException can be accessed from lastError/error.

The java service that throws ServiceException is simply like this:

IDataCursor cursor = pipeline.getCursor();
String message = IDataUtil.getString(cursor, "message");
throw new ServiceException(message);

-message (type: string)

Here’s an excerpt from the 7.1.x Developer Users Guide on page 176 regarding the SEQUENCE step:
“Note: When a SEQUENCE step exits on failure, the Integration
Server rolls back the pipeline contents. That is, the Integration
Server returns the pipeline to the state it was in before the
SEQUENCE step executed.”

To avoid this type of behavior by webMethods, the following works for me:
In your first initialization step where the individual variable is created, instead create a document type and then add individual variables to this newly created document type. Set the values as desired. When the value is modified in the TRY block, it will be retained thought the rest of the Flow steps.

I am not suggesting that this is a superior solution. I am just merely explaining how I found this “roll back” behavior by webMethods surprising and how creating a doc type worked. I hope this helps.


Hi dcova,

I tried and it works.

Thanks very much for the sharing :slight_smile: