-
1. Re: setting and accessing process variables in jpdl
dslevine Mar 27, 2007 2:04 PM (in response to shea.phillips)I think you can do all that. I dont see "$myVar" in your code sample, and your second sentence didn't quite finish. Look at decision nodes, and look at the script elements and variable tags in jpdl. Take a look in the docs and post here if you need clarification.
-
2. Re: setting and accessing process variables in jpdl
shea.phillips Mar 27, 2007 2:38 PM (in response to shea.phillips)My last reply did get truncated - probably my fault. What got clipped was saying that I thought the script element would possibly do what I need.
'$myVar; should have been '$recordId', which I have since learned should be accessible as a naked string in an expression (i.e. recordId).
I have done some further experimentation and reading regarding the script element, but I am having problems with using it - in some cases, xml validation errors when using it in certain places that should be allowed according to the DTD,. in other cases some weird persistence error indicating that the Script was not of type Action (which it is).
Is it possible that is not fully supported in jBPM 3.1.4?
Thanks,
Shea. -
3. Re: setting and accessing process variables in jpdl
shea.phillips Mar 27, 2007 2:40 PM (in response to shea.phillips)#$#%^& truncated again....can't use angle brackets apparently...
last bit was: 'is it possible that 'script' is not fully supported in jBPM 3.1.4?
thanks, Shea. -
4. Re: setting and accessing process variables in jpdl
dslevine Mar 27, 2007 3:29 PM (in response to shea.phillips)i am using 3.1.2 and script works for my use cases.
Can you post the specific code that is having problems? Here is a sample of script code I use, where contractSummary is a variable placed into the workflow context in Java code:<decision name="Needs Second Approval?" expression='#{ ( contractSummary.totalAmount > 1000 ) ? "Yes" : "No" }'> <transition to="Contract Approval" name="Yes"></transition> <transition to="Needs Staff Assignment?" name="No"> <script> <expression> approvedAmount = contractSummary.totalAmount; </expression> <variable name='approvedAmount' access='write' /> </script> </transition> </decision>
-
5. Re: setting and accessing process variables in jpdl
viniciuscarvalho Mar 27, 2007 3:41 PM (in response to shea.phillips)Kinda OT, but maybe someone could help me: Can I access a process deployed outside a seam application using @CreateProcess, @EndTask etc.?
Seems that seam only allows process that resides inside the application and are defined on the components.xml
Regards -
6. Re: setting and accessing process variables in jpdl
kukeltje Mar 27, 2007 4:49 PM (in response to shea.phillips)why not create a new topic for this if you already know it is oftopic??? anyway...
Sorry, I have no idea never tried multiple apps accessing the same process in a seam way. For jBPM itself it is no problem.
Maybe you should ask in the seam forum.... oh wait..... :-) -
7. Re: setting and accessing process variables in jpdl
shea.phillips Mar 27, 2007 5:31 PM (in response to shea.phillips)ok - so I now have 'script' contents being executed. Had to uncomment the Script.hbm.xml reference from jbpm's hibernate config file and include bsh.jar in my classpath. There is doco on this, but it didn't jump out at me initially. IMO, having Script support disabled by default is a bit weird.
In the following jpdl, I get to the point of executing the contents of my script element. However bsh pukes saying it can't resolve the variable 'ecgProcessNameLookup', which is a seam component, and is already successfully used in the decision's expression attribute. The variable element referencing this does nothing to help the situation.
My next step is to learn more about the context that script has available, and how to work with it.
dslevine - Thanks very much for your help so far.?xml version="1.0"?> <process-definition name="DispatchInboundECG" xmlns="urn:jbpm.org:jpdl-3.1"> <start-state name="start"> <transition name="begin" to="determineInterpretationProcess"/> </start-state> <decision name="determineInterpretationProcess" expression='#{ ( ecgProcessNameLookup.determineInterpretationProcessName == null ) ? "Yes" : "No" }'> <transition to="completed" name="Yes"></transition> <transition to="doInterpretation" name="No"> <script> <expression> String interpretationName = ecgProcessNameLookup.determineInterpretationProcessName(); </expression> <variable name='interpretationName' mapped-name="intepretationName" access='write'/> <variable name='ecgProcessNameLookup' mapped-name="ecgProcessNameLookup" access='write'/> </script> </transition> </decision> <node name="doInterpretation"> <action expression="#{eCGInterpretationGenerator.execute(interpretationName)}"/> <transition to="completed"/> </node> <end-state name="completed"/> <end-state name="doInterpret"/> </process-definition>
-
8. Re: setting and accessing process variables in jpdl
shea.phillips Mar 28, 2007 2:54 PM (in response to shea.phillips)I now have my process working pretty well. I am invoking my seam components in bsh inside a script element with variable elements. This seems to work reasonbly well, although ultimately I would like to have less bsh. I will be doing more investigation on how to enable this.
One problem I did encounter was accessing process instance variables in decision expressions like:<decision name="someDecision" expression="#{ (someVar == null) ? 'Skip' : 'doIt' }"> <transition name="Skip" to="doNothing"/> <transition name="doIt" to="doStuff"/> </decision>
where someVar is a process instance variable with a non-null value. In the above case, the 'Skip' transition would always be taken although the 'doIt' transition should have been.
If, however, I put an equivalent expression inside a 'condition' element on a specific transition, things worked (the variable was accessible). For example:<decision name="someDecision"> <transition to="doStuff" name="doIt"> <condition expression='#{ not empty someVar }'/> </transition> <transition to="doNothing" name="skip"/> </decision>
I'm not positive my problem with decision expressions was not an oversight of some subtle detail on my part (maybe in the EL notation or something), but this may be useful information for someone else.