29.2.2 How to Specify a Task Title

To specify a task title:

Enter an optional task title. The title defaults to this value only if the initiated task does not have a title set in it. The title provides a visual identifier for the task. The task title displays in Oracle BPM Worklist. You can also search on titles in Oracle BPM Worklist.

In the Task Title field of the General section, select a method for specifying a task title:

Text and XPath: Enter a combination of manual text and a dynamic expression. After manually entering a portion of the title (for example, Approval Required for Order Id:), place the cursor one blank space to the right of the text and click the icon to the right of this field. This displays the Expression Builder for dynamically creating the remaining portion of the title. After completing the dynamic portion of the name, click OK to return to this field. The complete name is displayed. For example:

Approval Required for Order Id: <%/task:task/task:payload/task:orderId%>

The expression is resolved during runtime with the exact order ID value from the task payload.

If you enter a title in the Task Title field of the General tab of the Create Human Task dialog described in the title you enter here is overridden.

29.2.3 How to Specify a Task Description

You can optionally specify a description of the task in the Description field of the General section. The description enables you to provide additional details about a task. For example, if the task title is Computer Upgrade Request, you can provide additional details in this field, such as the model of the computer, amount of CPU, amount of RAM, and so on. The description does not display in Oracle BPM Worklist.

The task outcomes can also have runtime display values that are different from the actual outcome value specified here. This permits outcomes to be displayed in a different language in Oracle BPM Worklist. For more information about internationalization, see Section 29.6.2, "How to Specify Multilingual Settings."

To specify a task outcome:

To the right of the Outcomes field in the General section, click the Search icon.

The Outcomes dialog shown in Figure 29-4 displays the possible outcomes for tasks. APPROVE and REJECT are selected by default.

In the Name field of the dialog, enter a custom name, and click OK. Your outcome displays in the Outcomes field.

Notes: Be aware of the following naming restrictions:

Do not specify a custom name that matches a name listed in the Actions tab of the Access section of the Human Task Editor (for example, do not specify Delete). Specifying the same name can cause problems at runtime.

Do not specify a custom name with blank spaces (for example, OnHold). This causes an error when the custom outcome is accessed in Oracle BPM Worklist. If you must specify an outcome with spaces, use a resource bundle. For more information, see

A custom task outcome must begin with a letter of the alphabet, either upper or lower case. It should contain only letters of the alphabet and the numbers zero (0) through nine (9).

Outcomes Requiring Comment

Click to select an outcome to which an assignee adds comments in Oracle BPM Worklist at runtime. The assignee must add the comments and perform the action without saving the task at runtime.

Default Outcome

Select the default outcome for this outcome.

The seeded and custom outcomes selected here display for selection in the Majority Voted Outcome section of the parallel participant type.

29.2.5 How to Specify a Task Priority

Specify the priority of the tasks. Priority can be 1 through 5, with 1 being the highest. By default, the priority of a task is 3. This priority value is overridden by any priority value you select in the General tab of the Create Human Task dialog. You can filter tasks based on priority and create views on priorities in Oracle BPM Worklist.

To specify a task priority:

From the Priority list in the General section, select a priority for the task.

For more information about specifying a priority value in the Create Human Task dialog, see

29.2.6 How to Specify a Task Category

You can optionally specify a task category in the Category field of the General section. This categorizes tasks created in a system. For example, in a help desk environment, you may categorize customer requests as either software-related or hardware-related. The category displays in Oracle BPM Worklist. You can filter tasks based on category and create views on categories in Oracle BPM Worklist.

To specify a task category:

Select a method for specifying a task category in the Category field of the General section:

By Name: Manually enter a name.

By Expression: Click the icon to the right of this field to display the Expression Builder for dynamically creating a category.

29.2.7 How to Specify a Task Owner

The task owner can view the tasks belonging to business processes they own and perform operations on behalf of any of the assigned task participant types. Additionally, the owner can also reassign, withdraw, or escalate tasks. The task owner can be considered the business administrator for a task. The task owner can also be specified in the Advanced tab of the Create Human Task dialog described in The task owner specified in the Advanced tab overrides any task owner you enter here.

29.2.7.1 Specifying a Task Owner Statically Through the User Directory or a List of Application Roles

Task owners can be selected by browsing the user directory (Oracle Internet Directory, Java AuthoriZatioN (JAZN)/XML, LDAP, and so on) or a list of application roles configured for use with Oracle SOA Suite.

To specify a task owner statically through the user directory or a list of application roles:

In the first list to the right of the Owner field in the General section, select User, Group, or Application Role as the type of task owner. Figure 29-5 provides details.

To select a user or group, you must first create an application server connection by clicking the Add icon. Note the following restrictions:

Do not create an application server connection to an Oracle WebLogic Administration Server from which to retrieve the list of identity service realms. This is because there is no identity service running on the Administration Server. Therefore, no realm information displays and no users display when performing a search with a search pattern in the Identity Lookup dialog. Instead, create an application server connection to a managed Oracle WebLogic Server.

You must select an application server connection configured with the complete domain name (for example, myhost.us.oracle.com). If you select a connection configured only with the hostname (for example, myhost), the Realm list may not display the available realms. If the existing connection does not include the domain name, perform the following steps:

In the Resource Palette, right-click the application server connection.

Select Properties.

In the Configuration tab, add the appropriate domain to the hostname.

Return to the Identity Lookup dialog and reselect the connection.

Select or create an application server connection to display the realms for selection. A realm provides access to a policy store of users and roles (groups).

Search for the owner by entering a search string such as jcooper, j*, *, and so on. Clicking the Lookup icon to the right of the User Name field fetches all the users that match the search criteria. Figure 29-7 provides details. One or more users or groups can be highlighted and selected by clicking Select.

If you selected Application Role, the Select an Application Role dialog appears.

In the Application Server list, select the type of application server that contains the application role or click the Add icon to launch the Create Application Server Connection wizard to create a connection.

In the Application list, select the application that contains the application roles (for example, a custom application or soa-infra for the SOA Infrastructure application).

Browse the available variable schemas and functions to create a task owner.

Click OK to return to the Human Task Editor.

Your selection displays in the Owner field.

For more information, see the following:

Click Help for instructions on using the Expression Builder dialog and XPath Building Assistant

for information about workflow service dynamic assignment functions, identity service functions, and instructions on using the XPath Building Assistant

29.2.8 How To Specify an Application Context

You can specify the name of the application that contains the application roles used in the task. This indicates the context in which the application role operates. If you do not explicitly create a task, but end up having one, you can set up the context.

In the Application Context field of the General section, enter the name.

29.3 Specifying the Task Payload Data Structure

This section enables you to specify the structure (message elements) of the task payload (the data in the task) defined in the XSD file. You create parameters to represent the elements in the XSD file. This makes the payload data available to the workflow task. For example:

You create a parameter for an order ID element for placing an order from a store front application.

You create parameters for the location, type, problem description, severity, status, and resolution elements for creating a help desk request.

Task payload data consists of one or more elements or types. Based on your selections, an XML schema definition is created for the task payload.

Select Type or Element and click the Search icon to display the Type Chooser dialog for selecting the task parameter.

Parameter Name

Accept the default name or enter a custom name. This field only displays if Type is the selected parameter type.

Editable via worklist

Select this checkbox to enable users to edit this part of the task payload in Oracle BPM Worklist. For example, for a loan approval task, the APR attribute may need to be updated by the user reviewing the task, but the SSN field may not be editable.

You can only define payload mapped attributes (previously known as flex field mappings) in Oracle BPM Worklist for payload parameters that are simple XML types (string, integer, and so on) or complex types (for example, a purchase order, and so on). If you must search tasks using keywords or define views or delegation rules based on task content, then you must use payload parameters based on simple XML types. These simple types can be mapped to flex columns in Oracle BPM Worklist.

To edit your selection, select it and click the Edit icon in the upper right part of the Data section.

29.4 Assigning Task Participants

Figure 29-16 shows the Assignment section of the Human Task Editor. This section enables you to select a participant type that meets your business requirements. While configuring the participant type, you build lists of users, groups, and application roles to act upon tasks.

You can easily mix and match participant types to create simple or complex workflow routing policies. You can also extend the functionality of a previously configured human task to model more complex workflows.

A participant type is grouped in a block under a stage (for example, named Stage1 in Figure 29-16). A stage is a way of organizing the approval process for blocks of participant types. You can have one or more stages in sequence or in parallel. Within each stage, you can have one or more participant type blocks in sequence or in parallel. The up and down keys enable you to rearrange the order of your participant type blocks.

For example:

You can create all participant type blocks in a single stage (for example, a purchase order request in which the entire contents of the order are approved or rejected as a whole).

You can create more complex approval tasks that may include one or more stages. For example, you can place one group of participant type blocks in one stage and another block in a second stage. The list of approvers in the first stage handles line entry approvals and the list of approvers in the second stage handles header entry approvals.

Each of the participant types has an associated editor that you use for configuration tasks. The sequence in which the assignees are added indicates the execution sequence.

To specify a different stage name or have a business requirement that requires you to create additional stages, perform the following steps. Creating additional stages is an advanced requirement that may not be necessary for your environment.

Select the second stage on the right, and click the Add icon. If you do not select the second stage (for this example, named Stage1 in Figure 29-20) and instead select only the participant type block (for example, named Edit Participant in Figure 29-20), all options under the Add icon are disabled.

