1 Reply Latest reply on Nov 21, 2006 11:03 AM by H River

    Task Management

    H River Newbie

      We are evaluating jBPM for the purpose of replacing the custom work flow components of our operational support systems. We have two systems which have been in production for roughly five years and a couple of other systems with work flow requirements on the horizon.

      We have run into difficultly with the way task instances are managed within jBPM and were hoping to get some feedback.

      To start with, we view a task list as representing the tasks which can be performed on a particular process instance in it's current state. So if a user were to bring up an order (process instance), the task list would show the tasks which could be performed on the order at that time. We were hoping to back the task list with jBPM task instances. Hopefully there is nothing too unreasonable here.

      One problem we run into is with with an optional task - a task which is valid (but not required) in one particular node, but is not valid in any other node. The task list needs to contain the task while we are in node B, but once we move to node C it should be removed. If we simple define the task on node B it will remain open until it is completed, even if we transition to node C (where it is no longer valid) or even if the process instance completes (when it certainly is not valid). If the task is valid and optional in multiple nodes we have another problem in that now multiple instances of the same task may exist as open. Is there any mechanism for supporting this type of scenario within a process definition? Should we not even attempt to represent these types of tasks on the process definition? Is it reasonable to modify the task instance management to remove any incomplete task instances on leaving a task node?

      Another probelm area is with tasks which can be performed multiple times. If we call end() on the task instance when it is completed the instance will no longer be open and we will need to create another instance to get it into the task list. If we do not call end() we lose the event notification and history. Any suggestions?

      We would also like to give the process designer greater ability to specify when a transition should be taken, especially based on the completion of a particular task. Given the task node signal property and a decision node there is some support for this, but it does not seem to be sufficent when dealing with multiple transitions or tasks (this particluar problem seems to somewhat covered in the Two Transfer Definitions thread). "It would be nice" to simple specificy on a task that a particular transition should be taken when it's complete. For more complex scenarios something along the lines of DecisionHandler might be a better solution. Do either of these solutions sound reasonable? Any other suggestions?

      We would appreciate any help you can offer.