I have a strange situation that I cannot solve, even though reading the docs, it seems that it should be feasible.
We have a task (Java Service Task) that should be invoked after an external event (modeled with a signal) happens. When the task executes, it reads the content of the message that was associated with the event (we serialize the content of such message in the process variables) and acts accordingly. What can happen is that the content of the event may be of interest to only ne of the various instances of the same activiti processes running (think a multi-customer scenario). Plus we're waiting a set number of such events (say 5) in the same process, but we don't know the order in which they come and we don't know at design time how many of these events will happen (process A may have 5, process B may have 3 and a next iteration of A may have only 4). Depending if the event is handled or not by the task, then: - if the task doesn't handle the event, it should just loop back to the signal handler and wait - if the task handles the event, then it should move the execution forward, but ALSO wait again if not all events have come. - if the task handles the event and it's the last, then it should only move the execution forward We have tried in some different way to model this loop all without full success. Based on the userguide, it seems that a construct like this image (hope it can be seen) should work, but it doesn't.
The two branches have two different conditions: - the right flow has a condition like ${parseFileTask.eventWasHandled} which calls back on the task (spring bean) if the last event was handled. - the looping flow has a condition like ${parseFileTask.eventsRemaining} which is true only when there are more events expected by the process.
But this doesn't work, as only ONE of the flows gets taken (sems actually only the first defined in the xml).
We tried with an inclusive gateway at the output of the task, as that should be the "right" way to do this, but also in that case only one path is taken (we suspect that the loop messes up with the selection logic in the inclusive gateway as the exit path will also be an input path).
We tried with a third solution with a parallel gateway at the output of the Parse task which pushed the looping leg through a manual task which looped then back - conditionally - into the signal catching event, but that path was always taken (like the condition wasn't evaluated)…
Any hints on how to solve this (I may agree that the modeling is not perfect and could be worked out more).