To be dynamically assigned to a task, a single participant can be selected from a group, an application role, or a participant list.

To configure the single participant type:

In the Label field, enter a recognizable label for this participant. This label must be unique among all the participants in the task definition (for example, Approval Manager, Primary Reviewers, and so on).

Instructions for configuring the following subsections of the Edit Participant Type dialog for the single participant type are listed in Table 29-7:

29.4.3.1 Creating a Single Task Participant List

Users assigned to a participant list can act upon tasks. In a single-task participant list, only one user is required to act on the task. You can specify either a single user or a list of users, groups, or application roles for this pattern. If a list is specified, then all users on the list are assigned the task. You can specify either that one of them must manually claim and act upon the task, or that one user from the list is automatically selected by an assignment pattern. When one user acts on the task, the task is withdrawn from the task list of other assignees.

You can create several types of lists for the single user participant, and for the parallel, serial, and FYI user participants, for example:

Value-based name and expression lists

These lists enable you to statically or dynamically select users, groups, or application roles as task assignees.

Value-based management chain lists

Management chains are typically used for serial approvals through multiple users in a management chain hierarchy. Therefore, this list is most likely useful with the serial participant type. This is typically the case if you want all users in the hierarchy to act upon the task. Management chains can also be used with the single participant type. In this case, however, all users in the hierarchy get the task assigned at the same time. As soon as one user acts on the task, it is withdrawn from the other users.

For example, a purchase order is assigned to a manager. If the manager approves the order, it is assigned to their manager. If that manager approves it, it is assigned to their manager, and so on until three managers approve the order. If any managers reject the request or the request expires, the order is rejected if you specify an abrupt termination condition. Otherwise, the task flow continues to be routed.

Rule-based names and expression lists and management chain lists

Business rules enable you to create the list of task participants with complex expressions. For example, you create a business rule in which a purchase order request below $5000 is sent to a manager for approval. However, if the purchase order request exceeds $5000, the request is sent to the manager of the manager for approval. Two key features of business rules are facts and action types, which are described in Section 29.5.2, "How to Specify Advanced Task Routing Using Business Rules."

When you select a participant type, a dialog box enables you to choose an option for building your list of task participant assignees (users, groups, or application roles), as shown in Figure 29-24. The three selections described above are available: Names and expressions, Management Chain, and Rule-based.

To create participant lists consisting of value-based names and expressions:

From the Build a list of participants using list, select Names and expressions.

Do either of the following:

Select Let participants manually claim the task. If you select this option, then the task is assigned to all participants in the list. An individual user from the task assignees can then manually claim the task to work on it.

Select Auto-assign to a single list, select User, Group, or Application Role, then select an assignment pattern.

To find out more about each assignment pattern, and to select and configure it, click Assignment Pattern. The Assignment Pattern dialog box appears. Figure 29-26 shows an example of an Assignment Pattern dialog box.

When you specify an application server connection in the Application Server field, the assignment patterns are loaded into the Assignment Pattern list. When you select one of the patterns from the Assignment Pattern list, a description of your selection appears in the text box.

If you want the assignment pattern to consider all types of tasks, then select Use tasks of all types to evaluate pattern criteria. Otherwise, the pattern considers only this task type when determining the selected user. For example, to assign a vacation request task to the least busy user, and you select Use tasks of all types to evaluate pattern criteria, then all assigned tasks are taken into consideration when determining the least busy user. If you do not select Use tasks of all types to evaluate pattern criteria, then only assigned vacation request tasks are considered when determining the least busy user.

A particular pattern may enable you to specify input parameters that control how the pattern is evaluated. For example, as shown in Figure 29-26, the Most Productive pattern enables you to specify the Time Period (in days) over which the productivity is calculated. Input values can be static, or can be dynamically set by using an XPath expression. Not all patterns accept parameters.

To change your selection in the Identification Type column, click it to invoke a dropdown list.

In the Data Type column, click your selection to invoke a dropdown list to assign a value:

By Name: If your identification type is a user or group, click the Browse icon (the dots) on the right to display a dialog for selecting a user or group configured through the identity service. The identity service enables the lookup of user properties, roles, and group memberships. User information is obtained from an LDAP server such as Oracle Internet Directory. You can use wild cards (*) to search for IDs.

If your selection is an application role, click the Browse icon to display the Select an Application Role dialog for selecting an application role. To search for application roles, you must first create a connection to the application server. When searching, you must specify the application name to find the name of the role. The task definition can refer to only one application name. You cannot use application roles from different applications as assignees or task owners.

By Expression: For a user, group, or application role, click the Browse icon to dynamically select a task assignee in the Expression Builder dialog. Use the bpws:getVariableData(...) expression or the ids:getManager() XPath function.

The Value column displays the value you specified.

To manually enter a value, click the field in the Value column and specify a value.

From the Build a list of participants using list, select Management Chain.

Do either of the following:

Select Let participants manually claim the task. If you select this option, then the task is assigned to all participants in the list. An individual user from the task assignees can then manually claim the task to work on it.

Select Auto-assign to a single list, select User, then select an assignment pattern.

To find out more about each assignment pattern, and to select and configure it, click Assignment Pattern. The Assignment Pattern dialog box appears. Figure 29-26 shows an example of an Assignment Pattern dialog box.

When you specify an application server connection in the Application Server field, the assignment patterns are loaded into the Assignment Pattern list. When you select one of the patterns from the Assignment Pattern list, a description of your selection appears in the text box.

If you want the assignment pattern to consider all types of tasks, then select Use tasks of all types to evaluate pattern criteria. Otherwise, the pattern considers only this task type when determining the selected user. For example, to assign a vacation request task to the least busy user, and you select Use tasks of all types to evaluate pattern criteria, then all assigned tasks are taken into consideration when determining the least busy user. If you do not select Use tasks of all types to evaluate pattern criteria, then only assigned vacation request tasks are considered when determining the least busy user.

A particular pattern may enable you to specify input parameters that control how the pattern is evaluated. For example, as shown in Figure 29-26, the Most Productive pattern enables you to specify the Time Period (in days) over which the productivity is calculated. Input values can be static, or can be dynamically set by using an XPath expression. Not all patterns accept parameters.

In the Top Participant list, select a method for assigning the number of task participant levels:

By Title: Select the title of the last (highest) approver in the management chain.

XPath: Select to dynamically enter a top participant through the Expression Builder dialog.

In the Number of Levels list, select a method for assigning a top participant:

By Number: Enter a value for the number of levels in the management chain to include in this task. For example, if you enter 2 and the task is initially assigned to user jcooper, both the user jstein (manager of jcooper) and the user wfaulk (manager of jstein) are included in the list (apart from jcooper, the initial assignee).

XPath: Select to dynamically enter a value through the Expression Builder dialog.

29.4.3.1.3 Creating Participant Lists Consisting of Rulesets

A ruleset provides a unit of execution for rules and for decision tables. In addition, rulesets provide a unit of sharing for rules; rules belong to a ruleset. Multiple rulesets can be executed in order. This is called rule flow. The ruleset stack determines the order. The order can be manipulated by rule actions that push and pop rulesets on the stack. In rulesets, the priority of rules applies to specify the order of firing of rules in the ruleset. Rulesets also provide an effective date specification that identifies that the ruleset is always active, or that the ruleset is restricted based on a time and date range, or a starting or ending time and date.

The method by which you create a ruleset is based on how you access it. This is described in the following section.

To specify participant lists based on rulesets:

Business rules can define the participant list. There are two options for using business rules:

Rules define parameters of a specific list builder (such as Names and Expressions or Management Chain). In this case, the task routing pattern is modeled to use a specific list builder. In the list builder, the parameters are listed as coming from rules. Rules return the list builder of the same type as the one modeled in Oracle JDeveloper.

From the Build a list of participants using list, select Names and expressions or Management Chain.

Select Let participants manually claim the task. If you select this option, then the task is assigned to all participants in the list. An individual user from the task assignees can then manually claim the task to work on it.

Select Auto-assign to a single list, select User, Group, or Application Role, then select an assignment pattern.

To find out more about each assignment pattern, and to select and configure it, click Assignment Pattern. The Assignment Pattern dialog box appears. Figure 29-26 shows an example of an Assignment Pattern dialog box.

When you specify an application server connection in the Application Server field, the assignment patterns are loaded into the Assignment Pattern list. When you select one of the patterns from the Assignment Pattern list, a description of your selection appears in the text box.

If you want the assignment pattern to consider all types of tasks, then select Use tasks of all types to evaluate pattern criteria. Otherwise, the pattern considers only this task type when determining the selected user. For example, to assign a vacation request task to the least busy user, and you select Use tasks of all types to evaluate pattern criteria, then all assigned tasks are taken into consideration when determining the least busy user. If you do not select Use tasks of all types to evaluate pattern criteria, then only assigned vacation request tasks are considered when determining the least busy user.

A particular pattern may enable you to specify input parameters that control how the pattern is evaluated. For example, as shown in Figure 29-26, the Most Productive pattern enables you to specify the Time Period (in days) over which the productivity is calculated. Input values can be static, or can be dynamically set by using an XPath expression. Not all patterns accept parameters.

Click OK.

