5 Replies Latest reply on Sep 29, 2005 9:40 AM by James Depoorter

    Preserving the sequence of tasks in processdefinition

    janapoornavel Newbie

      would it not be necessary to preserve the sequence of specification of tasks in processdefinition,so that at runtime the user of the system gets to finish the tasks as per the sequence.execuse me if iam missing some thing,but i see no options of doing such thing in jbpm3.0.i have also given an example below to make things a bit more clear(iam removing all the angle brackets for the obvious reasons)

      task-node name="create-PurchaseOrder"
      1)task swimlane="OrderingParty" name="create-new-po"
      2)task swimlane="OrderingParty" name="intimate-info"
      transition name="trn-task-evaluate-purchaseorder" to="evaluate-purchaseorder"

      when the user gets to act on the tasks he should be able to move thru the sequence,first doing task1 and next task2 which i fear is absent in jbpm3.0's offering.


        • 1. Re: Preserving the sequence of tasks in processdefinition
          Ronald van Kuijk Master

          Why not use two task nodes instead of two tasks witin a tasknode? Then you have the sequence you need.

          • 2. Re: Preserving the sequence of tasks in processdefinition
            janapoornavel Newbie

            hi ron,
            thanks for the quick reply.but if that becomes the only choice we have,
            it would be better if could avoid providing the support of letting user define
            multiple tasks in a single task-node.because,most of the
            people would try to use things to the max and i think people
            would end defining tasks in fashion which they might expect
            to get done sequentially and end up losing the order in the
            runtime.plus dont you think if the workflow is going to become
            larger,would it not lead to task-node explosion ?

            please do correct me if iam wrong.


            • 3. Re: Preserving the sequence of tasks in processdefinition
              Ronald van Kuijk Master

              multiple different tasks is indeed not what I would use a tasknode for, although it is possible. Maybe if the editor would show the multiple tasks then I'd use it, but for now I use a fork/join construction.

              With regard to 'people using things to the max' this is one of the lesser weird constructions I been in contact with someone over. Simple adding something to the docs in this case that tasks in a node are parrallel would be enough would it? Or should we even take people into account who do not read the fine manuals :-)

              And why is a tasknode explosion bad? Tasks in a tasknode do not take up to much room and a clear but explicit processflow is what we need right?

              • 4. Re: Preserving the sequence of tasks in processdefinition
                janapoornavel Newbie

                hi ,
                documenting the nature of tasks being parallel is okay with me.Actually
                it gave me another perspective of modeling the process too.thanks for the help.


                • 5. Re: Preserving the sequence of tasks in processdefinition
                  James Depoorter Novice

                  As to the "clear process definition" part: Actually, we have the following fuzzy process:
                  The process follows a fixed sequence (using the process definition), and in one of the steps one resource determines which other steps and the number of steps should be followed, and these are executed by different resources.
                  After executing all those steps, the process continues again in a fixed sequence.
                  The process is an example of a problem solving process (e.g. complaints, support):
                  First there are some predefined steps which will lead to the cause and nature of the problem (e.g. data gathering step, investigation step etc.)
                  Then the support-guy determines the solution:
                  - he would like to start a non-deterministic number of subprocesses or tasks to solve the problem
                  - the subprocesses are all little ways of handling part of the solution, which follow specific steps, executed by different resources. These are not simple tasks.
                  - Maybe he would even like to determine some order and parallellism
                  After that the process is again deterministic (e.g. notifying, closing)
                  Throughout the topics in this forum, different approaches are given for creating a non-deterministic flow
                  - saying a non-deterministic flow is not the right way to model a process :-)
                  - simply creating tasks that should be executed by the different resources (problem is their parallel nature, but this could be solved by having different tasknodes with correct transitions). However, tasks are just endpoints, without having any further flow in itself.
                  - giving priorities to the tasks, so you could mimic some sequence/parallellism.
                  - creating a custom fork with a loop construct around it: the loop for the sequencing bit, the fork for the parallel bit <= maybe this is the best solution: you define at least one fork-leg for every possible subprocess, and create multiple tokens (or none, if the subprocess is not needed). When looping, you do it again (or stop the loop).

                  I too feel that the transitions from nodes to nodes should be as deterministic as possible (after all, most development has also transtions in the form of functions, loops, conditionals etc.). So I guess it should be a mix of the approaches given.