Let me preface my remarks by conceding that I am not a BPMN guru and am even less familiar with BPMN Simulation. That being said, I would suggest that I have some knowledge about the general theory and practice of systems modelling. Also, there is some consideration of First Principles.
So, I have recently been posting about BPMN Scenario Simulation of non-trivial BPMN processes.
We have built a non-trivial process with 11 activities, ten gateways, and five pools – one with two lanes plus other assorted related items (not required for simulation). The gateway exit flows are populated with the appropriate guard condition expressions to correctly route the execution.
We have set up several scenarios to test our process and ensure that, given the input values for the relevant guards, the process will execute correctly and execute the required activities, terminating at the correct end event.
The scenario simulation is working well. We have some high-level processes that set up the required variables to drive the simulation. Then we invoke the Process under Simulation (PuS) via a Call Activity (by dragging the PuS onto the higher-level scenario process.
So far, all is good!
It is our practice to create “Neighborhood” diagrams (NDs) for our repository items (attached as the composite diagram of the item). The Neighborhood diagram locates all the related items to the Item under Observation (IuO) and all the diagrams in which the IuO appears. For most items, this means our users are never more than two double-clicks away from anywhere in the repository the item appears. This is a very powerful concept – especially for new hires who need to understand “what’s going on”.
Since the composite diagram mechanism is NOT used by BPMN 2.0 simulation, we figured that shouldn’t be a problem.
So, we started by creating NDs for our high-level scenario process. NDs were successfully created and worked as usual. We ran the Validation Process on the package, and it passed with no errors or warnings!
We then ran the simulation. Everything proceeded as normal until the PuS had to return to the calling process. At that point, we were presented with an Element Usage dialog (no indication of the element it was related to); it had two diagrams specified, the ND for the Call Activity and the Business Process Diagram wherein the Call Activity was located. This fact is how we surmised the Element Usage dialog was called by the return to the calling activity.
Now, it seems to us that a BPMN process can have only one Composite Structure diagram (since the diagram is the process's definition). When exiting a lower-level process, the return process and activity therein to be returned-to should be held in the metadata. It should have NOTHING to do with the number of diagrams the item appears in. However, this seems to be the case with the defective implementation of the simulation process. Any arbitrary item in the repository could appear in any number of diagrams for any number of reasons. From a simulation perspective, only BPMN diagrams are relevant.
But wait, there’s more!
Since NO simulation error was caused by creating the NDs for the other BPMN items in the high-level diagram, we created NDs for the PuS.
Imagine our surprise when, unlike the activities in the higher-level process, where the NDs had (apparently) NO impact on the simulation, we were presented with an Element Usage Diagram for every element in the lower-level process that had an ND! This is just bizarre self-inconsistency! Surely the ONLY items that are relevant to the simulation are the business processes and their components (both vertices and arcs) – since both can only appear in one BPMN diagram at a time.
While this is strictly true, if we wish to visualise the simulation, we need to be able to update the appropriate diagram with the relevant item to highlight! Surely this should be part of the metadata carried by the “conceptual token” that is being moved around the simulation. There is no need to examine the collection of diagrams the item can appear in. Consequently, you should look for the business process diagram in the collection and use that. If there is more than one such diagram, then that is an error that should be caught by the validation process!
To rectify this defect, I recommend NOT using the diagram collection to manage the visualisation of the simulation. But as a temporary solution, use the only Business Process diagram in the collection.
Thoughts?
Reported,
Paolo