Rules define the list builder and the list builder parameters. In this case, the list itself is built using rules. The rules define the list builder and the parameters.

Select Let participants manually claim the task. If you select this option, then the task is assigned to all participants in the list. An individual user from the task assignees can then manually claim the task to work on it.

Select Auto-assign to a single list, select User, Group, or Application Role, then select an assignment pattern.

To find out more about each assignment pattern, and to select and configure it, click Assignment Pattern. The Assignment Pattern dialog box appears. Figure 29-26 shows an example of an Assignment Pattern dialog box.

When you specify an application server connection in the Application Server field, the assignment patterns are loaded into the Assignment Pattern list. When you select one of the patterns from the Assignment Pattern list, a description of your selection appears in the text box.

If you want the assignment pattern to consider all types of tasks, then select Use tasks of all types to evaluate pattern criteria. Otherwise, the pattern considers only this task type when determining the selected user. For example, to assign a vacation request task to the least busy user, and you select Use tasks of all types to evaluate pattern criteria, then all assigned tasks are taken into consideration when determining the least busy user. If you do not select Use tasks of all types to evaluate pattern criteria, then only assigned vacation request tasks are considered when determining the least busy user.

Click OK.

Both options create a rule dictionary, if one is not already created, and preseed several rule functions and facts for easy specifications of the participant list. In the rule dictionary, the following rule functions are seeded to create participant lists:

CreateResourceList

CreateManagementChainList

The Task fact is asserted by the task service for basing rule conditions.

After the rule dictionary is created, the Oracle Business Rules Designer is displayed.

Model your rule conditions. In the action part, call one of the above functions to complete building your lists. Figure 29-31 provides details.

The parameters for the rule functions are similar to the ones in Oracle JDeveloper modeling. In addition to the configurations in Oracle JDeveloper, some additional options are available in the Oracle Business Rules Designer for the following attributes:

responseType: If the response type is REQUIRED, the assignee must act on the task. Otherwise, the assignment is converted to an FYI assignment.

ruleName: The rule name can create reasons for assignments.

lists: This object is a holder for the lists that are built. Clicking this option shows a pre-asserted fact Lists object to use as the parameter.

An example of rules specifying management chain-based participants is shown in Figure 29-32.

If multiple rules are fired, the list builder created by the rule with the highest priority is selected.

29.4.3.2 Specifying a Time Limit for Acting on a Task

You can specify the amount of time a user, group, or application role receives to act on a task. If the user, group, or role does not act in the time specified, the global escalation and renewal policies that you set in the Deadlines section (known as the routing slip level) of the Human Task Editor are applied. For example, if the global policy is set to escalate the task and this participant does not act in the duration provided, the task is escalated to the manager or another user, as appropriate.

To specify a time limit for acting on a task:

Expand the Advanced section of the Edit Participant Type dialog for the single type, as shown in Figure 29-33.

29.4.3.3 Inviting Additional Participants to a Task

You can allow a task assignee to invite other participants into the workflow before routing it to the next assignee in this workflow. For example, assume the approval workflow goes from James Cooper to John Steinbeck. If this option is checked, James Cooper can decide to first route it to Irving Stone before it goes to John Steinbeck.

This is also known as ad hoc routing. If this option is selected, Adhoc Route is added to the Actions list in Oracle BPM Worklist at runtime.

To invite additional participants to a task:

Expand the Advanced section of the Edit Participant Type dialog for the single type, as shown in Figure 29-33.

Select Allow this participant to invite other participants.

29.4.3.4 Bypassing a Task Participant

You can bypass a task participant (user, group, or application role) if a specific condition is satisfied. For example, if a user submits a business trip expense report that is under a specific amount, no approval is required by their manager.

To bypass a task:

Expand the Advanced section of the Edit Participant Type dialog for the single type, as shown in Figure 29-33.

Select Specify skip rule.

This action displays an icon for accessing the Expression Builder dialog for building a condition.

The expression to bypass a task participant must evaluate to a boolean value. For example, /task:task/task:payload/order:orderAmount < 1000 is a valid XPath expression for skipping a participant.

29.4.4 How to Configure the Parallel Participant Type

This participant type is used when multiple users, working in parallel, must act simultaneously, such as in a hiring situation when multiple users vote to hire or reject an applicant. You specify the voting percentage that is needed for the outcome to take effect, such as a majority vote or a unanimous vote.

For example, a business process collects the feedback from all interviewers in the hiring process, consolidates it, and assigns a hire or reject request to each of the interviewers. At the end, the candidate is hired if the majority of interviewers vote for hiring instead of rejecting.

In the Label field, enter a recognizable label for this participant. This label must be unique among all the participants in the task definition (for example, Approval Manager, Primary Reviewers, and so on).

Instructions for configuring the following subsections of the Edit Participant Type dialog for the parallel participant type are listed in Table 29-8:

29.4.4.1 Specifying the Voting Outcome

You can specify a voted-upon outcome that overrides the default outcome selected in the Default Outcome list. This outcome takes effect if the required percentage is reached. Outcomes are evaluated in the order listed in the table.

To specify group voting details:

Go to the Vote Outcome section of the Edit Participant Type dialog for the parallel type.

The Any outcome enables you to determine the outcome dynamically at runtime. For example, if you select Any and set the outcome percentage to 60, then at runtime, whichever outcome reaches 60% becomes the final voted outcome. If 60% of assignees vote to reject the outcome, then it is rejected.

From the list in the Outcome Type column, select a method for determining the outcome of the final task.

By Expression: Dynamically specify the details with an XPath expression.

By Percentage: Specify a percentage value that determines when the outcome of this task takes effect.

From the list in the Value column, specify a value based on your selection in Step 3.

If you selected By Expression, click the Browse icon to the right of the field to display the Expression Builder dialog for creating an expression.

If you selected By Percentage, enter a percentage value required for the outcome of this task to take effect (for example, a majority vote (51) or a unanimous vote (100)). For example, assume there are two possible outcomes (ACCEPT and REJECT) and five subtasks. If two subtasks are accepted and three are rejected, and the required acceptance percentage is 50%, the outcome of the task is rejected. Figure 29-36 provides details.

This functionality is nondeterministic. For example, selecting a percentage of 30% when there are two subtasks does not make sense.

In the Default Outcome list, select the default outcome or enter an XPath expression for this task to take effect if the consensus percentage value is not satisfied. This happens if there is a tie or if all participants do not respond before the task expires. Seeded and custom outcomes that you entered in the Outcomes dialog in Section 29.2.4, "How to Specify a Task Outcome" display in this list.

Specify additional group voting details:

Immediately trigger voted outcome when minimum percentage is met

If selected, the outcome of the task can be computed early with the outcomes of the completed subtasks, enabling the pending subtasks to be withdrawn. For example, assume four users are assigned to act on a task, the default outcome is APPROVE, and the consensus percentage is set at 50. If the first two users approve the task, the third and fourth users do not need to act on the task, since the consensus percentage value has been satisfied.

Wait until all votes are in before triggering outcome

If selected, the workflow waits for all responses before an outcome is initiated.

To share comments and attachments with all group collaborators or workflow participants for a task, select Share attachments and comments. This information typically displays in the footer region of Oracle BPM Worklist.

29.4.4.2 Creating a Parallel Task Participant List

Users assigned to the list of participants can act upon tasks. You can create several types of lists:

29.4.4.3 Specifying a Time Limit for Acting on a Task

You can specify the amount of time a user, group, or application role receives to act on a task. If the user, group, or role does not act in the time specified, the global escalation and renewal policies that you set in the Deadlines section (known as the routing slip level) of the Human Task Editor are applied. For example, if the global policy is set to escalate the task and this participant does not act in the duration provided, the task is escalated to the manager or another user, as appropriate.

To specify a time limit for acting on a task:

In the Advanced section of the Edit Participant Type dialog for the parallel type, click the Advanced icon to expand the section shown in Figure 29-35.

29.4.4.4 Inviting Additional Participants to a Task

You can allow a task assignee to invite other participants into the workflow before routing it to the next assignee in this workflow. For example, assume the approval workflow goes from James Cooper to John Steinbeck. If this option is checked, James Cooper can decide to first route it to Irving Stone before it goes to John Steinbeck.

To invite additional participants to a task:

In the Advanced section of the Edit Participant Type dialog for the parallel type, click the Advanced icon to expand the section (if not expanded).

Select Allow this participant to invite other participants.

29.4.4.5 Bypassing a Task Participant

You can bypass a task participant (user, group, or application role) if a specific condition is satisfied. For example, if a user submits a business trip expense report that is under a specific amount, no approval is required by their manager.

To bypass a task participant:

In the Edit Participant Type dialog for the parallel type, select the Specify skip rule checkbox.

This action displays an icon for accessing the Expression Builder dialog for building a condition. The expression must evaluate to a boolean value.

29.4.5 How to Configure the Serial Participant Type

This participant type enables you to create a list of sequential participants for a workflow. For example, if you want a document to be reviewed by John, Mary, and Scott in sequence, use this participant type. For the serial participant type, they can be any list of users or groups.

In the Label field, enter a recognizable label for this participant. This label must be unique among all the participants in the task definition (for example, Approval Manager, Primary Reviewers, and so on).

Instructions for configuring the following subsections of the Edit Participant Type dialog for the serial participant type are listed in Table 29-9.

