1. Exception flow* is also crucial for me. Is it possible to extend
Flow to support it?
Flow currently allows you to use fault nodes to signal an
error.
Exception handlers can be attached to the process or to composite nodes
(to allow for some nested exception handler scopes). These exception
handlers can then for example signal an event, so the process can
continue executing some error path. So this is very similar to what you
describe, we just don't allow you to put a boundary error event on the
side of a node just yet (any Eclipse IDE wizards that want to help out? ;)).
2. How to extend Activities.
As you already discovered, use a
pluggable work item. We would
recommend not adding too much execution details in your process (like
Java classes to call etc.) and we believe this work item approach
provides you the same kind of flexibility but in a lot more declarative
manner.
3. Is Flow based on its own PVM or jBPM PVM? Is it also possible to
extend flow with new flow constructs?
It is based on a generic process engine. We
offer a set of core
constructs but this is extensible (for example, to support OSWorkflow
migration, a custom node was added to our language to simplify this
translation).
4. From Human task is possible only one outgoing transitions. We
quite often use multiple outgoing transitions and user choose which
one to take.
Can it be done directly?
At this point, a human task node indeed only can have one outgoing
transition (as many other nodes). We deliberately chose this because
this forces the user to think about how to model multiple paths (as many
options are possible: XOR, AND, OR) and makes the resulting graph easier
to understand. So you should just store the result of the human task as
a process variable and use an XOR split right after that.
Kris
Disclaimer:
http://www.kuleuven.be/cwis/email_disclaimer.htm