What product/components do you use and which version/fix level are you on?

IntegrationServer 10.11

Is your question related to the free trial, or to a production (customer) instance?

customer

What are you trying to achieve? Please describe it in detail.

I’m trying to figure out whether I stumbled on a bug or not. Consider the following flow service with a minimal try-catch-finally structure, but as a child of a regular sequence:

My understanding is that the FINALLY step should always be executed, irrespective of the exception that is thrown in the TRY step and irrespective of how the parent is configured.

However, I find that the Exit on setting of the main sequence influences the try-catch-finally steps: if Exit on is SUCCESS, then the FINALLY step is not executed. However, if Exit on is FAILURE or DONE, then the FINALLY step is executed as expected.

Is this expected behaviour? It strikes me as odd and undesirable. It seems to me that the try-catch-finally steps should always behave the same and independent of how the parent is configured.
Admittedly, by default the ‘Exit on’ setting of a sequence is FAILURE, so one would need to actively change this setting in order to trigger this behaviour.

Why do you want to combine “Exist on done” with try-catch-finally? It sound for me like a conflicting and confusing implementation. As “Exist on done” is here higher in the flow hierarchy and it is not clear which technique should be the leading one. Therefore keep it simple

What about two nested try-catch-finally-blocks? Would that work?

Hi Simon,

the point is not whether it would be smart or logical to combine a sequence with Exit on Success (or done or failure, for that matter) with a try-catch-finally construct. The point it that is a possible construct with - in my opinion - unexpected behaviour.
I’m asking here, I guess, for two things:

• Do you observe the same behaviour?
• Is this the expected behaviour?

If not, then we have a bug on our hands.

I haven’t ventured into nested try-catch-finally blocks. According to the examples I found in the documentation, that should work as expected: all finally-step are executed.

I agree with @Simon_Hanisch1 – it appears to be mixing SEQUENCE behavior with try/catch/finally. What purpose does the parent SEQUENCE provide? Based upon what has been shared, it is unnecessary.

Based upon observations, if you’re familiar with the typical try/catch approach using SEQUENCEs, you may be surprised at the behavior of pipeline handling in the new try/catch blocks.

SEQUENCE (exit on success)
…SEQUENCE (exit on fail; try)
…SEQUENCE (exit on done/fail; catch)

In the catch sequence, the pipeline is in the same state as it was before entering the parent sequence. Any pipeline vars introduced in the try block are not present. If you want them, need to get them via the getLastError and the pipeline var.

For the new:

try:
catch:
finally:

In the catch block, the pipeline is in the state it was when the exception is thrown. Which may or may not be desirable, depending upon what the catch block does.

Because of this change in behavior, we do not use the new try/catch/finally structure, and still use the “traditional” SEQUENCE structure. For us, the new try/catch added no benefit to offset the increased need for pipeline management.

[Edit]: But it is a fair point that @Ido-Eduard.de_Baat makes – even if there is a parent SEQUENCE, seems reasonable to expect the finally block would still be executed. I know the docs have quite a bit of info describing the behaviors. Perhaps it covers this scenario?

Yes, I noticed the difference in the state of the pipeline in the catch block of the new construct, opposed to the traditional SEQUENCE structure.

@Simon_Hanisch1 , it appears that the try-catch-finally are seen as 3 individual children to the SEQUENCE, so setting the SEQUENCE to “exit on success” will cause it to exit as soon as any of those 3 children are successful. I agree it’s an unfortunate behavior. Fortunately, this behavior can be mitigated by moving the try-catch-finally to a child service.

Unfortunately, the pipeline behavior described by @reamon is not something that is easily mitigated. I reported this pipeline behavior to Software AG last year in SI-467623 and a fix was supposed to have been issued back in August '22 but it fell through the cracks. The support engineer that assisted me is following up with the engineering team to give me a new estimate. I will report it back to you guys once I hear back from them.

For the time being, I have also reverted back to using SEQUENCE-based try-catches because the pipeline behavior of the new try-catch is dangerous in my opinion, as child services can inadvertently remove or change variables in the parent’s pipeline.

Percio