29.4.5.2 Specifying a Time Limit for Acting on a Task

You can specify the amount of time a user, group, or application role receives to act on a task. If the user, group, or role does not act in the time specified, the global escalation and renewal policies that you set in the Deadlines section (known as the routing slip level) of the Human Task Editor are applied. For example, if the global policy is set to escalate the task and this participant does not act in the duration provided, the task is escalated to the manager or another user, as appropriate.

To specify a time limit for acting on a task:

In the Advanced section of the Edit Participant Type dialog for the serial type, click the Advanced icon to expand the section shown in Figure 29-37.

29.4.5.3 Inviting Additional Participants to a Task

You can allow a task assignee to invite other participants into the workflow before routing it to the next assignee in this workflow. For example, assume the approval workflow goes from James Cooper to John Steinbeck. If this option is checked, James Cooper can decide to first route it to Irving Stone before it goes to John Steinbeck.

To invite additional participants to a task:

In the Advanced section of the Edit Participant Type dialog for the serial type, click the Advanced icon to expand the section (if not already expanded).

Select Allow this participant to invite other participants.

Note:

For the serial participant type, additional participants can be invited as follows:

Globally specifying that the ad hoc participants can be invited at anytime. In this case, even in a sequential workflow, approvers can invite other participants at any level in the sequential workflow.

Specifying that an ad hoc invitation of other participants can be done only in specific points in the workflow. In this case, other ad hoc participants are invited only when a serial in complete.

29.4.5.4 Bypassing a Task Participant

You can bypass a task participant (user, group, or application role) if a specific condition is satisfied. For example, if a user submits a business trip expense report that is under a specific amount, no approval is required by their manager.

To bypass a task participant:

In the Advanced section of the Edit Participant Type dialog for the serial type, select the Specify skip rule checkbox.

This action displays an icon for accessing the Expression Builder dialog for building a condition. The expression must evaluate to a boolean value.

29.4.6 How to Configure the FYI Participant Type

Figure 29-39 displays the Edit Participant Type dialog for the FYI type. This dialog also includes a Participants Exclusion List at the bottom that is not displayed in Figure 29-39.

This participant type is used when a task is sent to a user, but the business process does not wait for a user response; it just continues. FYIs cannot directly impact the outcome of a task, but in some cases can provide comments or add attachments.

For example, a magazine subscription is due for renewal. If the user does not cancel the current subscription before the expiration date, the subscription is renewed. This user is reminded weekly until the request expires or the user acts on it.

In the Label field, enter a recognizable label for this participant. This label must be unique among all the participants in the task definition (for example, Approval Manager, Primary Reviewers, and so on).

29.4.6.1 Creating an FYI Task Participant List

Users assigned to the list of participants can act upon tasks. You can create several types of lists:

A task must be routed to each of the participants in the order in which they appear. This is predetermined, default routing. For example, in a hiring process, if three users interview and provide review feedback, then the task is sent to the human resources department.

A participant in a task can accept or reject it, thus ending the workflow without the task being sent to any other participant. For example, a manager rejects a purchase order, meaning that purchase order is not sent to their manager for review.

The participants to whom the task is routed are determined by the business rule logic that you model. For example, a loan application task is designed to go through a loan agent, their manager, and then the senior manager. If the loan agent approves the loan, but their manager rejects it, the task is returned to the loan agent.

29.5.1 How to Route Tasks to All Participants in the Specified Order

You can select to have a task reviewed by all selected participants. This is known as default routing because the task is routed to each of the participants in the order in which they appear. This type of routing differs from state machine-based routing.

To route tasks to all participants in the specified order:

In the Assignment section, click the icon to the right of Task will go from starting to final participant.

Select Route task to all participants, in order specified from the list shown in Figure 29-42.

29.5.1.1 Allowing All Participants to Invite Other Participants

This checkbox is the equivalent of the ad hoc workflow pattern of pre-10.1.3 Oracle BPEL Process Manager releases. This applies when there is at least one participant. In this case, each user selects users or groups as the next assignee when approving the task.

To allow all participants to invite other participants:

In the Assignment section, click the icon to the right of Task will go from starting to final participant.

Select Route task to all participants, in order specified.

Select the Allow all participants to invite other participants checkbox for this task assignee to invite other participants into the workflow before routing it to the next assignee in this workflow.

29.5.1.2 Stopping Routing of a Task to Further Participants

You can specify conditions under which to complete a task early, regardless of the other participants in the workflow.

For example, assume an expense report goes to the manager, and then the director. If the first participant (manager) rejects it, you can end the workflow without sending it to the next participant (director).

To abruptly complete a condition:

In the Assignment section, click the icon to the right of Task will go from starting to final participant.

Select Route task to all participants, in order specified from the list.

Select the Complete task when a participant chooses: <outcome> checkbox.

The Abrupt Completion Details dialog appears.

There are two methods for specifying the abrupt completion of a task:

Outcomes

XPath expression routing condition

If outcomes are specified, any time the selected task outcome occurs, the task completes. If both outcome and routing condition are specified, the workflow service performs a logical OR operation on the two.

Select appropriate outcomes and click the > button, as shown in Figure 29-43. To select all, click the >> button.

To the right of the Routing Condition field, click the icon to display the Expression Builder dialog for dynamically creating a condition under which to complete this task early. For example, if a user submits a business trip expense report that is under a specific amount, no approval is required by their manager.

An early completion XPath expression is not evaluated until at least one user has acted upon the task.

You can click the icon to the right of the Complete task when a participant chooses: <outcome> checkbox to edit this information.

29.5.1.3 Enabling Early Completion in Parallel Subtasks

You can use this option in the following environments:

Multiple stages and groups of participants perform subtasks in parallel.

A participant in one group approves or rejects a subtask, which causes the other participants in that same group to stop acting upon the task. However, this does not cause the other parallel group to stop acting upon subtasks. That group continues taking actions on tasks.

For example, assume there are two parallel subgroups, each in separate stages. One group acts upon lines of a purchase order. The other group acts upon headers of the same purchase order. If participant ApproveLines.Participant2 of the first group rejects a line, all other task participants in the first group stop acting upon tasks. However, the second parallel group continues to act upon headers in the purchase order. In this scenario, the entire task does not complete early. Figure 29-44 provides details.

29.5.1.4 Completing Parent Subtasks of Early Completing Subtasks

You can use this option in the following environments:

Multiple stages and groups of participants perform subtasks in parallel.

A participant in one group approves or rejects a subtask, which causes the other participants in that same group to stop acting upon the task. This also causes the other parallel group to stop acting upon subtasks.

For example, assume there are two parallel subgroups, each in separate stages, as shown in Figure 29-44. One group acts upon lines of a purchase order. The other group acts upon headers of the same purchase order. If participant ApproveLines.Participant2 of the first group rejects a line, all other task participants in the first group stop acting upon tasks. In addition, the second parallel group stops acting upon headers in the purchase order. In this scenario, the entire task completes early.

29.5.2 How to Specify Advanced Task Routing Using Business Rules

Use advanced routing rules to create complex workflow routing scenarios. The participant types (single, parallel, serial, and FYI) are used to create a linear flow from one set of users to another with basic conditions such as abrupt termination, skipping assignees, and so on. However, there is often a need to perform more complex back and forth routing between multiple individuals in a workflow. One option is to use the BPEL process as the orchestrator of these tasks. Another option is to specify it declaratively using business rules. This section describes how you can model such complex interactions by using business rules with the Human Task Editor.

29.5.2.1 Introduction to Advanced Task Routing Using Business Rules

You can define state machine routing rules using Oracle Business Rules. This action enables you to create Oracle Business Rules that are evaluated:

Using Oracle Business Rules, you define a set of rules (called a ruleset) that relies on business objects, called facts, to determine which action to take.

29.5.2.2 Facts

A fact is an object with certain business data. Each time a routing slip assignee sets the outcome of a task, instead of automatically routing the task to the next assignee, the task service performs the following steps:

Asserts facts into the decision service

Executes the advanced routing ruleset

Rules can test values in the asserted facts and specify the routing behavior by setting values in a TaskAction fact type.

This fact contains the current state of the workflow task instance. All task attributes can be tested against it. The task fact also contains the current task payload. This fact enables you to construct tests against payload values and task attribute values.

PreviousOutcome

This fact describes the previous task outcome and the assignee who set the outcome. The previous outcome fact contains the following attributes:

actualParticipant: The name of the participant who set the task outcome (for example, jstein)

logicalParticipant: The logical name (or label) for the routing slip participant responsible for setting the task outcome (for example, assignee1)

outcome: The outcome that was set (for example, approve or reject)

level: If the previous participant was part of a management chain, then this attribute records their level in the chain, where 1 is the first level in the chain. For other participant types, the value is -1.

totalNumberOfApprovals: The total number of users that have now set the outcome of the task.

TaskAction

This fact is not intended for writing rule tests against it. Instead, it is updated by the ruleset, and returned to the task service to indicate how the task should be routed. Rules should not directly update the TaskAction fact. Instead, they should call one of the RL functions described in Section 29.5.2.3, "Action Types." These functions handle updating the TaskAction fact with the appropriate values.

Some fact types can only be used in workflow routing rules, while others can only be used in workflow participant rules. Table 29-12 describes where you can use each type.

