In the course of CAM-3455, we have made some changes in the execution tree for the following constructs in 7.3:

Changed behavior:

• event subprocesses are now scopes and are represented by an additonal execution
• sequential multi-instance creates an additional multi-instance scope that is represented by an additional execution
• multi instance: receive task and call activity are now scope but were not scope before
• concurrent && scope executions in 7.2 (e.g. created with non-interrupting boundary events and event subprocesses) are in 7.3 always represented by two executions, one concurrent with a scope child
• multi-instance: async job definitions reference the mi-activity, not the mi-body; should work for the mi-body though

• start instances with 7.2, check activity instance tree with 7.3. (reason: Refactorings in PvmExecutionImpl#getParentActivityInstanceId and PvmExecutionImpl#replace)
• Error propagation for instances that were started in 7.2 and that is triggered with 7.3 (reason : the error propagation flow scope walker might make wrong assumptions about scope activities and executions due to event subprocess being scopes now)
• a compacted tree: one execution that is asyncBefore before a non-scope task; now a non-interrupting event subprocess triggers; check whether in 7.2. the concurrent root now has an activity instance id; if not, the getActivityInstance-Command might not work correctly (background: in 7.3 it now definitely has an activity instance id and it seems it wan't that case before)
• delete a process instance with 7.3 that was started with 7.2; make sure the end listeners are invoked correctly

Known problems:

• parallel gateway uses ActivityExecution#leaveActivityViaTransitions which in turn uses PvmExecutionImpl#createConcurrentExecution to create executions for more than one outgoing sequence flow. PvmExecutionImpl#createConcurrentExecution implements legacy behavior for expanding a compacted tree. In 7.2, this legacy behavior was only seen when executing non-interrupting events, but it was not seen with parallel gateway because PvmExecutionImpl#takeAll created concurrent executions correctly

AT:

• write integration tests that start processes with one engine version (7.2.) and complete them with the current (7.3) with legacy behavior turned on and off