16 Worklist Application

16.3.1.1 Task Actions

Figure 16-3 shows a Task Action list. The actions in the list depend on the task design, the state of the task (for example, if the task has been completed, then no actions are listed), and the roles assigned to the logged-in user. Custom actions (actions defined in the BPEL process), such as Accept or Reject, are listed first. System actions, such as Escalate or Suspend, are listed below a separator line.

Figure 16-3 Task Actions List

Description of the illustration wl_task_act_list.gif

You act on tasks using either the Task Action list or a button. The Task Action list contains actions that do not require additional input, such as accept, reject, renew, and suspend. Buttons are provided for actions that require additional input, such as reassignment and requests for information.

System actions are available on all tasks based on the user's privileges. Table 16-3 lists system actions.

After you select one of the actions, the task is routed to the next step, depending on how the business process was designed. When a task is completed, all actions and form elements are disabled.

16.3.1.2 Request Status

For every update request (custom or system action) that you submit, the status of the request is displayed in the left portion of the header. If a request is successful, then you see a confirming message, as shown near the top of the page in Figure 16-4.

Figure 16-4 A Successful Update Request

Description of the illustration wl_successful.gif

If a request is not successful, then you see an error message, as shown in Figure 16-5. You can click the link for additional information about the error.

Figure 16-5 Error Message Display

Description of the illustration wl_request_not_success.gif

The error shown in Figure 16-5 occurs when a user has attempted an action that is not permitted. This is possible in the following scenarios:

• The task expired between the time the user loaded the page and actually performed the action.

• The task was claimed and updated concurrently by another user (such as a manager, owner, or administrator) between the time the user loaded the page and actually performed the action.

Errored tasks are not assigned to a specific user. They are only assigned to the bpeladmin user. If you are a user other than bpeladmin and want to see these errors, select All in the Category list and Errored or Any in the Status list.

16.3.1.3 Header Section

Figure 16-6 shows the header section. Header information includes the task number and title; the state, outcome, and priority of the BPEL process, and information about who created, updated, claimed, or is assigned to the task. It also displays dates related to task creation, last modification, and expiration.

Figure 16-6 Header Section of the Task Details Page

Description of the illustration wl_header1.gif

16.3.1.4 Payload Section

Figure 16-7 shows the payload section for the Vacation Request Process Request workflow. The fields displayed—Creator, From Date, To Date, Reason—reflect how the BPEL process for vacation approval was designed, using the autogenerated JSP.

Figure 16-7 Payload Section

Description of the illustration wl_payload.gif

See "Automatically Generating a Simple Task Display Form" for information on using the autogenerated JSP in your workflow design.

16.3.1.5 Comments and Attachments Section

Figure 16-8 shows where you add or delete comments and attachments. To add or delete a comment or attachment, you must have permission to update the task.

Figure 16-8 Adding a Comment or Attachment

Description of the illustration wl_comments.gif

A newly added comment and the comment writer's username are appended to the existing comments. A trail of comments is maintained throughout the life cycle of the task. When adding attachments, you can use an absolute path name or browse for a file or provide a URL.

16.3.1.6 History Section

Figure 16-9 shows the short history for a vacation approval task.

Figure 16-9 History Section of the Task Details Page

Description of the illustration wl_history.gif

The short history for a task lists all versions created by the following tasks:

• Initiate task

• Reinitiate task

• Update outcome of task

• Completion of task

• Erroring of task

• Expiration of task

• Withdrawal of task

• Alerting of task to the error assignee

You can include the following actions in the short history list by modifying the shortHistoryActions element in

SOA_Oracle_Home\bpel\system\services\config\wf_config.xml

• Acquire

• Adhoc route

• Auto release of task

• Delegate

• Escalate

• Information request on task

• Information submit for task

• Override routing slip

• Update outcome and route

• Push back

• Reassign

• Release

• Renew

• Resume

• Skip current assignment

• Suspend

• Update

The full history lists all version changes in a task.

16.3.1.7 Routing