Table 29-12 Use of Fact Types

Fact Type

Can Use in Routing Rules?

Can Use in Participant Rules?

Task

Yes

Yes

PreviousOutcome

Yes

No

TaskAction

Yes

No

Lists

No

Yes

RoutingSlipObjectFactory

No

Yes

ResourceListType

No

Yes

ManagementChainListType

No

Yes

ResourceType

No

Yes

ParameterType

No

Yes

AutoActionType

No

Yes

ResponseType

No

Yes

29.5.2.3 Action Types

To instruct the task service on how to route the task, rules can specify one of many task actions. This is done by updating the TaskAction fact asserted into the rule session. However, rules should not directly update the TaskAction fact. Instead, rules should call one of the action RL functions, passing the TaskAction fact as a parameter. These functions handle the actual updates to the fact. For example, to specify an action of go forward, you must add a callGO_FORWARD(TaskAction) to the action part of the rule.

Each time a state machine routing rule is evaluated, the rule takes one of the actions shown in Table 29-13:

Table 29-13 Business Rule Actions

Action

Description

Parameters

GO_FORWARD

Goes to the next participant in the routing slip (default behavior).

None

PUSHBACK

Goes back to the previous participant in the routing slip (the participant before the one that just set the task outcome).

None

GOTO

Goes to a specific participant in the routing slip.

participant'

A string that identifies the label of the participant (for example, Approver1) to which to route the task.

COMPLETE

Finishes routing and completes the task. The task is marked as completed, and no further routing is required.

None

ESCALATE

Escalates and reassigns the task according to the task escalation policy (usually to the manager of the current assignee).

None

29.5.2.4 Sample Ruleset

This section describes how to use rules to implement custom routing behavior with a simple example. A human workflow task is created for managing approvals of expense requests. The outcomes for the task are approve and reject. The task definition includes an ExpenseRequest payload element. One of the fields of ExpenseRequest is the total amount of the expense request. The routing slip for the task consists of three single participants (assignee1, assignee2, and assignee3).

By default, the task gets routed to each of the assignees, with each assignee choosing to approve or reject the task.

Instead of this behavior, the necessary routing behavior is as follows:

If the total amount of the expense request is less than $100, approval is only required from one of the participants. Otherwise, it must be approved by all three.

If an expense request is rejected by any of the participants, it must be returned to the previous participant for re-evaluation. If it is rejected by the first participant, the expense request is rejected and marked as completed.

This behavior is implemented using the following rules. When a rule dictionary is generated for advanced routing rules, it is created with a template rule that implements the default GO_FORWARD behavior. You can edit this rule, and make copies of the template rule by right-clicking and selecting Copy Rule in the Oracle Business Rules Designer.

If the amount is greater than $100 and the previous assignee approved the task, it is not necessary to provide a rule for routing a task to each of the assignees in turn. This is the default behavior that is reverted to if none of the rules in the ruleset are triggered:

For information about iterative design, see the workflow-106-IterativeDesign sample available with the Oracle SOA Suite samples.

29.5.2.5 Linked Dictionary Support

For human workflow, business rule artifacts are now stored in two rules dictionaries. This is useful for scenarios in which you must customize your applications. For example, you create and ship version 1 of an application to a customer. The customer then customizes the rulesets in the application with Oracle SOA Composer. Those customizations are now stored in a different rules dictionary than the base rules dictionary. The rules dictionary that stores the customized rulesets links with the rules in the base dictionary. When you later ship version 2 of the application, the base rule dictionary may contain additional changes introduced in the product. The ruleset customization changes previously performed by the customer are preserved and available with the new changes in the base dictionary. When an existing application containing a task using rules is opened, if the rules are in the old format using one dictionary, they are automatically upgraded and divided into two rules dictionaries:

Base dictionary

Custom dictionary

For more information about customizations, see

29.5.2.6 Creating Advanced Routing Rules

To create advanced routing rules:

In the Assignment section, click the icon to the right of Task will go from starting to final participant.

Select Use Advanced Rules from the list.

To the right of Rules Dictionary, click the Edit icon, as shown in Figure 29-48.

This starts the Oracle Business Rules Designer with a preseeded repository containing all necessary fact definitions, as shown in Figure 29-49. A decision service component is created for the dictionary, and is associated with the task service component.

29.5.3 How to Use External Routing

You configure an external routing service that dynamically determines the participants in the workflow. If this routing policy is specified, all other participant types are ignored. It is assumed that the external routing service provides a list of participant types (single approver, serial approver, parallel approver, and so on) at runtime to determine the routing of the task.

Use this option if you do not want to use any of the routing rules to determine task assignees. In this case, all the logic of task assignment is delegated to the external routing service.

Note:

If you select Use External Routing in the Configure Assignment dialog, specify a Java class, and click OK to exit, the next time you open this dialog, the other two selections (Route task to all participants, in order specified and Use Advanced Rules) no longer appear in the dropdown list. To access all three selections again, you must delete the entire assignment.

To use external routing

In the Assignment section, click the icon to the right of Task will go from starting to final participant.

In the Class Name field, enter the fully qualified class file name (for example, the org.mycompany.tasks.RoutingService class name). This class must implement the following interface:

oracle.bpel.services.workflow.task.IAssignmentService

Add name and pair value parameters by name or XPath expression that can be passed to the external service, as shown in Table 29-14.

Table 29-14 External Routing

Field

Description

By Name

Enter a name in the Name field and a value in the Value field.

By Expression

Enter a name and dynamically enter a value by clicking the icon to the right of the field to display the Expression Builder dialog.

Click the Add icon to add additional name and pair value parameters.

29.5.4 How to Configure the Error Assignee

Tasks can error for reasons such as incorrect assignments. When such errors occur, the task is assigned to the error assignee, who can perform corrective actions. Recoverable errors are as follows:

Invalid user and group for all participants

Invalid XPath expressions that are related to assignees and expiration duration

Escalation on expiration errors

Evaluating escalation policy

Evaluating renewal policy

Computing a management chain

Evaluating dynamic assignment rules. The task is not currently in error, but is still left as assigned to the current user and is therefore recoverable.

Dynamic assignment cyclic assignment (for example, user A > user B > user A). The task is not currently in error, but is still left as assigned to the last user in the chain and is therefore recoverable.

The following errors are not recoverable. In these cases, the task is moved to the terminating state ERRORED.

During modeling of workflow tasks, you can specify error assignees for the workflow. If error assignees are specified, they are evaluated and the task is assigned to them. If no error assignee is specified at runtime, an administration user is discovered and is assigned the alerted task. The error assignee can perform one of the following actions:

Ad hoc route

Route the task to the actual users assigned to the task. Ad hoc routing allows the task to be routed to users in sequence, parallel, and so on.

Reassign

Reassign the task to the actual users assigned to this task

Error task

Indicate that this task cannot be rectified.

If there are any errors in evaluating the error assignees, the task is marked as being in error.

This dialog enables you to specify the users or groups to whom the task is assigned if an error in assignment has occurred.

To configure the error assignee:

In the Assignment section, click the icon to the right of Task will go from starting to final participant.

Click the Assignment tab.

Click the Add icon to assign reviewers or error assignees, as shown in Figure 29-52.

If you are using parallel participant types, you can specify where to store the subtask payload with the following options.

Use server settings

The SharePayloadAcrossAllParallelApprovers System MBean Browser boolean property in Oracle Enterprise Manager Fusion Middleware Control determines whether to share the payload of subtasks in the root task. By default, this property is set to true. If set to true, the All task participants share the same payload (better performance and less storage space) option is used. If this property is set to false, the Each parallel participant has a local copy of the payload option is used. To change this property, perform the following steps:

All task participants share the same payload (better performance and less storage space)

The payload for the subtasks is stored in their root task. This situation means that the payload of the root task is shared across all its subtasks. Internally, this option provides better performance and storage space consumption. Less storage space is consumed because the payload of the root task is shared across all its subtasks.

Each parallel participant has a local copy of the payload

Each subtask has its own copy of the payload. Internally, this option provides lesser performance and storage space consumption because more storage space is consumed.

29.6 Specifying Multilingual Settings and Style Sheets

The Presentation section shown in Figure 29-53 enables you to specify resource bundles for displaying task details in different languages in Oracle BPM Worklist and WordML and custom style sheets for attachments.

29.6.1 How to Specify WordML and Other Style Sheets for Attachments

In the Stylesheet for Attachments list of the Presentation section, select one of the following options:

Word ML: This option dynamically creates Microsoft Word documents for sending as email attachments using a WordML XSLT style sheet. The XSLT style sheet is applied on the task document.

Other: This option creates email attachments using an XSLT style sheet. The XSLT style sheet is applied on the task document.

Click the Search icon to select the style sheet as an attachment.

29.6.2 How to Specify Multilingual Settings

You can specify resource bundles for displaying task details in different languages in Oracle BPM Worklist. Resource bundles are supported for the following task details:

Displaying the value for task outcomes in plain text or with the message(key) format.

Making email notification messages available in different languages. At runtime, you specify the hwf:getTaskResourceBundleString(taskId, key, locale?) XPath extension function to obtain the internationalized string from the specified resource bundle. The locale of the notification recipient can be retrieved with the function hwf:getNotificationProperty(propertyName).

