Two Transition Definitions

[hosierdm]

I'm interested in the thought process behind creating two different definitions for the transition element. I can see situations where it would be valuable to allow the condition element for transitions globally and not just inside a decision node. It could save work and help clean up a process if you wanted to branch based on a variable value and could do that straight from a node where that value is set. Any thoughts? I don't know how much work it would be to change that functionality. I assume evaluating the conditions is a function of the decision node and not generic to the transition implementation.

[tom.baeyens]

please, give some more input it is very valuable to us.

first the background on the current situation (lack of general applicable conditions on transitions): my main problem with adding conditions or guards on all transitions is that jbpm is not able to do anything functional with them except throw an exception when a user wants to take a transition that is not available.

this can only be meaning full in the first transition that is taken. if a user provides a signal and process execution resumes. suppose that after executing a few nodes, an automatic node decides to take a transition for which the condition is not met. then the user will get an exception that is caused by a problem in the process definition. the user would get an exception in the line of "hey, somewhere in the process definition there was a contradiction: node x decided to take transition t, which was not accessible"

the user is only responsible for the initial signal and the transition that he/she specifies. in that case the engine could throw an exception with a message like "hey, you can't take this transition".

in the latter case, guards could make sense. BUT, the verification could just as well be done in the user code as in the process. Instead of sending a signal to the process and have the process decide wether you can take that transition, you might as well check that condition yourself. When checking for conditions in the user code, you don't rely on exceptions for your normal program operation.

So in my opinion, there is this one little thing in which guard conditions make sense. To ask the process execution: "to filter the outgoing transitions of the current node and answer the question: 'which transitions are currently available for this execution'"

Are you referring to exactly this last use case ?
Do you see another use case for guard conditions that i should be aware of ?

[tom.baeyens]

i've added this to the faqs: Why does jPDL lack a notion of a guard condition on every transition ?

[hosierdm]

I think I understand your concerns, and they make sense. Unfortunately, I'm not really hip to the concept of guards on transitions as you describe it, so that discussion is a bit over my head.

Here is an example where I thought conditions on transitions in general could be useful. My company has written a framework for a customer that includes workflow using jBPM. Part of that framework includes some sub-processes that provide the customer with some built-in functionality. One of these sub-processes logs into a network device, runs some commands, and then sets an exit code process variable. To determine what their process should do next, the customer was having to continually add Decision nodes to their processes to test this exit code and transition to an error state or whatever. So I got to thinking it would be nice, for example, to be able to specify conditions on transitions coming out of a process state. Maybe I led the customer astray and there is an easier way, but I didn't see any way to figure out the "status" of the sub-process and change the process path of execution without adding a node. Basically, what it boils down to is the desire to have as few nodes and transitions in a process as is possible, in order to keep the process clean and simple.

Obviously you have a bigger picture view of jBPM, so this whole concept could be complete bunk. Hopefully my use case helps clarify my thought process though.

[tom.baeyens]

aha. you are absolutely right and i misinterpreted your request initially.

what your saying make absolute sense. thanks for being persistent !

here's some ways of we could add support for what you want.

* add conditions on the transitions. there is one catch to it: how to resolve the variables that are used in the condition. We could only resolve to the variables in the subprocess, only resolve the vars in the super process. Or maybe we could resolve first in the sub process and then in the superprocess. Would that make sense ?

* add an expression to the process-state that resolves to the name of the leaving transition to take.

Maybe we could strive to support both (exclusive) options...

[tom.baeyens]

feel free to make a jira issue feature request and describe your desired behaviour.