12 Replies Latest reply on Oct 30, 2007 5:40 PM by Ronald van Kuijk

    task component

    Tom Baeyens Master

      here is a short description of the task component as i have it in mind:

      * a task is a runtime task instance. each task is one record in the database. all tasks for all people are in one table. people should be able to look at different 'views' on that table. the most typical view is the query that selects all tasks for which the authenticated user is directly assigned to the task. but all other kind of queries should be possible. e.g. a manager might want to see all tasks for his subordinates.

      * task module must be decoupled from identity component. to achieve that, all references to users and groups are done with plain strings. i refer to them (users and groups) as actors.

      * tasks must be assignable to people directly. the actor property (column) in the task object (record) references a user.

      * tasks must also be assignable to a set of candidates. in this case, the actorId field is null. a set of candidate actorIds must be associatable with the task; in task UI's, a separation should be made between tasks on which you can work and tasks for which you are a candidate. Each of the candidates of a task can try to 'take' the task. That means that the task will be removed from all the other candidate's group task lists and it will appear in the person's personal task list. The list of candidates should still be remembered.

      * tasks must be able to have variables. towards the user of the task API, the variable key's are java.lang.String's and the values are java.lang.Object's. an as-broad-as-possible collection of java types must be supported out of the box. also it should be configurable and pluggable to support new types as variables. this is the same requirement as for process variables, so the process variable mechanism of the pvm should be reused for this.

      * swimlanes should be supported as process roles. a swimlane instance will remember the candidates and actor for multiple tasks in the process that are to be associated to the same person.

      * sub tasks must be supported.

      * a task node should be included in the task component as an integration between the task component and the pvm process execution.

      * all of this must work in
      1) plain java without persistence (meaning no dependency on hibernate or jdbc)
      2) plain java with hibernate persistence
      3) enterprise java with hibernate persistence

        • 1. Re: task component
          Ronald van Kuijk Master

          some additions (maybe for jdpl2?)

          Task variables:
          - variables should be 'typed'
          - it should be possible to give variables an initial value (maybe even via EL, actions)
          - it should be possible to mark variables as
          - required
          - read-only
          with
          - a default of not required and not read-only
          - the option to do this dynamically (e.g. via EL)

          So the variable objects should be more complex then a key and a value.

          * Swimlanes:
          Remembering the candidates is imo not good. In many cases the actual 'available' canditates can change. I'd like the swimlane to remember the 'role/group' runtime have the roles of a user passed to the task manager and use that 'string' instead of the already expanded available candidates.

          * states
          A transition from a state can be triggered externally as well. In many of our systems, we need to make sure certain variables are passed to the process as well (just like with tasks). Currently in these situations we do not use states but task-nodes which are assigned to a system (also an actor).

          Maybe the taskcontroller as there currently is, can be split in a task and variable controller where the variable controller can be used in states as well

          • 2. Re: task component
            Tom Baeyens Master

            I looked at the bonita task package and the docs:

            BONITA roles are related to activities access in processes. Each Process has its specific role management. This allows to have different semantics associated to the same role name in the scope of two different processes.

            Activities are associated to roles, that is each activity can be taken over only by a user assuming a given role. There is a single role associated to each activity. Users participate to a project, and in the scope of this project, a user can assume one or several roles.

            Four types of roles are defined:

            - all users in a group

            - initiator of the workflow project instance

            - user known by his exo's login

            - system: to execute automatic ativity

            We saw how to use the first two types of users in the xpdl part of the document. To define a user known by his eXo login, set his type to HUMAN and his name to the login you want to use.

            The last role define is "SYSTEM", usually it is automatically created when you define an automatic activity in your xpdl editor.


            Miguel, could you explain the roles and rolemappers a bit more ?

            • 3. Re: task component
              Tom Baeyens Master

              thanks, Ronald for the good feedback.

              "kukeltje" wrote:

              Task variables:
              - variables should be 'typed'
              - it should be possible to give variables an initial value (maybe even via EL, actions)
              - it should be possible to mark variables as
              - required
              - read-only
              with
              - a default of not required and not read-only
              - the option to do this dynamically (e.g. via EL)


              - variables should *optionally* be 'typed'
              - initial value (+1)

              * process instance creation, signals and task completion are 3 forms (i think the 3 only) of external triggers. external triggers should be able to specify a signature just like with java method invocations. i also agree with having a required/optional indication.

              * by default, variables should be dynamic. meaning that nothing has to be declared in order to use it. it should be possible to just use a variable in a form without it being declared or initialized before.

              * variable scopes should be: process, node (incl super-states), task. each scope should be able to declare separate variables. initial value might be expressed with EL in terms of outer scope variables. Similarly for leaving a scope, a mapping of the inner scope variables to the outer scope variables should be possible.

              * nested variable scopes should be optional. a complete process with task and forms should be possible based only on process instance level variables.

              "kukeltje" wrote:
              So the variable objects should be more complex then a key and a value.


              the structure of process variables should indeed be more then just 1 hashmap of variables per process instance.

              "kukeltje" wrote:
              * Swimlanes:
              Remembering the candidates is imo not good. In many cases the actual 'available' canditates can change. I'd like the swimlane to remember the 'role/group' runtime have the roles of a user passed to the task manager and use that 'string' instead of the already expanded available candidates.


              that is already possible today in jpdl. just put the role/group as 1 actorId in the candidates list.

              "kukeltje" wrote:
              * states
              A transition from a state can be triggered externally as well. In many of our systems, we need to make sure certain variables are passed to the process as well (just like with tasks). Currently in these situations we do not use states but task-nodes which are assigned to a system (also an actor).


              see note above on signals and external triggers. i agree that something like that is necessary.

              "kukeltje" wrote:

              Maybe the taskcontroller as there currently is, can be split in a task and variable controller where the variable controller can be used in states as well


              again, see above. indeed i agree.

              But you do bring up a point that i forgot to mention: Forms.

              Forms should be decoupled from the task management component. There might be several types of UI that need to be connected to the task management component.

              The task definition should be equipped with a string that identifies a form. Up to the user to determine wether this id is a relative URL in a webapp or a reference to a form file in the process archive or something completely different.

              • 4. Re: task component
                mvaldes Novice

                Hi Tom,

                Humm, I guess the document you mentioned is the Bonita integration in eXo documentation and not the generic Bonita one...

                You will find a good introduction of what a rolemapper is here: http://wiki.bonita.objectweb.org/xwiki/bin/download/Main/Documentation/Bonita_DevelopmentGuide.pdf (Chapter 7)

                Anyway, find hereafter some explanations on roles and rolemappers:

                - Roles are entities associated to a particular workflow process
                - RoleMappers are adds dynamic resolution of users for a particular role.
                - One activity has only one role

                Users returned by a rolemapper resolution will have the task in their todolist. The first of them that takes the task will be responsaible for.

                Another entity, called Performer Assignment, is available if a fine grained users-mappers is required at activity level (a kind of complement to mappers which acts at role level).

                - A Performer Assignment is a java class returning only one user responsible for this task. Commonly, performers selects one of the users resolved by the rolemapper.

                In the previous version of Bonita, RoleMappers were resolved at process instance creation time while PerformerAssigments are when a particular activity in a workflow instances is getting the execution.

                As a first implementation in the XPDL extension based on the PVM both rolemappers and performer assignments are resolved at activity runtime.

                regards,
                Miguel Valdes



                • 5. Re: task component
                  Tom Baeyens Master

                  Aha. That makes much more sense :-)

                  and it maps pretty well to concepts that we have as well. so we should be able to find a common model.

                  • 6. Re: task component
                    Ronald van Kuijk Master

                    Yep, I agree.. a common model should be possible. Although WS-Humantask is imo just one part of the WS-Hell set of specs... 140 pages... come on...

                    With regard to the 'dynamic' group assignment, I will post a note in the normal jbpm forum.

                    • 7. Re: task component
                      mvaldes Novice

                       


                      Forms should be decoupled from the task management component. There might be several types of UI that need to be connected to the task management component.

                      The task definition should be equipped with a string that identifies a form. Up to the user to determine wether this id is a relative URL in a webapp or a reference to a form file in the process archive or something completely different.


                      Forms should also be added to the agenda for the next meeting in Lyon.

                      UI attributes constrains (i.e readonly, required, hide...) should not be defined at task level.
                      Link between forms/webflow and tasks is definitely a topic that could be discussed during the meeting

                      regards,
                      Miguel Valdes

                      • 8. Re: task component
                        Ronald van Kuijk Master

                        Miguel,

                        constraints are imo *not* UI attributes, but task/state/node related attributes (hibe being the exception). The 'engine' should validate these independent of whether they come from a ui related api call, a jms message, a webservice or anything else. The constraint is.

                        I've not looked at the ws-humantask enough to know what their stand on this is. I do like the attribute set of xforms though, where all attributes can even be an xpath statement returning a boolean so you can have e.g. a variable be required depending on the value of other variables.

                        • 9. Re: task component
                          mvaldes Novice

                          Ronald,

                          "kukeltje" wrote:

                          constraints are imo *not* UI attributes, but task/state/node related attributes (hibe being the exception). The 'engine' should validate these independent of whether they come from a ui related api call, a jms message, a webservice or anything else. The constraint is.


                          I understand your point but the key thing is to well define what is workflow related attribute and what is application related (i.e web form).

                          The easiest is to delegate that to the application. This also reduces the workflow engine complexity, which is not responsible of constraints check (i.e this task can only be finished if all required attributes are fulfiled)

                          "kukeltje" wrote:

                          I've not looked at the ws-humantask enough to know what their stand on this is. I do like the attribute set of xforms though, where all attributes can even be an xpath statement returning a boolean so you can have e.g. a variable be required depending on the value of other variables.


                          If I well remember, ws-humantask differentiates between presentation data and operational data. I should give a deeper look to the spec but I think that they don't cover sematic's check or constraints.

                          I also like the way in which xforms handles semantics and constraints check. We have been using xforms in previous Bonita versions but always delegating to xforms constraints and semantic's checks.

                          regards,
                          Miguel Valdes



                          • 10. Re: task component
                            Ronald van Kuijk Master

                            I'll answer in the reverse order ;-)

                            We have been using xforms in previous Bonita versions but always delegating to xforms constraints and semantic's checks.


                            I know, that is why I referred to it and almost chose bonita over jbpm a few years ago.


                            The easiest is to delegate that to the application. This also reduces the workflow engine complexity, which is not responsible of constraints check (i.e this task can only be finished if all required attributes are fulfiled)


                            I agree to a certain extend. If by delegating it to the application you mean delegating it to the model (like the hibernate validation annotations) I agree. But then there should be a realy big 'advisory' to users to only store a relative small amount of data in the processengine (operational data?) and store the rest in their domainmodel (presentation data?), or duplicate some fields. This is what I usually do anyway.

                            But other people use jbpm in another way. So we should either have a more slim 'task component' or a really extensive one, not something that is in between. I understand this is easier said then done and I have no idea what the outcome will be. Maybe keeping things simple and manage the perception of the users upfront is the best way to go.

                            btw, congrats on Nova Bonita M1. I'll definately give it a try again.

                            C

                            • 11. Re: task component
                              Tom Baeyens Master

                              * constraints must be enforces on process variables

                              * constraints should be enforced in the UI on task forms (e.g. xforms constraints and semantic checks)

                              * it must be possible for a task to have local variable scope. Both local variables and references to process variables should be possible, preferrably intermixed as well.

                              is that a good summary ?

                              the problem is the constraint language on the process variables. EL expressions ?

                              • 12. Re: task component
                                Ronald van Kuijk Master

                                good summary.

                                I think EL expressions is an option for simple to moderately complex forms. For more complex forms, like we have in reporting insurance claims, car damage reports etc, the page 'model' is a lot more complex In those cases EL would not be my first choice and xoath seams more suitable. (due to the 'complex' nature of the forms (complex xml elements, repeated etc...))

                                I think hover that they are not mutually exclusive. We do have to watch out though, since the danger is dragging in MDA like stuff.