Resource bundles can also simply be property files. For example, a resource bundle that configures a display name for task outcomes can look as follows:

APPROVE=Approve

REJECT=Reject

To specify multilingual settings:

In the Presentation section, click the Add icon across from Resource Bundle.

In the Resource Name field, enter the name of the resource used in the resource bundle. This should be a .properties-based resource bundle file.

In the Resource Location field, click the Search icon to select the JAR or ZIP resource bundle file to use. The resource bundle is part of your system archive (SAR) file.

If the resource bundle is outside of the composite project, you are prompted to place a local copy in SCA-INF/lib.

If the resource bundle file is not in the composite class loader (directly under SCA-INF/classes or in a JAR file in SCA-INF/lib), you must specify its location. For example, if the resource bundle is accessible from a location outside of the composite class loader (for example, an HTTP location such as http://host:port/bundleApp/taskBundles.jar), then this location must be specified in this field.

Click OK to return to the Human Task Editor.

For more information, see

29.7 Escalating, Renewing, or Ending the Task

You can specify the expiration duration of a task in this global policy section (also known as the routing slip level). If the expiration duration is specified at the routing slip level instead of at the participant type level, then this duration is the expiration duration of the task across all the participants. However, if you specify expiration duration at the participant type level (through the Limit allocated duration to checkbox), then those settings take precedence over settings specified in the Deadlines section (routing slip level).

If there is no expiration specified at either the participant level or this routing slip level, then that task has no expiration duration.

If expiration duration is specified at any level of the participants, then for that participant, the participant expiration duration is used. However, the global expiration duration is still used for the participants that do not have participant level expiration duration. The global expiration duration is always decremented by the time elapsed in the task.

The policy for interpreting the participant level expiration for the participants is described as follows:

Serial

Each assignment in the management chain gets the same expiration duration as the one specified in the serial. The duration is not for all the assignments resulting from this assignment. If the task expires at any of the assignments in the management chain, the escalation and renewal policy is applied.

Parallel:

In a parallel workflow, if the parallel participants are specified as a resource, a routing slip is created for each of the resources. The expiration duration of each created routing slip follows these rules:

The expiration duration equals the expiration duration of the parallel participant if it has an expiration duration specified.

The expiration duration that is left on the task if it was specified at the routing slip level.

Otherwise, there is no expiration duration.

If parallel participants are specified as routing slips, then the expiration duration for the parallel participants is determined by the routing slip.

Note:

When the parent task expires in a parallel task, the subtasks are withdrawn if those tasks have not expired or completed.

29.7.2 How to Specify a Policy to Never Expire

You can specify for a task to never expire.

To specify a policy to never expire:

In the dropdown list in the Deadlines section, as shown in Figure 29-55, select Never Expire.

29.7.3 How to Specify a Policy to Expire

You can specify for a task to expire. When the task expires, either the escalation policy or the renewal policy at the routing slip level is applied. If neither is specified, the task expires. The expiration policy at the routing slip level is common to all the participants.

To specify for a task to expire:

In the dropdown list of the Deadlines section, select Expire after, as shown in Figure 29-57.

Specify the maximum time period for the task to remain open.

The expiration policy for parallel participants is interpreted as follows:

If parallel participants are specified as resources in parallel elements, there is no expiration policy for each of those participants.

If parallel participants are specified as routing slips, then the expiration policy for the routing slip applies to the parallel participants.

29.7.4 How to Extend an Expiration Policy Period

You can extend the expiration period when the user does not respond within the allotted time. You do this by specifying the number of times the task can be renewed upon expiration (for example, renew it an additional three times) and the duration of each renewal (for example, three days for each renewal period).

To extend an expiration policy period:

In the dropdown list of the Deadlines section, select Renew after, as shown in Figure 29-58.

Specify the maximum number of times to continue renewing this task.

In Figure 29-58, when the task expires, it is renewed at most three times. It does not matter if the task expired at the LoanAgentGroup participant or the Supervisor participant.

29.7.5 How to Escalate a Task Policy

You can escalate a task if a user does not respond within the allotted time. For example, if you are using the escalation hierarchy configured in your user directory, the task can be escalated to the user's manager. If you are using escalation callbacks, the task is escalated to whoever you have defined. When a task has been escalated the maximum number of times, it stops escalating. An escalated task can remain in a user inbox even after the task has expired.

To escalate a task policy:

In the dropdown list of the Deadlines section, select Escalate after, as shown in Figure 29-59.

Specify the following additional values. When both are set, the escalation policy is more restrictive.

Maximum Escalation Levels

Number of management levels to which to escalate the task. This field is required.

Highest Approver Title

The title of the highest approver (for example, self, manager, director, or CEO). These titles are compared against the title of the task assignee in the corresponding user repository. This field is optional.

The escalation policy specifies the number of times the task can be escalated on expiration and the renewal duration. In Figure 29-59, when the task expires, it is escalated at most three times. It does not matter if the task expired at the LoanAgentGroup participant or the Supervisor participant.

29.7.6 How to Specify Escalation Rules

This option allows a custom escalation rule to be plugged in for a particular workflow. For example, to assign the task to a current user's department manager on task expiration, you can write a custom task escalation function, register it with the workflow service, and use that function in task definitions.

The default escalation rule is to assign a task to the manager of the current user. To add a new escalation rule, follow these steps.

In the Custom Escalation Java Class field of the Deadlines section, enter the function name as defined in the Workflow Task Service Properties page for the escalation rule.

For more information, see

29.7.7 How to Specify a Due Date

A due date indicates the date by which the task should be completed. The due date is different from the expiration date. When a task expires it is either marked expired or automatically escalated or renewed based on the escalation policy. The due date is generally a date earlier than the expiration date and an indication to the user that the task is about to expire.

You can enter a due date for a task, as shown in Figure 29-55. A task is considered overdue after it is past the specified due date. This date is in addition to the expiration policy. A due date can be specified irrespective of whether an expiration policy has been specified. The due date enables Oracle BPM Worklist to display a due date, list overdue tasks, filter overdue tasks in the inbox, and so on. Overdue tasks can be queried using a predicate on the TaskQueryService.queryTask(...) API.

To specify a due date:

In the Deadlines section, select the Action Requested Before checkbox.

Select By Duration to enter a time duration or select By Expression to dynamically enter a value as an XPath expression.

Note the following details:

The due date can be set on both the task (using the Create ToDo Task dialog in Oracle BPM Worklist) and in the .task file (using the Human Task Editor). This is to allow to-do tasks without task definitions to set a due date during initiation of the task. A due date that is set in the task (a runtime object) overrides a due date that is set in the .task file.

In the task definition, the due date can only be specified at the global level, and not for each participant.

If the due date is set on the task, the due date in the .task file is ignored.

If the due date is not set on the task, the due date in the .task file is evaluated and set on the task.

If there is no due date on either the task or in the .task file, there is no due date on the task.

Note:

You cannot specify business rules for to-do tasks.

For more information, see

29.8 Specifying Participant Notification Preferences

Figure 29-60 shows the General tab of the Notification section of the Human Task Editor (when fully expanded).

Notifications indicate when a user or group is assigned a task or informed that the status of the task has changed. Notifications can be sent through email, voice message, instant message, or SMS. Notifications are sent to different types of participants for different actions. Notifications are configured by default with default messages. For example, a notification message is sent to indicate that a task has completed and closed. You can create your own or modify existing configurations.

Note:

Embedded LDAP does not support group email addresses. Therefore, when a task is assigned to a group ID, emails are sent to all of its members instead of to the group email address.

29.8.1 How to Notify Recipients of Changes to Task Status

Three default status types display in the Task Status column: Assign, Complete, and Error. You can select other status types for which to receive notification messages.

To notify recipients of changes to task status:

In the Notification section, click the General tab.

In the Task Status column, click a type to display the complete list of task types:

Alerted

When a task is in an alerted state, you can notify recipients. However, none of the notification recipients (assignees, approvers, owner, initiator, or reviewer) can move the task from an alerted state to an error state; they only receive an FYI notification of the alerted state. The owner can reassign, withdraw, delete, or purge the task, or ask the error assignee to move the task to an error state if the error cannot be resolved. Only the error assignee can move a task from an alerted state to an error state.

When the task is assigned to users or a group. This captures the following actions:

Task is assigned to a user

Task is assigned to a new user in a serial workflow

Task is renewed

Task is delegated

Task is reassigned

Task is escalated

Information for a task is submitted

Complete

Error

Expire

Request Info

Resume

Suspend

Update

Task payload is updated

Task is updated

Comments are added

Attachments are added and updated

Update Outcome

Withdraw

All Other Actions

Any action not covered in the above task types. This includes acquiring a task.

Select a task status type.

Notifications can be sent to users involved in the task in various capacities. This includes when the task is assigned to a group, each user in the group is sent a notification if there is no notification endpoint available for the group.

In the Recipient column, click an entry to display a list of possible recipients for the notification message:

Assignees

The users or groups to whom the task is currently assigned.

Initiator

The user who created the task.

Approvers

The users who have acted on the task up to this point. This applies in a serial participant type in which multiple users have approved the task and a notification must be sent to all of them.

Owner

The task owner

Reviewer

The user who can add comments and attachments to a task.

For more information, see

29.8.2 How to Edit the Notification Message

A default notification message is available for delivery to the selected recipient. If you want, you can modify the default message text.

To edit the notification message:

In the Notification section, click the General tab.

In the Notification Header column, click the Edit icon to modify the default notification message.

This message applies to all the supported notification channels: email, voice, instant messaging, and SMS. Email messages can also include the worklist task detail defined in this message. The channel by which the message is delivered is based upon the notification preferences you specify.

Modify the message wording as necessary.

Click OK to return to the Human Task Editor.

For more information about notification preference details, see

29.8.3 How to Set Up Reminders

You can send task reminders, which can be based on the time the task was assigned to a user or the expiration time of a task. The number of reminders and the interval between the reminders can also be configured.

To set up reminders:

In the Notification section, click the Advanced tab.

From the list, select the number of reminders to send.

If you selected to remind the assignee one, two, or three times, select the interval between reminders, and whether to send the reminder before or after the assignment.

For more information, see

29.8.4 How to Change the Character Set Encoding

Unicode is a universally-encoded character set that enables information from any language to be stored using a single character set. Unicode provides a unique code value for every character, regardless of the platform, program, or language. You can use the default setting of UTF-8 or you can specify a character set with a Java class.

To change the character set encoding

In the Notification section, click the Advanced tab.

From the Encoding list, select Specify by Java Class.

Enter the Java class to use.

29.8.5 How to Secure Notifications to Exclude Details

To secure notifications, make messages actionable, and send attachments:

In the Notification section, click the Advanced tab.

Select Make notifications secure (exclude details).

If selected, a default notification message is used. There are no HTML worklist task details, attachments, or actionable links in the email. Only the task number is in the message.

For more information, see

29.8.6 How to Display the Oracle BPM Worklist URL in Notifications

You can configure whether to display the Oracle BPM Worklist URL in email notification messages.

To display the Oracle BPM Worklist URL in notifications:

In the Notification section, click the Advanced tab.

Select the Show worklist URL in notifications checkbox to display the Oracle BPM Worklist URL in email notification messages. If this checkbox is not selected, the URL is not displayed.

29.8.7 How to Make Email Messages Actionable

To make email messages actionable:

In the Notification section, click the Advanced tab.

Select Make notification actionable. This action enables you to perform task actions through email.

Note:

FYI tasks are not actionable and cannot be acknowledged from email messages.

29.8.9 How to Send Email Notifications to Groups and Application Roles

You can send email notifications to groups and application roles to which tasks are assigned.

To send email notifications to groups and application roles:

In the Notification section, click the Advanced tab.

From the Group notification configuration list, select one of the following options.

Send individual emails

Each user in the group or application role receives an individual email notification. This is the default selection.

In addition, the Use separate task forms based on locale checkbox is automatically selected.

When selected, this sends individual emails with a separate task form based on the language locale.

When not selected, this sends individual emails and reuses (shares) the task form.

Send one email containing all user addresses

A shared notification email is generated once for a user locale in a group or application role, thereby saving time in notification email content generation. The email is sent to all users in the group or application role.

Notes:

Since all (or a subset of) users receive the same email, the users in the group or application role are expected to have the same privilege. This ensures that the user does not see task details to which they are not entitled.

When sending one email to all users, the maximum number of characters allowed in the address field is 2000. If the limit is exceeded, email is sent to only those user addresses contained within the maximum limit.

29.8.10 How to Customize Notification Headers

Custom notification headers are used to specify name and value pairs to identify key fields within the notification. These entries can be used by users to define delivery preferences for their notifications. For example:You can set Name to ApprovalType and value to Expense or Name to Priority and value to High.Users can then specify delivery preferences in Oracle BPM Worklist. These preferences can be based on the contents of the notification.

The rule-based notification service is only used to identify the preferred notification channel to use. The address for the preferred channel is still obtained from the identity service.

To customize notification headers:

In the Notification section, click the Advanced tab.

Expand Notification Header Attributes.

Add name and pair value parameters by name or XPath expression.

For more information about preferences, see the following sections:

29.8.11 How to Specify an E-mail Address for the Recipient of a Notification

When using the Human Task editor in a BPM Suite installation, you can specify an e-mail address for the recipient of a Notification.

To specify an e-mail address for the recipient of a notification:

Open the Human Task editor.

Click the Notification tab.

Double-click the Recipient list.

The Recipient list is an editable list, when you double click it, it becomes a text field.

Enter the recipient's e-mail address.

Optionally you can use the buttons next to the Recipient text field to look up the e-mail address in an application server or to specify the e-mail address using XPath.

Note:

When sending a notification to a recipient specified using an e-mail address, the notification service uses the user context of an assignee to obtain the task information to include in the notification.

29.9 Specifying Access Policies and Task Actions on Task Content

You can specify access rules on task content and actions to perform on that content.

29.9.1 How to Specify Access Policies on Task Content

You can specify access rules that determine the parts of a task that participants can view and update. Access rules are enforced by the workflow service by applying rules on the task object during the retrieval and update of the task.

29.9.1.1 Introduction to Access Rules

Access rules are computed based on the following details:

Any attribute configured with access rules declines any permissions for roles not configured against it. For example, assume you configure the payload to be read by assignees. This action enables only assignees and nobody else to have read permissions. No one, including assignees, has write permissions.

Any attribute not configured with access rules has all permissions.

If any payload message attribute is configured with access rules, any configurations for the payload itself are ignored due to potential conflicts. In this case, the returned map by the API does not contain any entry for the payload. Write permissions automatically provide read permissions.

If only a subset of message attributes is configured with access rules, all message attributes not involved have all permissions.

Only comments and attachments have add permissions.

Write permissions on certain attributes are meaningless. For example, write permissions on history do not grant or decline any privileges on history.

The following date attributes are configured as one in the Human Task Editor. The map returned by TaskMetadataService.getVisibilityRules() contains one key for each. Similarly, if the participant does not have read permissions on DATES, the task does not contain any of the following task attributes:

START_DATE

END_DATE

ASSIGNED_DATE

SYSTEM_END_DATE

CREATED_DATE

EXPIRATION_DATE

ALL_UPDATED_DATE

The following assignee attributes are configured as one in the Human Task Editor. The map returned by TaskMetadataService.getVisibilityRules() contains one key for each of the following. Similarly, if the participant does not have read permissions on ASSIGNEES, the task does not contain any of the following task attributes:

ASSIGNEES

ASSIGNEE_USERS

ASSIGNEE_GROUPS

ACQUIRED_BY

Mapped attributes do not have individual representation in the map returned by TaskMetadataService.getVisibilityRules().

All message attributes in the map returned by TaskMetadataService.getVisibilityRules() are prefixed by ITaskMetadataService.TASK_VISIBILITY_ATTRIBUTE_PAYLOAD_MESSAGE_ATTR_PREFIX (PAYLOAD).

An application can also create pages to display or not display task attributes based on the access rules. This can be achieved by retrieving a participant's access rules by calling the API on oracle.bpel.services.workflow.metadata.ITaskMetadataService. Example 29-1 provides details.

Assign privileges (read, write, or no access) to users to act upon task content. A user cannot be assigned a privilege above their highest level. For example, an ADMIN user cannot be assigned write access on the PAYLOAD task content. Table 29-17 shows the maximum privilege each user has on task content.

Table 29-17 Highest Privilege Levels for Users of Task Content

Task Content

Individual with Read Access

Individual with Write Access

Assignees

Admin, Approvers, Assignees, Creator, Owner, Reviewers

--

Attachments

Admin, Approvers

Assignees, Creator, Owner, Reviewers

Comments

Admin, Approvers

Assignees, Creator, Owner, Reviewers

Dates

Admin, Approvers, Assignees, Creator, Owner, Reviewers

--

Flexfields

Admin, Approvers, Reviewers

Assignees, Creator, Owner

History

Admin, Approvers, Assignees, Creator, Owner, Reviewers

--

Payload

Admin, Approvers, Reviewers

Assignees, Creator, Owner

Reviewers

Admin, Approvers, Assignees, Creator, Owner, Reviewers

--

Payload elements

Inherited from payload

Inherited from payload

For example, if you accept the default setting of ASSIGNEES, CREATOR, and OWNER with write access, ADMIN, APPROVERS, and REVIEWERS with read access, and PUBLIC with no access to the PAYLOAD task content, the dialog appears as shown in Figure 29-63.

Select the method for displaying task content in this dialog. Choosing the currently unselected option causes all settings to reset to their default values.

Coarse grained (default)

Displays the task content as a whole (for example, displays only one payload or reviewer).

Fine grained

Displays the content as individual elements (for example, displays all payloads (such as p1, p2, and p3) and all reviewers assigned to this task (such as jstein, wfaulk, and cdickens).

Note:

Access rules are always applied on top of what the system permits, depending on who is performing the action and the current state of the task.

29.9.1.3 Specifying Actions for Acting Upon Tasks

You can specify the actions (either access or no access) that specific users (such as the task creator or owner) have for acting on the task content (such as a payload) that you specified in the Configure Task Content Access dialog.

To specify actions for acting upon tasks:

Click the Access tab.

Click the Actions tab.

Select the task action for which to specify users, as shown in Figure 29-64.

29.9.2 How to Specify a Workflow Digital Signature Policy

Digital signatures provide a mechanism for the nonrepudiation of digitally-signed human tasks. This ability to mandate that a participant acting on a task signs the details and their action before the task is updated ensures that they cannot repudiate it later.

Note:

If digital signatures are enabled for a task, actionable emails are not sent during runtime. This is the case even if actionable emails are enabled during design time.

To specify a workflow digital signature policy:

Click the Access tab.

From the Signature Policy list, select Configure Policy, as shown in Figure 29-65.

Participants can send and act upon tasks without providing a signature. This is the default policy.

Password required

Participants specify a signature before sending tasks to the next participant. Participants must reenter their password while acting on a task. The password is used to generate the digital signature. A digital signature authenticates the identity of the message sender or document signer. This ensures that the original content of the sent message is unchanged.

Digital certificate required

Participants must possess a digital certificate for the nonrepudiation of digitally-signed human tasks. A digital certificate establishes the participant's credentials. It is issued by a certification authority (CA). It contains the following:

Your name

A serial number

Expiration dates

A copy of the certificate holder's public key (used for encrypting messages and digital signatures)

Digital signature of the certificate-issuing authority so that message authenticity can be established

The CA names and CA CRL and URLs of the issuing authorities must be configured separately.

Click OK.

For more information, see

29.9.2.1 Specifying a Certificate Authority

To use digital signatures, you must specify CAs you consider trustworthy in the System MBean Browser in Oracle Enterprise Manager Fusion Middleware Control. Only certificates issued from such CAs are considered valid by human workflow.

29.10 Specifying Restrictions on Task Assignments

You can restrict the users to which a task can be reassigned or routed by using a callback class.

The user community seeded in a typical LDAP directory can represent the whole company or division. However, it may be necessary at times to limit the potential list of users to associate with a task based on the scope or importance of the task or associated data. For example, in a large company with thousands of users, only a few people have the ability to approve and create purchase orders. Specifically for such tasks, the users that can be chosen for ad hoc routing and reassignment should not be the whole company. Instead, only a few users who are relevant or have the right privilege should be chosen. This can be achieved by the restricted assignment functionality. This is implemented as a callback class that can implement the logic to choose the right set of users dynamically based on the task object that is passed containing the instance data.

29.10.1 How to Specify Restrictions on Task Assignments

To specify restrictions on task assignments:

In the Access section, click Configure Restricted Assignments.

The Configure Restricted Assignment dialog appears.

Enter the class name. The class must implement the oracle.bpel.services.workflow.task.IRestrictedAssignmentCallback interface.

Click the Add icon to add name and value pairs for the property map passed to invoke the callback.

Click OK.

29.11 Specifying Java or Business Event Callbacks

You can specify Java or business event callbacks.

29.11.1 How to Specify Callback Classes on Task Status

You can register callbacks for the workflow service to call when a particular stage is reached during the lifecycle of a task. Two types of callbacks are supported:

Java callbacks: The callback class must implement the interface oracle.bpel.services.workflow.task.IRoutingSlipCallback. Make the callback class available in the class path of the server.

Business event callbacks: You can have business events raised when the state of a human task changes. You do not need to develop and register a Java class. The caller implements the callback using an Oracle Mediator service component to subscribe to the applicable business event to be informed of the current state of an approval transaction.

To specify callback classes on task status:

Click the Events tab.

The following state change callbacks are available for selection:

OnAssigned

Select if the callback class must be called on any assignment change, including standard routing, reassignment, delegation, escalation, and so on. If a callback is required when a task has an outcome update (that is, one of the approvers in a chain approves or rejects the task), this option must be selected.

OnUpdated

Select if the callback class must be called on any update (including payload, comments, attachments, priority, and so on).

OnCompleted

Select if the callback class must finally be called when the task is completed and control is about to be passed to the initiator (such as the BPEL process initiating the task).

OnStageCompleted

Select if the callback class must be called to enable business event callbacks in a human workflow task. When the event is raised, it contains the name of the completed stage, the outcome for the completed stage, and a snapshot of the task when the callback is invoked.

OnSubtaskUpdated

Select if the callback class must be called on any update (including payload, comments, attachments, priority, and so on) on a subtask (one of the tasks in a parallel-and-parallel scenario).

If your Oracle JDeveloper installation is updated to include both the BPEL and BPM extensions, then the following content callbacks are also available for selection:

Comments Callback

Select if the callback class must be called to store the comments in a schema other than the WFCOMMENT column.

Attachment Call Back

Select if the callback class must be called to store the comments in a schema other than the WFATTACHMENT column.

Validation Callback

Select if the callback class must be called to validate either the task or payload before updating, approving, and so on.

29.11.1.1 Specifying Java Callbacks

To specify Java callbacks:

In the State column of the Events section, select a task state.

In the Java Class column, click the empty field to enter a value. This value is the complete class name of the Java class that implements oracle.bpel.services.workflow.task.IRoutingSlipCallback. Figure 29-66 provides details.

29.11.1.2 Specifying Business Event Callbacks

To specify business event callbacks:

In the State column of the Events section, select a task state.

Leave the Java Class field empty.

Select the Trigger Workflow Event checkbox. This action disables the Java Class column, as shown in Figure 29-67. Each callback, such as OnAssigned, corresponds to a business event point. When a business event is fired, the event details contain the task object and a set of properties that are populated based on the context of the event being fired.

A preseeded, static event definition language (EDL) file (JDev_Home\jdeveloper\integration\seed\soa\shared\workflow\HumanTaskEvent.edl) provides the list of available business events to which to subscribe. These business events correspond to the callbacks you select in the Callback Details dialog. You must now create an Oracle Mediator service component in which you reference the EDL file and subscribe to the appropriate business event.

Note:

A file-based MDS connection is required so that the EDL file can be located. The location for the file-based MDS is JDev_Home\jdeveloper\integration\seed.

Create an Oracle Mediator service component in the same or a different SOA composite application that can subscribe to the event.

In the Template list during Oracle Mediator creation, select Subscribe to Events.

Click the Add icon to subscribe to a new event.

To the right of the Event Definition field, click the Browse icon to select the EDL file.

The SOA Resource Browser dialog appears.

Select the previously created file-based MDS connection.

From the list at the top, select Resource Palette.

Select SOA > Shared > Workflow > HumanTaskEvent.edl.

Click OK.

The Event Chooser is now populated with EDL file business events available for selection.

In the Event field, select the event to which to subscribe. Figure 29-68 provides details.

You can have multiple human tasks available for subscribing to the event. For example, assume you performed the following:

Configured a human task named TaskA to subscribe to the event (for example, OnAssigned)

Configured a human task named TaskB to subscribe to the same event

To distinguish between events for TaskA and TaskB and ensure that an event is processed only by the intended Oracle Mediator, you can add a static routing filter:

xpath20:compare(med:getComponentName(), 'TaskA')

This only invokes this routing when the sending component is TaskA.

If the EDL file was not selected from the file-based MDS connection, accept to import the dependent XSD files when prompted, and click OK. If the EDL file was selected from the file-based MDS connection, you are not prompted.

The Oracle Mediator service component is now populated with the business event to which to subscribe. You can also subscribe to other business events defined in the same EDL file now or at a later time.

See the following documentation for additional details about business events and callbacks:

29.11.2 How to Specify Task and Routing Customizations in BPEL Callbacks

In general, the BPEL process calls into the workflow component to assign tasks to users. When the workflow is complete, the human workflow service calls back into the BPEL process. However, if you want fine-grained callbacks (for example, onTaskUpdate or onTaskEscalated) to be sent to the BPEL process, you can use the Allow task and routing customization in BPEL callbacks option.

Make sure to manually refresh the BPEL diagram for this callback setting.

To specify task and routing customizations in BPEL callbacks:

In the Events section, select the Allow task and routing customization in BPEL callbacks checkbox.

Return to Oracle BPEL Designer.

Open the task activity dialog.

Click OK.

This creates the while, pick, and onMessage branch of a pick activity for BPEL callback customizations inside the task scope activity.

For more information about specifying task and routing customizations, see

29.11.3 How to Disable BPEL Callbacks

A user talk activity (in Oracle BPEL Designer) has an invoke activity followed by a receive or pick activity. Deselecting the Disable BPEL callbacks checkbox enables you to invoke the task service without waiting for a reply.

You can configure Human Tasks to store attachments in the UCM repository. These attachments may contain one or more metadata properties. You can assign values to these properties or configure them to allow the user to provide the value.

To configure Oracle UCM Repository for task attachments:

In the Project Navigator tree, expand the Business Catalog node.

Expand the Human Tasks node.

Double-click the Human Task you want to configure.

The Human Task Editor appears.

Click the Documents tab.

Select Use Document Package.

A section to configure metadata properties appears. The table already contains the mandatory standard metadata: Security Group and Document Type.

Optionally add new standard or custom metadata properties:

Click the Add button.

Click the Name column to select a standard property from the list or to enter a custom name.

Click the Value column to assign a value to the property. Select By Name to provide the text to assign the value to the property, or By Expression to provide an expression.

Click the Display column to select a display mode:

Editable: the user can provide a value in the task form when uploading the attachment.

Hidden: the value does not appear in the task form

Read-Only: the value appears in the task form but the user cannot modify it

Note:

custom metadata does not appear in the task form, so you must map the value to a task payload or provide a static value.

Scripting on this page enhances content navigation, but does not change the content in any way.