If there is no predetermined sequence of approvers or if the workflow was designed to permit ad hoc routing, then the task can be routed in an ad hoc fashion. For such tasks, a Route button appears on the Task Details page. From the Routing page, you can look up one or more users for routing. When you specify multiple assignees, you can choose whether the list of assignees is for simple (group assignment to all users), sequential, or parallel assignment. In the case of parallel assignment, you provide the percentage of votes required for approval.

16.3.1.8 Requesting More Information

From the Task Details page, you can request more information by using the Request Info button. The Reapproval Needed field appears if previous approvers must reapprove given the additional information, assuming that the process was designed to support reapproval. You can also add comments. After you have requested additional information, the task is assigned to the user from whom the additional information is needed. The user from whom additional information is requested uses Submit More Info to fulfill the request.

16.3.1.9 Reassignment

From the Task Details page, you can reassign a task using the Reassign button. As Figure 16-10 shows, you can either reassign (transfer) or delegate:

Figure 16-10 Reassigning Tasks

Description of the illustration wl_reassign2.gif

• Reassign (transfer task to another user or group)—The task is moved from the assignee's worklist to another user's worklist. The newly assigned user then acts on the task, rather than the original user.

• Delegate (allow specified user to act on my behalf)—The task is delegated to another user, but it shows up in both the original user's and the delegated user's worklists. The delegated user can act on behalf of the original assignee.

Use the Search button to find assignees and the up and down arrows to select or deselect assignees. Wildcard search is supported.

A supervisor can always reassign tasks to any of his reportees. Users with the BPMWorkflowReassign role can assign tasks to any users in the organization.

16.3.1.10 Parallel Tasks

Parallel tasks are created when a parallel flow pattern is specified for scenarios such as voting. In this pattern, the parallel tasks have a common parent. The parent task is visible to a user only if the user is an assignee or an owner or creator of the task. The parallel tasks themselves (referred to as subtasks) are visible to whomever the task is assigned, just like any other task. It is possible to view the subtasks from a parent task. In such a scenario, the Task Details page of the parent task contains a View SubTasks button. The SubTasks page lists the corresponding parallel tasks. In a voting scenario, if any of the assignees updates the payload or comments or attachments, the changes are visible only to the assignee of that task. A user who can view the parent task (such as the final reviewer of a parallel flow pattern), can drill down to the subtasks and view the updates made to the subtasks by the participants in the parallel flow.

16.3.1.11 Determining Action Permissions

A user can view a task when associated with the task as one of the following: current assignee (directly or by group membership), current assignee's manager, creator, owner, or a previous actor.

A user's profile determines his group memberships and roles. The roles determine a user's privileges. Apart from the privileges, the exact set of actions a user can perform is also determined by the state of the task, the custom actions, and restricted actions defined for the task flow at design time.

The following algorithm is used to determine the actions a user can perform on a task:

1. Get the list of actions a user can perform based on the privileges granted to him.

2. Get the list of actions that can be performed in the current state of the task.

3. Create a combined list of actions that appear on the preceding lists.

4. Remove any action on the combined list that is specified as a restricted action on the task.

The resulting list of actions is displayed in the listing page and the Task Details page for the user. When a user requests a specific action, such as claim, suspend, or reassign, the workflow service ensures that the requested action is contained in the list determined by the preceding algorithm.

Step 2 in the preceding algorithm deals with many cases. If a task is in a final, completed state (after all approvals in a sequential flow), an expired state, a withdrawn state, or an errored state, then no further update actions are permitted. In any of the these states, the task, task history, and subtasks (parent task in parallel flow) can be viewed. If a task is suspended, then it can only be resumed or withdrawn. A task that is assigned to a group must be claimed before any actions can be performed on it.

See "Identity Service" for information about the identity service and how privileges can be assigned to users.

16.3.5.1 Vacation Preferences

Use the vacation preferences to make yourself unavailable for task assignments. As Figure 16-15 shows, you specify a vacation date range, and optionally create a rule. Based on the rules you specify, tasks can be approved automatically or reassigned to someone else, for example.

Figure 16-15 Setting a Vacation Preference in the Worklist Application

Description of the illustration wl_rule_vac.gif

As Figure 16-16 shows, when creating a rule, you can specify which task the rule applies to, add conditions, and delegate or reassign the task to another user or a group.

