> 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 _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users