Rüdiger, Vladimir and me discussed this topic in more detail during a workshop last week and came to the conclusion that an event listener is not sufficient for debugging at the BPMN level.
Our conclusion arises from the fact that the current BPMN Parallel Gateway implementation does not execute the paths in parallel, but rather one after another in a somewhat random order. Hence, stopping the engine in a parallel section through an event listener would leave the process in a state were other paths may not even have started to execute. If there are interdependencies, e.g., via BPMN Events or Data Flow, among the parallel paths, there might be constellations, which cannot be reached through event-based debugging or even cause a deadlock.
That leaves two options:
1. The Parallel Gateway could be fixed to be really parallel, e.g., using multiple threads. This way an event-listener would only block one path in a parallel section, but not the entire process instance. This fix might even be needed to support certain BPMN use-cases.
2. A debugging interface could be introduced in the PVM together with an according service in the engine module. The idea would be to switch the engine into a debug mode either programmatically at runtime or through configuration at startup, which would then enable additional checks for active breakpoints. The advantage of such a solution would be, that it is highly transparent and allows for debugging on a logical process level independent from implementation details. Rüdiger and his colleagues have might be able to contribute such a feature and we already discussed a possible implementation strategy.
