9 Replies Latest reply on Feb 15, 2007 9:07 AM by thedog

    initial nodes

    tom.baeyens

      for some reason or another i never did take the time to properly analyse and implement initial nodes.

      just did some tests and this is now supported:

      <process-definition name="door" initial="Closed">
      
       <state name="Locked">
       <transition name="unlock" to="Closed" />
       </state>
       <state name="Closed">
       <transition name="lock" to="Locked" />
       <transition name="open" to="Open" />
       </state>
       <state name="Open">
       <transition name="close" to="Closed" />
       <transition name="lock" to="Open Locked" />
       </state>
       <state name="Open Locked">
       <transition name="unlock" to="Open" />
       </state>
      
      </process-definition>


      this prevents users from having to do a signal right after creation of the process.

      also, when creating a new process instance, the initial node (or the start state) IS EXECUTED as the last step in the creation of the process instance. This means that you can have processes that start automatically. You can e.g. specify an initial node with an action handler.

      To remain backwards compatible, start-state still ends up in the process definition startState. so you do not HAVE to specify an initial node name.

      in theory, this should also work in the context of super states. in that case you can specify the slash separated hierarchical name of the initial node. (not tested yet)

      the complete test suite now runs with this additions.

        • 1. Re: initial nodes

          Tom,

          Can you explain how an action handler could specify the initial node? Where would the handler be hooked to?


          You wrote:

          this prevents users from having to do a signal right after creation of the process.

          Does this mean that developers need to remove the initial signal() to avoid a "double-step"? (I'm new... but won't this break a lot of code?)

          Thanks,
          -Ed Staub


          • 2. Re: initial nodes
            tom.baeyens

            Ed,

            you can now (with the code in cvs) do something like this:

            <process-definition name="door" initial="generatePdf">
            
             <node name="generatePdf">
             <action class="your.class.that.GeneratesAPdfFile">
             <transition to="next" />
             </state>
            
             <state name="next">
             ...
            


            so when you then do a new ProcessInstance(processDefinition),
            execution of the GeneratesAPdfFile will be done already in that constructor.

            • 3. Re: initial nodes

              Tom,

              Ah, I see... I misunderstood entirely. I thought you were saying that an ActionHandler could specify which node would be the initial node for an instance of the process - that the same definition could start with different initial nodes in different instances, based on an ActionHandler.

              -Ed Staub

              • 4. Re: initial nodes
                tom.baeyens

                well. with the implemented feature, you could get really close to what you're saying... if you create 1 single initial node with an action that repositions the token in the proper start node. the difference is that you actually need an extra initial node in your process. but you don't even need the transitions between that initial node and the other (conceptually) initial nodes.

                regards, tom.

                • 5. Re: initial nodes
                  kukeltje

                  great news Tom.. maybe I should 'fix' the issue of starting a process WITH passing initial variables. (it is assigned to me) That would be a nice combination.

                  • 6. Re: initial nodes
                    tom.baeyens

                    yes. i fixed that in one go.

                    • 7. Re: initial nodes
                      kukeltje

                      COOOOOOOOOOL.....

                      • 8. Re: initial nodes
                        tom.baeyens

                         

                        "kukeltje" wrote:
                        COOOOOOOOOOL.....


                        sorry it took so long :-)

                        • 9. Re: initial nodes
                          thedog

                          Seems that I stumbled across a similar problem (avoiding signal after process create) but with different solution.

                          Therefore two questions:

                          * Is this signal really required? I searched the documents but did not find anything stating that this is necessary

                          * To me it seems that a node.enter is missing at end of
                          public ProcessInstance( ProcessDefinition processDefinition ):

                          Currently:

                          // fire the process start event
                           if (rootToken.getNode()!=null) {
                           ExecutionContext executionContext = new ExecutionContext(rootToken);
                           processDefinition.fireEvent(Event.EVENTTYPE_PROCESS_START, executionContext);
                           }
                          

                          But the node is always unitialised (null) when starting a process

                          Would that be the right way?
                           rootToken.setNode(processDefinition.getStartState())
                           ExecutionContext executionContext = new ExecutionContext(rootToken);
                           processDefinition.fireEvent(Event.EVENTTYPE_PROCESS_START, executionContext);
                          


                          Could someone point out if I'm going the right direction? Are there problems with sub-processes or other jbpm features when using the code from above?