BPM: Problems with "Conditional Intermediate Event (Boundary)" on multi-instance task

[hi-ko]

The boundary conditional event is not synced with flow execution. It is checked in-idle.

OK, that explains the behavior. The boundary conditional event is checked async and therefore the last task may complete the sub-process earlier and then the boundary conditional event will never fire.

[yuri]

Added to docs about in-idle checking.

The limitation with boundary event not being in sync was dictated by performance trade-offs.

Regarding not returning collection through a boundary event. My option that it would be not a good design choice to do so as it introduces edge cases. E.g. not all sub-processes instances has been started, or some sub-process instances have already prepared needed data, some -- not.

[yuri]

Return data not being passed to the boundary flow is not related to the fact that the sub-process is multi-instance. It's not passed by design. We can call it the limitation of the implementation. It can be worked around currently. Unfortunately, we cannot address this problem soon, as it's not a bug.

> The "Conditional Intermediate Event (Boundary)" does not fire, if the current task is the last of the sublfow's inputCollection. As a work around one would need a exclusive gateway in a later step to check the custom fields written by script before.

I'm not sure I understand. If I understand right. The boundary conditional event is not synced with flow execution. It is checked in-idle. It's how it was designed, not a bug. We can call it the limitation of the implementation.

[hi-ko]

Two observations that are at least “unexpected” and could be important to know for others when using multi-instance tasks in bpmn workflows:

• When using a "Conditional Intermediate Event (Boundary)" to interrupt a multi instance task (e.g. when first reviewer denies), the multi instance subflow will not write the return/return collection variables to the parent flow and therefore any following tasks will not have access to the subflow's outcome. As a work around the outcome like the tasks resoluiton or resolutionNote should be written additional to a custom field in the related entity by a script task in the multi instance subflow.
• The "Conditional Intermediate Event (Boundary)" does not fire, if the current task is the last of the sublfow's inputCollection. As a work around one would need a exclusive gateway in a later step to check the custom fields written by script before.

I would consider at least the second point to be a bug. The first point should be addressed by always writing the return/return summary variables - regardless of whether the sub-process has ended by completing all parallel tasks or has been stopped by a boundary event.

[hi-ko]

That's what I ended up for now. I write in a hidden entity text field in the sub-flow task and then read that in a later in a script task of the parent flow into variables to have them available in email templates.

My suggestions for improvement would be:

• access the variables of a subflow via a script or always expose return variables / return collection variables as a finally method before continuing
• pass flow's linked entity into the context when executing an email template in an email task (currently I read all required entity data required in the template into flow variables).

[yuri]

Using an entity to store needed data could work.

[hi-ko]

Hi yuri, thanks a lot for your prompt fix! Now the flow continues as expected.

Since return variables are not returned to the parent process for an subprocess which is interrupted by an boundary event:
do you have a tip/advice how to access the outcome of the review task inside the multi-instance sub-process from the main process?

[yuri]

I found the reason. It interrupted the sub-process node before preparing nodes outgoing from a boundary event. From code, it seems as it was done intentionally. I changed the logic (execution order) for all boundary event types. Did some manual testing and run integration tests. Seems works. I'm going to make a release.

[yuri]

I managed to reproduce the "Attempted to continue flow of not active process" error.

[yuri]

It will be easier if we handle issues separately. Concentrating on a single issue in a moment.

I'd start with the parent process being stopped.

Did it start to happen only after upgrade? Did it work before?

[hi-ko]

Hey Yuri,
thanks a lot for your prompt response. I will create and attach a minimal example asap.
to your questions:

• The effect that the main process ends too early (probably due to the boundary event) is a new - even with the inclusive gateway. I added the inclusive gateway in the hope that we can wait for the multi-instance sub-flow to complete the variable collection.

• Do you mean it's not available in the flow outgoing from the boundary event? I believe it never worked that way.

  yes, that's what I mean. In another workflow we had at least access to "return variables" set in the multi-instance sub-flow.
  The use case is to run the review many times in parallel but to stop the sub-flow if any sub-instance chooses "changes" but then we need access to the "changes" details to inform the others. As a work around I could try to write to a variable in the parent process via script but I would prefer to always have access to the instance-collection from the parent process.

The bug would then still be that the parent process ends as soon as the boundary event fires. The parent process should continue until the end.
I'll try to isolate/reproduce that issue in a minimal workflow ...

[yuri]

The converging inclusive gateway requires parallel flows to be active. If there's no two parallel flows in the moment one of the flows arrived to the gateway, it will fail by design.

[yuri]

I'm also not sure whether it's correct to use the inclusive gateway. Maybe a parallel gateway is needed instead.

[yuri]

> the multi-instance subprocess does not write the "Collection Return Variable",

Do you mean it's not available in the flow outgoing from the boundary event? I believe it never worked that way.

[yuri]

> the event is not only cancelling the sub-process but also the main process. Then in a later "Send Message Task" fails with status 500 because the process already ended

Did it work before v3.7?

A minimum reproducible example would be very helpful. From the experience, I can say that it can take hours to reproduce without having a concrete min example.