On message correlation, I can set local variables in the triggered execution

[ThorbenLindhauer]

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-10680
Reporter	@ThorbenLindhauer
Has restricted visibility comments	false

---

There is an additional correlation parameter that takes variables with the following semantics:

Intermediate message event/receive task: Set the variables on the execution that is in the intermediate event (like setVariablesLocal) Event sub process: Set the variables on the execution that represents the scope instance of the event sub process (unlike setVariablesLocal)

User Problem

User Story (Required on creation):

As a developer, I want to be able to define in the BPMN, how a certain error should be handled based on a variable.

Functional Requirements (Required before implementation):

• Create new additional correlation parameter variablesToTriggeredScope that are assigned to the new scope triggered by correlation
• Pass the variables via the existing execution to the new scope
• Race condition doesn't affect the outcome of the correlations

Technical Requirements (Required before implementation):

Limitations of Scope (Optional):

Breakdown

• [x] Add new setVariablesToTriggeredScope to MessageCorrelationBuilder and implementation
• [x] Add new field to store the payload in PvmExecutionImpl
• [x] In EventHandlerImpl.handleIntermediateEvent() fetch the payload input and add it to the process instance execution (as a dedicated tuple: activityId, variables)
• [x] After PvmAtomicOperationActivityStart#getScope() is executed check if activity is a message and variables not empty in PI, set the payload to the (right) execution
  • [x] "check if activity is a message" - populate this information in the activity behaviour (BoundaryEventActivityBehavior, EventSubProcessStartEventActivityBehavior, and IntermediateCatchEventActivityBehavior) Fetch the type from the "type" property of the activity
• [x] JUnit tests: correlation of boundary, event subprosses start, and intermediate event. Consider adding async continuation test.
• [x] REST API: add processVariablesToTriggeredScope in CorrelationMessageDto
  • [x] Add tests and adjust OpenAPI
• [x] Backport

Hints

Execution Tree Examples

example-1.pdf example-2.pdf example-3.pdf example-4.pdf

Links:

• is depended on by https://jira.camunda.com/browse/SUPPORT-5916
• is related to https://jira.camunda.com/browse/SUPPORT-11047
• https://jira.camunda.com/browse/SUPPORT-17688

### Pull requests
- [ ] https://github.com/camunda/camunda-bpm-platform/pull/3973
- [ ] https://github.com/camunda/camunda-bpm-platform-maintenance/pull/1117

[yanavasileva]

• [x] What will be the expected behaviour when correlating a intermediate catch event with the new variables parameter (setVariablesToTriggeredScope)? Tricky part here is that there's no new scope.
• [x] Also revisit implementation for message start event (link). During that message correlation, EventHandlerImpl.handleIntermediateEvent() is not executed.

Message start event

1. Don't do anything (don't add the variablesToTriggeredScope at all)
   • Pros
   • Cons
   • not user friendly, user will expect to see their variables processed/handled
   • there's a new scope for the start event when the process instance is created
2. Set variables to the new process instance similarly to setVariablesLocal
   • Pros
   • consistency with the other variables
   • semantically correct behaviour

Message intermediate catching event

1. Don't do anything (don't add the variablesToTriggeredScope at all)
   • Pros
   • theoretically there's no new scope for intermediate catch event so we can say the parameter in not applicable in this case
   • Cons
   • not user friendly, user will expect to see their variables processed/handled
2. Treat the variables as local
   • Pros
   • semantically correct action (for intermediate catch event we just fall back to existing scope when there isn't a new one)
   • setVariablesLocal is semantically the same in this use case

Decision: For both use cases second option with arguments considering user expectations and existing implementation. Also, reached out to the customer to get their feedback. So far we are not aware if they are using those two events and if they have intentions to use the new parameter with them.

[yanavasileva]

To consider: add a test case with async continuation.

[yanavasileva]

Notes:

• when asyncAfter is used, the behaviour is the same
• however, when asyncBefore is used, the behaviour is different as the new execution is created before the correlation. We still can assign the variables to that scope just we need to do it earlier.

Therefore, I adjusted setting the variables at earlier point in PVM instead of PvmAtomicOperationActivityStart:

• (async) non-interrupting boundary event -> PvmAtomicOperationActivityStartConcurrent
• (async) interrupting boundary event -> PvmAtomicOperationActivityStartCancelScope
• EventSubprocess (async) (non)-interrupting start event -> ExecutionEntity(PvmExecutionImpl).setDelayedPayloadToNewScope (after SubProcessActivityBehavior triggers execution.executeActivity("message"). I created https://github.com/camunda/camunda-bpm-platform/issues/3979 to move out the logic from the execution to the operations.
• behaviour for message start event and intermediate message event doesn't change

[yanavasileva]

@danielkelemen, I covered async continuation scenario and implemented the review hints. Ready for review on master and 7.20

[yanavasileva]

Handover to QA:

• Docs REST API for message correlation: https://docs.camunda.org/rest/camunda-bpm-platform/7.20/#tag/Message/operation/deliverMessage

• new variable processVariablesToTriggeredScope to be used

• Use cases:

  • Interrupting and non-interrupting boundary event with asyncBefore=true (customer scenario)
  • Interrupting and non-interrupting message start event in an event subprocess
  • message intermediate catching event (variable visible only in History view)
  • all above with asyncBefore or asyncAfter
  • Start message event

• Example processes:

  • Variable to be set testLocalVar=outputValue
  • bpmn.zip

[gbetances089]

Tested on 7.20.2 patch