nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Process Debugger

ruediger_hain

Hi,
we are prototyping a process debugger for Activiti.
One feature we need in the debugger is setting breakpoints so that the process execution will stop before/after reaching a certain activity.

Our idea was to merge an artificial breakpoint activity into the original process definition which would behave as a wait state.
This might work (we havent tried yet) but seems like an ugly hack, there should be some support for this in the engine.

Are there any hooks planned to support breakpoints in the future?
Or can you give any hints how to accomplish this?

Find more posts tagged with

Comments

tombaeyens

In the next release, we should be able to finish a so called process event bus. It's similar to what was called a HistorySession in jBPM 4. When a process instance executes, events are fired. Listeners are notified synchronously. Such a listener would be ideal for implementing breakpoints, I think.

It would be really cool to have that capability then in the engine build in.

I believe in the XML parsing, we already switched from DOM to use a SAX parser in order to capture the line numbers of the Activities. I don't know by heart, but it should be possible to get that data as well.

ruediger_hain

Do you mean the execution would block in the Listener call which implements the breakpoint?
Or would there be a way in the listener to safely suspend the execution and resume it later?
In my opinion it would be better to ensure the execution is in a stable state when the breakpoint is reached - that's where the idea to add "breakpoint activities" that simply behave as wait states came from.

tombaeyens

a listener implementation can block the process execution. i think that is preferable. as then you get the exact same behaviour in debug as in real execution.

you say you want to ensure a stable state for the execution. i don't see yet what you would call an unstable state. can you clarify that what you meant with that?

ruediger_hain

With stable I mean the process execution is in a wait state, i.e. it is waiting for an external trigger. So the method that initiated the process (for example ProcessService#startProcessInstance) returns even when the execution has reached a breakpoint.

In a process that splits up into multiple concurrent paths on a parallel gateway I would like to have all concurrent paths being executed "to the end". In other words, for a concurrent path that contains a breakpoint the token is at that breakpoint whereas all other tokens are at the end of their respective paths, for example at a merging gateway.

If I understand the engine correctly, this behaviour would not be achievable by just blocking the process execution in a listener because the concurrent execution paths would be blocked as well, leaving the process in a somewhat non-deterministic state.

tombaeyens

process concurrency doesn't make a difference. you want the debugger to block on breakpoints and for the rest it should behave just the same like it does in real execution mode. so having a blocking call on an process event listener being dispatched is still a good solution imo.

i don't see the counter argument yet.

bernd_ruecker

Hey guys.

I think you are basically talking about different things.

The Breakpoint as Tom sees it behaves like a Java Breakpoint: The Thread stops and waits for action. The transaction is kept open and is waiting. If you wait too long, it times out and is aborted. This make sense for debugging and is what you expect from a breakpoint.

What Rüdiger has in mind is more like an additional persistent stop, to have "transactional breakpoint". I think I can understand why you want to have something like that, but it is true, that this will change the runtime behavior of the process instance (if now the instances crashes afterwards, it will rollback to the breakpoint, not the last wait state!).

I need to have a look at the current implementation of the Event Bus, but maybe it would be cool if a listener can set a transaction boundary (@Tom: maybe that could be used for asynchronous continuation as well?), then both could be implemented. But it would be good to see the exact use case for the Debugger (development time, runtime inspection, marketing demos, …?).

Cheers
Bernd

tombaeyens

@ Bernd, if your interpretation of Ruediger is correct, then he's talking about an asynchronous continuation, right?

bernd_ruecker

Basically yes, but on an instance level during runtime, and not triggered automatically, but from the "Debugger-App"

ruediger_hain

I'm not sure what an async. continuation means, but Bernd's interpretation is right, I basically want a transactional breakpoint not a Java breakpoint. The intended use case of a breakpoint is to debug process semantics not the internal functions of the process engine.
When the breakpoint is reached, I want to be able to introspect all process variables, pending user tasks etc.
Is this really possible when the transaction is not yet committed and the executing thread is blocked in an event listener?

Cheers,
Rüdiger

tombaeyens

In that case i don't yet see the relation between debugging and that kind of breakpoints.

bernd_ruecker

That depends how fast you are with your Debugger 😉

falko_menge

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.

tombaeyens

BPMN execution assumes persistent usage of the Activiti engine. In this mode, you move from one state to another in a transaction. This means transactional control flow. You have typically only 1 TCP JDBC connection to your DB. So parallel gateway is not something that needs to be 'fixed' imo. In the persistent use case, it is like it should be.

If your goal is to debug software that will run in this same persistent environment, then process debugging should not differ from the persistent execution mode. Hence it is good to have the exact same execution semantics in debug as well as in runtime mode.

Maybe you're talking about a different use case. Where you want to provide analysts with a BPMN simulator. In that case I understand your request. To support that use case we have to discuss implementation strategies here on this list. My first thoughts are towards the atomic operations. The while loop of atomic operations could be interrupted when a breakpoint is reached. Probably there are other alternatives. This research would take quite some time i think.

Also other, more urgent features are waiting on finishing the atomic operations like asynchronous continuations. Meaning, the idea for async continuations is that they get send over a message and later the execution is loaded and the atomic operation is then performed asynchronously. But some state in the execution is not persisted. It should be passed in the message (in the job). This is not implemented yet. And dealing with those very same memberfields is what you'ld need to do for an atomic based solution as well.

Let's analyse the use case further: what *exactly* is it that you want? If my assumption correct that this is for a BPMN simulation environment for analysts, rather then for debugging persistent BPMN executable processes? In what other ways is this environment different? What alternatives do we see for implementation strategies?

ruediger_hain

The use case is what you call a BPMN simulation environment.
It's meant to be used by process developers (business analysts etc.) who dont really care about internal workings of the engine itself but on process semantics.
We came up with a similar solution you are suggesting (prevent AtomicOperationActivityExecute or activityBehaviour.execute() from being called and invoke it later after the breakpoint). The engine would need to provide a hook to prevent the operation execution. This could be added as a full blown debug api or in a more general purpose and non-invasive way. For example you could provide the AtomicOperations through a factory rather than constants in the AtomicOperation interface. In debug mode this factory could provide a special AtomicOperationActivityExecute which does the breakpoint checks.

tombaeyens

For BPMN process simulation, i think it is best to write a completely different set of activities.
Check out the test suite of the current trunk activiti-pvm module. It contains a great starting point for implementing those.
Then you don't have any persistence involved.

Then you could have say a SimulationProcessDefinition extends ProcessDefinitionImpl that creates SimulationExecution extends ExecutionImpl.
Then you can overwrite the performAtomicOperation method or any other method.

tombaeyens

If you want to do this properly, you have to create extend the activiti-pvm test suite with tests that validate your simulation use case. maybe even create a separate simulation module.

Only if your use case ends up in our test suite that all developers run before they commit, then it can survive the test of time. If it is not part of the test suite, you will always struggle to upgrade.

yaronwittenstei

Hi,
1. is there any release expectation for this feature?
2. The feature will have the option to re-play an historical process-executions ?
I mean, Would it be possible to import a process-instance-execution from the history-database and
play it visually while having options to break at certain points and inspect variables…?

Best Regards,
Yaron