Figure 16-16 Creating a Rule in the Worklist Application

Description of the illustration wl_vac.gif

16.3.5.2 My Rules

Use a rule to specify conditions which, if true, cause an automatic action on a task. Examples include vacation rules, as discussed in the previous section, or a rule in which certain types of tasks are approved automatically. As Figure 16-16 shows, you can specify the following when creating a rule:

• Rule name and description

• Which task the rule applies to—If unspecified, then the rule applies to all tasks.

• When the rule applies

• Conditions on the rule—These are filters that further define the rule, such as specifying that a rule acts on priority 1 tasks only, or that a rule acts on tasks created by a specific user. The conditions can be based on standard task attributes as well as any flex fields that have been mapped for the specific tasks. See "Using the Administration Functions" for information about mapping flex fields.

  Figure 16-17 shows how you add conditions to a rule.

  Figure 16-17 Adding Conditions on a Rule

  
  Description of the illustration wl_rules_cond.gif
  
  

• Actions

  • Reassign to—You can reassign tasks to subordinates or groups you manage. If you have been granted the BPMWorkflowReassign role, then you can reassign tasks to any user or group.

  • Delegate to—You can delegate to any user or group.

  • Set outcome to—You can specify an automatic outcome if the workflow task was designed for those outcomes, for example, accepting or rejecting the task. The rule must be for a specific task type. If a rule is for all task types, then this option is not displayed.

  • Take no action—Use this action to prevent other more general rules from applying. For example, if you want to reassign all your tasks to another user while you are on vacation, with the exception of loan requests, for which you want no action taken, then create two rules. The first rule specifies that no action is taken for loan requests; the second rule specifies that all tasks are reassigned to another user. The first rule will prevent reassignment for loan requests.

Figure 16-18 shows the Rules List page. Rules are executed in the order in which they are listed. Use the Move Up and Move Down buttons to reorder rules. If a rule meets its filter conditions, then it is executed and no other rules are evaluated. For your rule to execute, you must be the only user assigned to that task. If the task is assigned to multiple users (including you), the rule does not execute.

Figure 16-18 Setting User Rules in Worklist Preferences

Description of the illustration wl_rules2.gif

Figure 16-18 also shows the following:

• You can create, delete, and edit rules (click the rule name).

• A rule is active (see the Active column in Figure 16-18) if the date range you specified when you created the rule is current.

16.3.5.3 Group Rules

Use a group rule to specify how a workflow rule applies to members of a group. Examples of group rules include:

• Assigning tasks from a particular customer to a member of the group

• Ensuring an even distribution of task assignments to members of a group by using round-robin assignment

• Ensuring that high-priority tasks are routed to the least busy member of a group

Creating a group rule is similar to creating other rules (see Figure 16-16, "Creating a Rule in the Worklist Application"); only some of the actions are different. For group rules, you can specify the following actions:

• Reassign via—You can specify a criterion to determine which member of the group gets the assignment. This dynamic assignment criterion can include round-robin assignment, assignment to the least busy group member, or assignment to the most productive group member. You can also add your custom functions for allocating tasks to users in a group. See the following for more information:

  • "Runtime Config Service" for more information about dynamic assignment

  • "Implementing a Dynamic Assignment Function" for more information about custom functions

• Reassign to—As with user rules, you can reassign tasks to subordinates or groups you directly manage. If you have been granted the BPMWorkflowReassign role, then you can reassign tasks to any user or group (outside your management hierarchy).

• Take no action—As with user rules, you can create a rule with a condition that prevents a more generic rule from being executed.

The group Rules List page is similar to the user Rules List page, with the addition of a list of the groups that you (as the logged-in user) manage. You can select from this list to specify the group for which you are creating a rule.

16.3.5.4 Custom Views

Use a custom view to customize your task list display. Examples of custom displays include:

• Ordering the task list in a particular way

• Displaying only those tasks that meet a particular condition

• Displaying specific attributes (columns) in your task list

You can also grant other users access to your views.

Figure 16-19 shows the Custom Views page.

Figure 16-19 The Custom Views Page

Description of the illustration wl_custview_list.gif

The following functionality is available:

• You can create, edit, copy, and delete views, and choose to make the view visible or not in the My Views section of the Work Queues pane.

• For each view in the Granted Views list, you can choose to make the view visible or not in the Delegated Views section of the Work Queues pane on the Task List page.

• Details are available for granted views. You can rename a view granted to you.

Figure 16-20 shows the Create Custom View page.

Figure 16-20 Creating a Custom View

Description of the illustration wl_custview.gif

You can specify the following when creating a custom view:

• General—You must specify a name for your view.

• Columns—You can specify which columns you want to display in your task list. The columns in the views can be standard task attributes as well as any flex fields that have been mapped for the specific task type. See "Using the Administration Functions" for information about mapping flex fields.

  The default columns are the same as the columns in your inbox. You can also choose to show tasks actions in your task list and select ascending or descending order for a single column.

• Filter—You can specify which task categories you want to display, for example, My, Group, My & Group, and so on. You can also add conditions, for example, a condition that displays a task only when the title contains the words loan request.

• Sharing—You can grant access to this view to another user; for example, if jstein grants access to a My & Group category of tasks to jcooper, then jcooper will see jstein's tasks and group tasks. Sharing a view with another user is similar to delegating all tasks that correspond to that view to the other user; that is, the other user can act on your behalf. Shared views are visible in the Proxy Work Queues section of the worklist (shown in Figure 16-14, "Work Queues Pane").

16.3.5.5 Display Preferences

Use display preferences to customize how tasks are displayed in your worklist. As Figure 16-21 shows, you can use the following options to customize the display:

• Maximum number of tasks per page

• Page height in pixels

• Default ordering of tasks

• Show the following columns in the inbox view

• Show task actions in task list

Figure 16-21 Setting Display Preferences in the Worklist Application

Description of the illustration wl_display.gif

16.3.6.1 Manage Rules

An administrator uses the Manage Rules tab, shown in Figure 16-22, to view or edit the rules for any user or group.

Figure 16-22 The Manage Rules Tab

Description of the illustration wl_manage_rules.gif

This tab is useful if an administrator is needed to fix a problem with a rule. Also, for a user who no longer works for the company, administrators can set up a rule for that user so that all tasks assigned to the user are automatically assigned to another user or group.

16.3.6.2 Flex Field Mappings

An administrator uses the Flex Field Mappings tab, shown in Figure 16-23, to promote data from the payload to inline attribute flex fields. By promoting data to flex fields, the data becomes searchable and can be displayed as columns in the Task Listing (home) page.

Figure 16-23 The Flex Field Mappings Tab

Description of the illustration wl_flexfields2.gif

16.3.6.2.1 Creating Labels

To create a flex field mapping, an administrator first defines a semantic label, which provides a more meaningful display name for the flex field attribute. Click Create Label to use the Create Payload Mapping Label interface, as shown in Figure 16-24.

Figure 16-24 Creating a Label

Description of the illustration wl_creatinglabel.gif

As the figure shows, the label amount is mapped to the flex field NumberAttribute1, The payload attribute is also mapped to the label. In this example, the Number attribute type is associated with the amount label. The end result is that the value of the Number attribute is stored in the NumberAttribute1 column, and amount is the column label for that value as displayed in the user's task list. Labels can be reused for different task types. You can delete a label only if it is not used in any mappings.

A mapped payload attribute can also be displayed as a column in a custom view, and used as a filter condition in both custom views and workflow rules. The display name of the payload attribute is the attribute label that is selected when doing the mapping.

16.3.6.2.2 Browsing All Mappings

When this option is selected, all flex field mappings defined for all task types are displayed, as shown in Figure 16-25.

Figure 16-25 Browsing Mappings

Description of the illustration wl_browseall.gif

To display all the payload attributes mapped to a particular label, click the respective row in the label table.

16.3.6.3 Application Customization

An administrator uses the Application Customization tab, shown in Figure 16-30, to customize the appearance of the Worklist Application.

Figure 16-30 The Application Customization Tab

Description of the illustration wl_customizing2.gif

Values can be specified for the following parameters:

• Login page realm label—If the identity service is configured with multiple realms, then the Worklist Application login page displays a list of realm names. LABEL_LOGIN_REALM specifies the resource bundle key used to look up the label to display these realms. The term realm can be changed to fit the user community—terms such as country, company, division, or department may be more appropriate. Administrators can customize the resource bundle, specify a resource key for this string, and then set this parameter to point to the resource key.

  See "Customizing the Login Page" for information on customizing the image on the login page.

• Branding image location—This is the image displayed in the top left corner of every page of the Worklist Application. (The Oracle logo is the default.) Administrators can provide a .gif, .png, or .jgp file for the logo. This file must be in the public_html directory of the Worklist Application.

  See "Customizing Header Information" for information about the header.

• Application resource bundle classname—A resource bundle provides the strings displayed in the Worklist Application. By default, this is the class at:

  oracle.bpel.services.workflow.resource.WorkflowResourceBundle
  
  

  Administrators can change the strings shown in the application by copying WorkflowResourceBundle and creating their own. This parameter allows administrators to specify the classpath to this custom resource bundle.

16.3.7.1 Unattended Tasks Report

This report provides an analysis of tasks assigned to users' groups or reportees' groups that have not yet been claimed (unattended tasks). Use the following input parameters to define the report:

• Assignee—The tasks analyzed are based on the category chosen as it applies to the user; that is, tasks assigned to the user's groups, tasks assigned to the reportee's groups, tasks where the user is a creator, and tasks where the user is an owner.

• Creation Date (range)

• Expiration Date (range)

• Task State

• Priority

See Table 16-2 for descriptions of Creation (or Created) Date, Expiration Date, Task State (or Status), and Priority.

Figure 16-32 shows an example of an Unattended Tasks Report.

Figure 16-32 Unattended Tasks Report

Description of the illustration wl_unattend_rpt2.gif

The report shows that the California group has 15 unattended tasks, the Supervisor group has 7 unattended tasks, and the LoanAgentGroup has 11 unattended tasks. The unattended (unclaimed) tasks in this report are all DocumentReview tasks. If more than one type of unattended task exists when a report is run, all task types are included in the report, and the various task types are differentiated by color.

16.3.7.2 Tasks Priority Report

This report provides an analysis of the number of tasks assigned to a user, reportees, or their groups, broken down by priority. Use the following input parameters to define the report:

• Assignee—Depending on the assignee that you choose, this includes tasks assigned to you (My), tasks assigned to you and groups that you belong to (My & Group), or tasks assigned to groups to which your reportees belong.

• Creation Date (range)

• Ended Date (range)—This is the end dates of the tasks to be included in the report.

• Priority

See Table 16-2 for descriptions of Creation (or Created) Date and Priority.

Figure 16-33 shows an example of a Tasks Priority Report.

Figure 16-33 Tasks Priority Report

Description of the illustration wl_prio_rpt.gif

The report shows that the California group, the Supervisor group, and the LoanAgentGroup each have 16 tasks of normal priority. The users rsteven and jcooper have 5 and 22 tasks, respectively, all normal priority. Priorities (highest, high, normal, low, lowest) are distinguished by different colors in the bar chart.

16.3.7.3 Tasks Cycle Time Report

This report provides an analysis of the time taken to complete tasks from creation to completion based on users' groups or reportees' groups. Use the following input parameters to define the report:

• Assignee—Depending on the assignee that you choose, this includes your tasks or tasks assigned to groups to which your reportees belong.

• Creation Date (range)

• Ended Date (range)—This is the end dates of the tasks to be included in the report.

• Priority

See Table 16-2 for descriptions of Creation (or Created) Date and Priority.

Figure 16-34 shows an example of a Tasks Cycle Time Report.

Figure 16-34 Tasks Cycle Time Report

Description of the illustration wl_cyctime_rpt.gif

The report shows that it takes 1 hour and 6 minutes on average to complete DocumentReview tasks, and 1 hour and 28 minutes on average to complete VacationApproval tasks. The bar chart shows the average cycle time in milliseconds.

16.3.7.4 Tasks Productivity Report

This report provides an analysis of assigned tasks and completed tasks in a given time period for a user, reportees, or their groups. Use the following input parameters to define the report:

