6 Replies Latest reply on Jun 18, 2013 3:37 AM by aarellano

    Proposed temporary and limited approach to supporting excluded owners

    jemmerling

       

      I have been looking at way to do the following within jBPM:

       

      Have a node in a process definition be associated with a particular group (or groups), however due to the history of a given process, to exclude some actor(s) who might be members of that group.

       

      Now the WS-HumanTask specification supports something called excluded owners. Here is a snippet from one version of this specification (not certain if it is the latest one):

       

      "Potential owners of a task are persons who receive the task so that they can claim and complete it. A potential owner becomes the actual owner of a task by explicitly claiming it. Before the task has been claimed, potential owners can influence the progress of the task, for example by changing the priority of the task, adding ad-hoc attachments or comments. All excluded owners are implicitly removed from the set of potential owners. A WS-HumanTask Definition MAY define assignment for this generic human role.

      Excluded owners are are people who cannot become an actual or potential owner and thus they cannot reserve or start the task. A WS-HumanTask Definition MAY define assignment for this generic human role. "

       

      Although the jBPM5 schema supports the existence of excluded owners, I have seen no explicit mechanism to support this when developing an application. If there is something I am missing, please point this out.

       

      In the meantime, I can see a way that a developer could add this functionality without the need to directly modify jBPM5, using the following approach. I would like to know whether it is believed this would work. I am not completely comfortable with this for reasons I will give (although these reasons should be more or less obvious):

       

      1.) First, define a new work item parameter (or analogous mechanism) that represents users who will be excluded from the next node. Let's assume we can correctly identify the next node.

      2.) Create a class that extends WSHumanTaskHandler. This class will override the executeWorkItem method. This method will populate excluded owners in the people assignments from having inspected the new parameter. It will otherwise be the same as the method it overrides except for this one additional logic step.

      3.) Replace the existing Taskorm.xml with a modified version in which the TasksAssignedAsPotentialOwnerByGroup named query (and possibly some similar named queries) is modified so that excluded owners are not able to claim the task.

       

      I believe all the above is feasible because a.) there is nothing to stop the developer from extending WSHumanTaskHandler in the described manner, and using it in the application code and b.) the ORM file is specified in persistence.xml which is a developer-configurable file, so the developer should be at liberty to specify a different file. So all this could be done without "hacking" jBPM directly.

       

      However I am uncomfortable with this approach because the overridden executeWorkItem method as well as the replacement ORM file would be created using a copy-and-paste methodology so that when progressing to a later version of jBPM it would be necessary to modify these to reflect the original logic.

       

      Nevertheless, if there is some intention to support this type of functionality in a future release of jBPM (and assuming I am right to conclude it is not currently supported) this might be a justifiable short-term solution.

        • 1. Re: Proposed temporary and limited approach to supporting excluded owners
          tsurdilovic

          Take a look at http://hudson.qa.jboss.com/hudson/job/jbpm/lastSuccessfulBuild/artifact/jbpm-distribution/target/jbpm-5.3.0-SNAPSHOT-docs-build/jbpm-docs/html_single/index.html#d0e3990

          jBPM 5.2 includes a UserGroupCallback interface that you can provide your own implementation for. There you can pretty much do whatever you want.

           

          Hope this helps.

          • 2. Re: Proposed temporary and limited approach to supporting excluded owners
            jemmerling

            Hi,

             

            Two problems with this:

             

            a.) I can't seem to access this URL (what document in particular do you recommend looking at, can you reply with an attachment?).

            b.) The UserGroupCallback has no access to task or work item information, It is in fact necessary to implement if you need to know anything about users and groups, but I don't see how I can use it to address the concern I discussed in my original post.

             

            I will try to access the URL you gave from a different location later (I am at GMT -5 so I am still at work).

             

            --JE

            • 3. Re: Proposed temporary and limited approach to supporting excluded owners
              garyaiki

              Excluded owners are needed for for peer review. The roles stay the same, unlike an approval process.

               

              The WS-HumanTask specification has generic roles with excluded owners but leaves much to be decided by implementers. Unlike other roles it should be dynamically updated when a user completes a task, and it's a negative query parameter. Also, an excludedOwners list must be specific to either roles, swimlanes or tasks within a process instance.

               

              jBPM makes the first owner of a task the owner of all following tasks in that role for the process instance. This saves unneeded task reassignment but use cases for excluded users shouldn't work this way.

               

              I think these use cases are necessary and sufficient.

               

              Main Use Case

              1. user claims a task.
              2. user completes the task and the process definition specifies that user is excluded from further tasks in a role for that process instance.
              3. for the next task in that role call getPotentialOwners IN (roles) AND NOT IN (excludedOwners)
              4. repeat step 1

              Secondary Use Case

              1. user claims a task which has excludedOwners.
              2. user completes a task and the process definition specifies that the excludedOwners list for that process definition is cleared.
              3. formerly excluded owner can claim next task.
              • 4. Re: Proposed temporary and limited approach to supporting excluded owners
                paulkenny

                Hi John,

                 

                I think I figured out the external URL that should have been put in the first reply posting https://hudson.jboss.org/hudson/job/jbpm/lastSuccessfulBuild/artifact/jbpm-distribution/target/jbpm-5.3.0-SNAPSHOT-docs-build/jbpm-docs/html_single/index.html#d0e3990

                 

                Having looked at it I would agree with your assesment of the UserGroupCallback functionality.

                 

                Have you made any progress with figuring this out? Did your proposed implementation work?

                 

                IMHO this pattern is quite common in business processes where peer review is required and a elegant solution would be nice. I will need to figure out something here myself but just wanted to make sure I am not missing anything obvious.

                 

                  Cheers,

                      Paul

                • 5. Re: Proposed temporary and limited approach to supporting excluded owners
                  jemmerling

                  Hi Paul,

                   

                  At the time I posted, I was merely evaluating jBPM5 so I could not justify the time I would have needed to implement and test my proposed "fix".

                   

                  So the proposal was intended more as a thought experiment to show that the logic to do what I would need is presently absent but could probably be added. But the reasons I gave for feeling uncomfortable with this approach are real. If somebody does successfully try this, then I hope that I have helped them (and that they share their solution with the community).

                   

                  Having said this was an evaluation effort, how I would deal with the problem would be on the application side. In my case, I would be implementing some separate web application (similar in concept to what you see here: https://community.jboss.org/people/bpmn2user/blog/2011/09/21/jbpm5-web-example). So a user would see their "task list" in the UI I create, and (avoiding design pattern issues) this UI would filter tasks out of the task list "after the fact" according to this business rule (which I could probably capture using Drools). And I would hope that, at some point, jBPM5 would add OOTB support for this and then the client-side logic could be retired.

                   

                  As for the link the other poster continues to provide, from what I have seen, the problem is simply that it isn't up all the time. Unless he wants to draw attention to something that is new with jBPM5.3 he should refer to the jBPM5.2 user guide which is on the community web site.

                   

                  Hope this helps!

                   

                  --JE

                  • 6. Re: Proposed temporary and limited approach to supporting excluded owners
                    aarellano

                    Hi guys,

                     

                    I´m working on a same solution as jemmerling but in JBPM 5.4, however I require add dynamically an excluded user for a task. The main issue is that I´m not able to include excluded owners to an existing task and before I extend the WSHumanTaskHandler I was looking for already implemented solution in the api.

                     

                    To complicate the situation I´m using an already existing Drool and Human Task server which are not being executed in my Web Application, and in my web app I just have a client.

                     

                    Thanks!