7 Replies Latest reply on Oct 1, 2009 8:11 AM by Ronald van Kuijk

    Translation of task node from jBPM3 to 4

    Ralf Edmund Stranzenbach Newbie

      Hi,

      what is the correct/best way to translate a task-node like below from jBPM 3 to 4?

      <task-node name="A" signal="first" end-tasks="true">
       <task name="T1" />
       <task name="T2" />
       <task name="T3" />
       <transition to="next state" />
      </task-node>
      


        • 1. Re: Translation of task node from jBPM3 to 4
          Ronald van Kuijk Master

          I'm not sure. I've passed the question on. Let you know when I get an answer.

          • 2. Re: Translation of task node from jBPM3 to 4
            newcomer1 Newbie

            Bumping this.

            Is there any equivalent for task-node in jbpm 4?

            • 3. Re: Translation of task node from jBPM3 to 4
              Ronald van Kuijk Master

              no there is not. And not sure if it will return as it was or whether alternative ways (more bpmn like) will be implemented.

              What is the behaviour you need?

              • 4. Re: Translation of task node from jBPM3 to 4
                newcomer1 Newbie

                 

                "kukeltje" wrote:
                no there is not. And not sure if it will return as it was or whether alternative ways (more bpmn like) will be implemented.

                What is the behaviour you need?


                Im quite new to BPM and jBPM but I want to re implement an existing jBPM 3.x process in jBPM 4, but the existing process definition uses more or less only task-nodes. All the 3.x projects I've seen seems to use task-node definitions extensively and there is no examples/documentation in jbpm 4 that covers how to achieve the same type of behavior. Seems like what im after is grouping and/or fork/join.

                The behavior that I want is more or less like this:

                When entering a certain state (task-node) I want to create 5 tasks that have to be done to transition to the next state. The order these tasks are performed in do not matter and should not be enforced.

                 <task-node name="received" blocking="true" create-tasks="true">
                 <task name="reminder" blocking="true" duedate="1 business days">
                 <assignment class="xx.AssignmentHandler"/>
                 </task>
                 <task name="evaluate" blocking="true" duedate="2 business days">
                 xxx
                 </task>
                 <task name="createPlan" blocking="true" duedate="1 business days">
                 xxxx
                 </task>
                
                 <more tasks, timers etc./>
                
                 <transition name="toAccepted" to="accepted"/>
                 <transition name="toRejected" to="rejected"/>
                 </task-node>






                • 6. Re: Translation of task node from jBPM3 to 4
                  newcomer1 Newbie

                   

                  "kukeltje" wrote:
                  Yes, use a plain fork-join for this.


                  I still have to admit that I think the task-node approach is much easier to work with.

                  The jbpm documentation should have more information about differences from the jbpm 3.x way to model stuff. E.g. to associate tasks with a state.

                  How would you model a simple scenario as this:

                  start -> Registered (state) with 2 tasks that are created when the state is entered, one that MUST be performed, and one that is optional -> Handle, state with several tasks.

                  • 7. Re: Translation of task node from jBPM3 to 4
                    Ronald van Kuijk Master

                    tasks are never associated with a state. Tasks are now just 'simple' tasks, not 'complex' tasks anymore (the task has been 'promoted' to the level of the former task-node. That might be explicitly missing in the docs, I won't deny that. But

                    What you describe is not a 'simple' scenario, it is already a more complex one. You probably combined the 'blocking' attribute on the task within the task-node, the signal attribute on the task-node and maybe also the signalling. I agree that jBPM made this seem simple :-)

                    From what we've experienced these were not used alot. In jBPM 4, for now, you need to do something like using an eventhandler to cancel the 'parallel task'. In the future this will be made more explicit by using things like the bpmn cancel signal.