• Assignee—Depending on the assignee that you choose, this includes your tasks or tasks assigned to groups to which your reportees belong.

• Creation Date (range)—The default is one week.

• Task Type—Use the flashlight icon to select from a list of task titles. All versions of a task are listed on the Select Workflow Task Type page, as shown in Figure 16-35.

  Figure 16-35 Select Workflow Task Type

  
  Description of the illustration wl_seltasktype.gif
  
  

Figure 16-36 shows an example of a Tasks Productivity Report.

Figure 16-36 Tasks Productivity Report

Description of the illustration wl_product_rpt.gif

The report shows the number of tasks assigned to the California, LoanAgentGroup, and Supervisor groups. For individual users, the report shows that jcooper has 22 assigned tasks. In addition to his assigned tasks, jcooper has completed 2 tasks. The report shows that mtwain and rsteven have completed 6 and 11 tasks respectively. In the bar chart, the two task states—assigned and completed—are differentiated by color.

16.5.1.1 Customizing the Login Page

You can customize the image on the login page (the default is an image of people). In Login.jsp, replace the portion of the image tag shown in bold (people.jpg) with your own image:

<IMG HEIGHT="55" SRC="img/people.jpg">

See "Application Customization" for information on customizing the login page realm label.

16.5.1.2 Customizing Header Information

The header section appears on every page above the bread crumb navigation. You can customize the header by modifying the Header.jsp file. The logo and the name of the application in the left corner are contained in the Branding.jsp file that is included in the header.

See "Application Customization" for information on changing the branding image.

The upper-right area contains HTML controls for filters and search criteria for retrieving tasks. The filters can be customized to include only those choices that are relevant to the application.

16.5.1.3 Customizing the Task Details Page

The Task Details page is used to examine the contents of the task and view or update the payload. The layout of the details page consists of the actions and buttons at the top, a header section, the payload section, and the footer section consisting of optional contents such as comments and attachments. The information displayed on this form is typically defined by the task definition for the task being displayed (and the format is controlled by the workflow task designer). You can customize the Task Details page by modifying the TaskDetails.jsp file. See "Generating a Custom Task Display Form" for information on how to customize this file.

16.5.1.4 Changing the Client-Service Binding for the Worklist Application

The workflow services client interfaces can use a number of protocols to communicate with the workflow services. The client implementations encapsulate all the communication details, and users of the client interfaces do not need to be concerned with the details.

The Worklist Application is deployed in the same container as the workflow services, by default, and the application uses the Java client.

To switch the client type used by the Worklist Application, modify the init method in BaseServlet.java as follows:

public void init(ServletConfig config) throws ServletException
{ 
  super.init(config);
  try 
  {
   wfSvcClient 
     = WorkflowServiceClientFactory.getWorkflowServiceClient(
                            WorkflowServiceClientFactory.JAVA_CLIENT);    
  }
  catch (Exception e) 
  {
    wlSvcError = getStackTraceString(e);      
   }
}

Also, change WorkflowServiceClientFactory.JAVA_CLIENT to one of the following:

• WorkflowServiceClientFactory.SOAP_CLIENT—to use the SOAP-based Web services interface

• WorkflowServiceClientFactory.LOCAL_CLIENT—to use the local EJB interface

• WorkflowServiceClientFactory.REMOTE_CLIENT—to use the remote EJB interface

In addition, ensure that the wf_client_config.xml file is correctly set up for the client type that you select.

16.5.1.5 Deploying the Custom Worklist Application

The top-level directory of the sample Worklist Application contains an ant script, build.xml, that can be used to build and deploy the Worklist Application. This ant script makes use of the properties file orabpel.properties that exists in the same directory. The instructions in this section also provide fixes to some incorrect files in the sample Worklist Application source files configuration.

This section contains the following topics:

• Task 1: Changing the Application Configuration

• Task 2: Changing the Build File

• Task 3: Reviewing the File Changes

• Task 4: Building and Deploying the Application

  See Also:

  "Enabling the Worklist Application for Single Sign-On" after performing these tasks if you want to secure the Worklist Application to be Java single sign-on (JSSO)-enabled