163Task user management

While assigning the actors within a jPDL is simple, in many cases a dynamic assign- ment may be required. To further expand on our example of the PO process, the indi- vidual assigned to the task would likely depend on whom the requestor is reporting, from an organizational perspective. Perhaps jdoe would require djohnson’s approval, but msmith would need ltaylor. While you could attempt to create separate process flows to accommodate this, a far easier solution would be to use a custom assignment class or script. This is referred to as creating a custom assignment handler. An assign- ment handler class must implement the AssignmentHandler interface, and with it the required method assign. Listing 6.1 shows a simple assignment handler that imple- ments the rules we defined earlier (this class can also found in the sample code).

public class AssignmentExample implements AssignmentHandler { public void assign(Assignable assignable,

ExecutionContext context) throws Exception {

String submitter = (String) context.getContextInstance() .getVariable("submitter"); if (submitter.equalsIgnoreCase("jdoe")) assignable.setActorId("djohnson"); else if (submitter.equalsIgnoreCase("msmith")) assignable.setActorId("ltaylor"); else assignable.setActorId("rharris"); } }

Listing 6.1 An example of a jBPM AssignmentHandler class

jBPM Console identity component

One source of confusion that often arises is the interplay between the jBPM identity component that’s used by the jBPM Console and the actors within a process. The

identity component that comes with jBPM Console is used only for purposes of man- aging the login process and for controlling the permission-based menu options that are used within jBPM Console. It’s not referenced, directly or otherwise, by the pro- cess engine itself (with one apparent caveat: email resolution requires it). For exam- ple, when you log in to jBPM Console, the identity component is used to validate your credentials. Then, once completed, your username acts as your actorId for deter- mining which tasks you’ve been assigned. The identity component also uses groups

to determine which menu options exist through jBPM Console, such as user, manager, and admin. A user is associated with one or more of these groups through a membership. Thus, the identity component is used by the jBPM Console to deter-

mine which menu options and privileges the user has, and effectively associates the user’s login username with an actorId when interacting with the jBPM engine. The jBPM User Guide and some community forum entries describe, in some detail, how you can replace the default identity component with a custom alternative.

Implements required method

164 CHAPTER 6 jBPM tasks

In the highlighted code, you see how we are just hard-coding (for demonstration pur- poses) some logic for how to perform an assignment. In the first case, we’re simply checking to see whether the submitter’s name (submitter was retrieved as a process variable) is jdoe, and if so, we assign the task to djohnson (using the setActorId method). In a real-life scenario, a lookup to an LDAP directory server might be used to retrieve the organizational approvals that are required. Also, instead of using Assignable.setActorId(), you could just as easily assign a pooled group of actors using Assignable.setPooledActors(), which takes an array of actorId Strings.

NOTE The same configuration options available for the AssignmentHandler class are available for the ActionHandler class. See chapter 5.

You’ve probably encountered scenarios where, once a given task is assigned to an indi- vidual or group, it makes sense for any follow-up tasks related to the same work order or process to also be assigned to that same individual or group. After all, they’re already familiar with the issue. This can be accomplished with jBPM using a concept called swimlanes. Let’s explore this further so that you may consider using this func- tionality in the processes you develop.

6.2.2 Understanding swimlanes

Swimlanes, whose terminology is derived from UML activity diagrams and/or cross- functional flowcharts, represent roles that can be assigned to an individual actor or pooled group. Swimlanes are used when multiple tasks within a process should be per- formed by the same actor. For example, if tasks A and B are sequential and both are assigned the same swimlane, then when task A is completed, task B will automatically be assigned to the same actor as was assigned to task A. When do swimlanes make sense? When several tasks within a process exist within a given organization, say Human Resources, it often makes sense to have the same individual perform all of the given tasks as it relates to a given process instance. Also, because of the sensitivity of many HR-related tasks, it’s sometimes better to limit exposure beyond what is neces- sary—spreading out the work to multiple people for a given process instance may be undesired.

Thus, when using a swimlane within a task, you don’t specify an assignment to an individual actor or pooled group of actors, since the assignment is done within the definition of the swimlane itself. This can best be illustrated through a simple exam- ple, so consider the process shown in figure 6.3.

In the example shown in figure 6.3, the swimlane called approver was created at the root level of the jPDL definition. The two tasks that follow, approveAmt and assign-charge-codes, both use the @swimlane attribute to associate the task with that previously defined swimlane. Notice that the swimlane was defined using the @pooled-actors attribute, but a single assignment using @actor-id is permitted as well (or even a combination of the two).

165