I expected the “triggered task”-PlanItem to start when the “triggering task”-PlanItem completes, but that doesn’t seem to happen. The “triggered task”-PlanItem stays available and doesn’t transit over to active, even so all entry criterias are fullfilled. At least with my test environment setup using the CmmnAwareTests class from camunda-bpm-assert 2.0-alpha2. Can someone tell me why the PlanItem doesn’t transit to active state?
I used the following test case to investigate the issue:
A planItemOnPart must always reference a plan item by the attribute sourceRef. This plan item must be contained by the same stage the sentry is defined in.
That helped, thanks! I can’t find a corresponding restriction in the specs. The Sentry is restricted to be in the same stage as the referencing PlanItem, but the sourceRef of a PlanItemOnPart doesn’t seem to have such a restriction. But it seems logically to not support this kind of construct, as it would lead to stages getting available without having an entry criterion matched, or PlanItems not triggered on a satisfied EntryCriterion, because of the Stage not being active.
Ok, I was wrong about that. The specs actually allow this explicitly. Referring to section 8.4.2 - “Stage and Task Lifecycle”, table 8.7 - “Stage and Task instances state” the row for the “Available” state says:
A Stage or Task instance becomes available when
[…]
The Stage or Task has a Sentry with an OnPart that has a sourceRef outside of the enclosing Stage of that Stage or Task and this Sentry is satisfied. In that case, the Stage instance and recursively all Stage instances p to the enclosing Stage of the Stage or Task in which the Stage or Task resides moves into Active state if not already active.
I would expect the transition checks for the Stages getting active, are to be checked in this case, but couldn’t find anything about that in the specs yet. And there is no description of what happens if a parent Stage can’t get active because of its current Lifecycle state. The specs are quite vague here, and as there aren’t any good usecases for this construct, that I can think of, it is probably a good step to not support them for until there is a good reason to.