8 Replies Latest reply on Mar 28, 2007 2:54 PM by Shea Phillips

    setting and accessing process variables in jpdl

    Shea Phillips Newbie

      Hello,

      I am wondering how/if it is possible to set and access process variables from JPDL. I am most interested at the moment in being able to assign the return value from an action expression to a process variable for use elsewhere in my process definition.

      Here is a snippet from my process definition (not necessarily working) that invokes a Seam service/component and accepts a parameter and returns a String value or null, which I will test against in a transition element, and then use as a parameter in another action expression. Ultimately, the result of the latter service invocation will also be passed as a parameter to another service, although not shown here:

      <process-definition xmlns="http://jbpm.org/jpdl-3.1.xsd"
       name="interpretationProcess">
      
      
       <start-state name="start">
       <transition name="begin" to="determineInterpretationProcess"></transition>
       </start-state>
      
       <node name="determineInterpretationProcess">
       <action expression="#{interpretationLookup.getIntepretationName($recordID)}"/>
       <transition condition="#{empty interpretationName}" to="completed"/>
       <transition condition="#{not empty interpretationName}" to="doInterpretation"/>
       </node>
      
       <node name="doInterpretation">
       <action expression="#{interpretationService.doInterpretation($interpretationName)}"/>
       </node>
      
       <end-state name="completed" />
      
      </process-definition>
      

      There are two issue I have here:

      1. $myVar is a process instance variable created when my process instance is created - can it be referenced as shown above in an expression?

      2. How would I assign the return value of my expression to a variable with some scope that is accessible within my process? My sense so far is that I may need to use the element...

      Note that I would like to avoid having a "stateful" service (in which I invoke a method that does not return a value, but has a separate method for retrieving the result of the method). I have seen this in at least one example, but I would prefer not to do this.

      thanks,

      Shea.



        • 1. Re: setting and accessing process variables in jpdl
          dslevine Newbie

          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 Newbie

            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 Newbie

              #$#%^& 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 Newbie

                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
                  Vinicius Carvalho Apprentice

                  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
                    Ronald van Kuijk Master

                    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 Newbie

                      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 Newbie

                        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.