jboss-dev-forums

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: Two Transition Definitions

[<tom...@jb...>]

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 ?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953630#3953630

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953630

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: Two Transition Definitions

[<tom...@jb...>]

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

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953697#3953697

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953697

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: Two Transition Definitions

[hosierdm <do-...@jb...>]

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. =20

Here is an example where I thought conditions on transitions in general cou=
ld be useful.  My company has written a framework for a customer that inclu=
des workflow using jBPM.  Part of that framework includes some sub-processe=
s that provide the customer with some built-in functionality.  One of these=
 sub-processes logs into a network device, runs some commands, and then set=
s an exit code process variable.  To determine what their process should do=
 next, the customer was having to continually add Decision nodes to their p=
rocesses to test this exit code and transition to an error state or whateve=
r.  So I got to thinking it would be nice, for example, to be able to speci=
fy conditions on transitions coming out of a process state.  Maybe I led th=
e customer astray and there is an easier way, but I didn't see any way to f=
igure out the "status" of the sub-process and change the process path of ex=
ecution without adding a node.  Basically, what it boils down to is the des=
ire to have as few nodes and transitions in a process as is possible, in or=
der to keep the process clean and simple.

Obviously you have a bigger picture view of jBPM, so this whole concept cou=
ld be complete bunk.  Hopefully my use case helps clarify my thought proces=
s though.

View the original post : http://www.jboss.com/index.html?module=3Dbb&op=3Dv=
iewtopic&p=3D3953756#3953756

Reply to the post : http://www.jboss.com/index.html?module=3Dbb&op=3Dpostin=
g&mode=3Dreply&p=3D3953756

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: Two Transition Definitions

[<tom...@jb...>]

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...

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953939#3953939

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953939

[Jboss-dev-forums] [Design of JBoss jBPM] - Re: Two Transition Definitions

[<tom...@jb...>]

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

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953961#3953961

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953961