PlanItem in a stage, that has an PlanItemOnPart with PlanItem form parent stage as its entry criterion acts unexpected when trying to simulate with CmmnAwareTests


#1

So I build this little cmmn file: unexpected.

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:

@Test
@Deployment(resources={ "unexpected.cmmn" })
public void testUnexpectedCmmnBehaviour() throws Exception {
    CaseInstance instance = caseService().createCaseInstanceByKey("UnexpectedCase");
    assertThat(instance)
        .isActive();
    assertThat(instance)
        .humanTask("TriggeringPlanItem")
        .isActive();
    assertThat(instance)
        .stage("SomeStagePlanItem")
        .isActive();
    assertThat(instance)
        .stage("SomeStagePlanItem")
        .humanTask("TriggeredPlanItem")
        .isAvailable();
    complete(caseExecution("TriggeringPlanItem", instance));
    assertThat(caseExecutionQuery().count()).isEqualTo(3L);
    assertThat(instance)
        .isActive();
    assertThat(instance)
        .stage("SomeStagePlanItem")
        .isActive();
    assertThat(instance)
        .stage("SomeStagePlanItem")
        .humanTask("TriggeredPlanItem")
        .isActive();
}

The corresponding cmmn

My github repository contains a gradle based working example.


#2

Can someone at least test if the test reproduces my problem on their side? Probably its a setup problem and I want to rule that out.


#3

Hi @hapm,

I think defining sentries that cross stage boundaries is currently not supported. The docs at https://docs.camunda.org/manual/7.9/reference/cmmn11/sentry/#onpart says:

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.

Not sure if this scenario is allowed by the spec.

Cheers,
Thorben


#4

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.


#5

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.