Preserving the sequence of tasks in processdefinition

[janapoornavel]

hi,
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"
task-node

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.

thanks
jana

[kukeltje]

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

[janapoornavel]

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.

regards,
jana

[kukeltje]

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?

[janapoornavel]

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.

regards,
jana

[icyjamie]

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.