15 Oracle BPEL Process Manager Workflow Services

15.6.1.1 From the Application Navigator

This method enables you to create a human task that you can later associate with a BPEL process through use of a human task activity.

1. Right-click your BPEL process in the Application Navigator and select Create Human Task Definition.

   The Add a Human Task window appears.

2. Enter a name in the Human Task Name field.

   The name you enter is added to the directory path in the Location field.

   SOA_Oracle_Home/jdev/mywork/my_application/my_process/bpel/
   Human_task_directory/Human_task_name.task
   
   

3. Click OK.

   The Human Task editor appears.

4. Go to section "Reviewing the Sections of the Human Task Editor".

15.6.1.2 From the Component Palette

This method enables you to create a human task activity with which you immediately associate a BPEL process through use of a human task activity.

1. Select Process Activities from the Component Palette.

2. Drag and drop a Human Task activity into your BPEL process.

   The Add a Human Task window appears.

3. Click the second icon to the right of the Task Definition field.

   
   Description of the illustration ht_addtask.gif
   
   

4. Enter a name in the Human Task Name field.

   The name you enter is added to the directory path in the Location field.

   SOA_Oracle_Home/jdev/mywork/my_application/my_process/bpel/
   Human_task_directory/Human_task_name.task
   
   

5. Click OK.

   The Human Task editor appears.

6. Go to section "Reviewing the Sections of the Human Task Editor".

15.6.3.1 Specifying a Task Title and Priority

1. Enter the following details.

   Field	Description
   Title	Enter an optional task title. The task title displays in the Oracle BPEL Worklist Application. If you enter a title in the Task Title field of the General tab of the Human Task window described in "Specifying the Task Title", the title you enter here is overridden.
   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. The priority can be used to sort tasks in the Oracle BPEL Worklist Application. This priority value is overridden by any priority value you select in the General tab of the Add a Human Task window. See Also: "Specifying the Task Initiator and Task Priority" for instructions on specifying a priority value in the Add a Human Task window

   
   

15.6.3.2 Specifying a Task Outcome

Task outcomes capture the possible outcomes of a task. The Oracle BPEL Worklist Application displays the outcomes you specify here as the possible actions to perform during run time. You can specify the following types of task outcomes:

• Select a seeded outcome

• Enter a custom outcome

The task outcomes can also have run time display values that are different from the actual outcome value specified here. This permits outcomes to be displayed in a different language in the Oracle BPEL Worklist Application. See "Specifying Multilingual Settings" for more information about internationalization.

1. Click the flashlight icon to the right of the Outcomes field.

   The Outcomes window displays the possible outcomes for tasks. APPROVE and REJECT are selected by default.

   
   Description of the illustration ht_outcomes.gif
   
   

2. Select additional task outcomes or deselect the default outcomes.

3. Enter any custom outcomes separated by commas in the Custom Outcomes field.

4. Click OK to return to the Human Task editor.

   Your selections display in the Outcomes field.

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

   See Also:

   "Specifying Group Voting Details"

15.6.3.3 Specifying 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. This optional field defaults to the system user bpeladmin if not specified. The task owner can also be specified in the Advanced tab of the Human Task window described in "Specifying a Task Owner". The task owner specified in the Advanced tab overrides any task owner you enter here.

1. Select a method for specifying the task owner:

   • Specifying a Task Owner By Browsing the User Directory

   • Specifying a Task Owner Dynamically

15.6.5.1 Specifying Task Approvers

Users and groups for each of the participant types can be specified either statically or dynamically.When the users and groups are specified statically (or by browsing the identity service), the values can be either of the following:

• A single user or group (for example, jstein), which in the case of a single approver, is captured as follows:

  <participant name="Assignee1">
    <resource isGroup="false" type="STATIC">jstein</resource>
   </participant> 
  
  

• A delimited string of users or groups (for example, jstein, wfaulk, cdickens), which in the case of a single approver, is captured as follows:

  <participant name="Assignee1">
   <resource isGroup="false" type="STATIC">jstein, wfaulk, cdickens</resource>
  </participant>
  
  

You may have a business requirement to create a dynamic list of task approvers specified in a payload variable. This XPath expression can resolve to zero or more XML nodes. Each node value can be either of the following:

• A single user or group

• A delimited string of users or groups. For example, the following task shows that the payload message attribute is of type xsd:String and its value is a comma-delimited string of approvers. This node can be used to specify the participants.

  <task>
   . . .
   <payload>
     <approvers>jstein,wfaulk,cdickens</approvers>
   </payload>
  </task> 
  
  

The default delimiter for the assignee delimited string is a comma (,). This delimiter can be changed using the assigneeDelimiter XML element in the wf-config.xml file. This delimiter applies to all workflows in the system.

Specifying participants in this manner is applicable to all participant types, although they are interpreted differently for each type. For example:

• In a single user participant type, the task is assigned to everyone evaluated.

• In a sequential list of approvers participant type, the task is sequentially assigned to users and groups evaluated in the list.

• In a group vote participant type, a task is created for each user and group evaluated in the list.

This interpretation of resource XPath expressions provides orcl:create-nodeset-from-delimited-string-equivalent functionality to enable you to specify a dynamic list of one or more task approvers (resource element members) from the payload variable.

15.6.5.2 Configuring the Single Approver Participant Type

Figure 15-13 displays the Single Approver window.

This participant type requires a single user to act on a task. If the task is assigned to a role or group with multiple users, one of the members must claim the task and act on it. Based on the user's action, you define what the business process does.

For example, a vacation request is assigned to a manager. The manager must act on the request task three days before the vacation starts. If the manager formally approves or rejects the request, the employee is notified with the decision. If the manager does not act on the task, the request is treated as rejected. Notification actions similar to the formal rejection are taken.

Figure 15-13 Add Participant Type — Single Approver

Description of the illustration ht_singleapprove.gif

1. Enter a recognizable label for this participant in the Label field. This label must be unique within this workflow (for example, Approval Manager, Primary Reviewers, and so on).

   Instructions for configuring the following subsections of the Add Participant Type - Single Approver window are listed in Table 15-3:

   Table 15-3 Add Participant Type — Single Approver

   For This Subsection...	See...
   Requires action from one of the participants below	"Assigning Participants to the Single Approver Task"
   Specify skip rule	"Bypassing a Task Participant"
   Limit allocated duration to	"Specifying a Time Limit for Acting on a Task"
   Allow this participant to invite other participants	"Inviting Additional Participants to a Task"

   
   

15.6.5.3 Configuring the Group Vote Participant Type

Figure 15-14 displays the Group Vote window.

This participant type is used when multiple users, working in parallel, must take action 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.

Figure 15-14 Add Participant Type — Group Vote

Description of the illustration ht_groupvote.gif

1. Enter a recognizable label for this participant in the Label field. This label must be unique within this workflow (for example, Approval Manager, Primary Reviewers, and so on).

   Instructions for configuring the following subsections of the Add Participant Type - Group Vote window are listed in Table 15-4:

   Table 15-4 Add Participant Type — Group Vote Window

   For This Subsection...	See...
   Required consensus between the participants below: 50	"Assigning Participants to the Group Vote Task"
   Specify skip rule	"Bypassing a Task Participant"
   Share attachments and comments	"Sharing Attachments and Comments with Task Participants"
   Default Outcome Consensus Percentage Immediately trigger voted outcome when minimum percentage is met Wait until all votes are in before triggering outcome	"Specifying Group Voting Details"
   Limit allocated duration to	"Specifying a Time Limit for Acting on a Task"

   
   

15.6.5.4 Configuring the Management Chain Participant Type

Figure 15-15 displays the Management Chain window.

This participant type routes tasks for approval to multiple users in a management chain hierarchy. You specify the task participants as a management chain list or a list of 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 of the managers reject the request or the request expires, the order is rejected.

Figure 15-15 Add Participant Type — Management Chain

Description of the illustration ht_manchain.gif

1. Enter a recognizable label for this participant in the Label field. This label must be unique within this workflow (for example, Approval Manager, Primary Reviewers, and so on).

   Instructions for configuring the following subsections of the Add Participant Type - Management Chain window are listed in Table 15-5:

   Table 15-5 Add Participant Type - Management Chain

   For This Subsection...	See...
   Requires management chain approval of one of the participants below	"Assigning Participants to the Management Chain Task"
   Specify skip rule	"Bypassing a Task Participant"
   Maximum Number of Chain Levels Up Highest Title of Approver	"Specifying the Number of Approvers"
   Limit allocated duration to	"Specifying a Time Limit for Acting on a Task"
   Allow this participant to invite other participants	"Inviting Additional Participants to a Task"

   
   

15.6.5.5 Configuring the Sequential List of Approvers Participant Type

Figure 15-16 displays the Sequential List of Approvers window.

This 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. This is similar to the management chain participant type, except that with that type, the users are part of an organization hierarchy. For the sequential list of approvers participant type, they can be any list of users or groups.

Figure 15-16 Add Participant Type — Sequential List of Approvers

Description of the illustration ht_seqlist.gif

1. Enter a recognizable label for this participant in the Label field. This label must be unique within this workflow (for example, Approval Manager, Primary Reviewers, and so on).

   Instructions for configuring the following subsections of the Add Participant Type - Sequential List of Approvers window are listed in Table 15-6.

   Table 15-6 Add Participant Type — Sequential List of Approvers

   For This Subsection...	See...
   Requires sequential approval of all participants below	"Assigning Participants to the Sequential List of Approvers Task"
   Specify skip rule	"Bypassing a Task Participant"
   Limit allocated duration to	"Specifying a Time Limit for Acting on a Task"
   Allow this participant to invite other participants	"Inviting Additional Participants to a Task"

   
   

15.6.5.6 Configuring the FYI Assignee Participant Type

Figure 15-17 displays the FYI Assignee window.

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. FYI assignees 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.

Figure 15-17 Add Participant Type — FYI Assignee

Description of the illustration ht_fyi.gif

1. Enter a recognizable label for this participant in the Label field. This label must be unique within this workflow (for example, Approval Manager, Primary Reviewers, and so on).

   Instructions for configuring the following subsections of the Add Participant Type - FYI Assignee window are listed in Table 15-7:

   Table 15-7 Add Participant Type - FYI Assignee

   For This Subsection...	See...
   Send an FYI copy of this task to all participants below	"Assigning Participants to the FYI Assignee Task"
   Share attachments and comments	"Sharing Attachments and Comments with Task Participants"

   
   

15.6.5.7 Configuring the External Routing Service Participant Type

Figure 15-18 displays the External Routing Service window.

This participant type enables you to configure an external routing service that dynamically determines the participants in the workflow. If this participant type is specified, all other participant types are ignored. It is assumed that the external routing service provides a list of participant types (single approver, list of approvers, group vote, and so on) at run time to determine the routing of the task.

Figure 15-18 Add Participant Type — External Routing Service

Description of the illustration ht_ers.gif

1. Enter a recognizable label for this participant in the Label field. This label must be unique within this workflow (for example, Approval Manager, Primary Reviewers, and so on).

15.6.5.8 Allowing All Participants to Invite Other Participants

After you configure a participant type and are returned to the Human Task editor, the Allow all participants to invite other participants check box is enabled, as shown in Figure 15-19.

Figure 15-19 Human Task Editor — Assignment and Routing Policy Section

Description of the illustration ht_arp.gif

This check box is the equivalent of the Adhoc workflow pattern of previous BPEL 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.

1. If you want this task assignee to invite other participants into the workflow before routing it to the next assignee in this workflow, select the Allow all participants to invite other participants check box.

15.6.5.9 Abruptly Completing a Condition

After you configure a participant type and are returned to the Human Task editor, the Enable abrupt completion condition check box is enabled, as shown in Figure 15-19.

1. If you want to specify conditions under which to complete the task early, regardless of the other participants in the workflow, select the Enable abrupt completion condition check box.

   The Abrupt Completion Details window appears.

   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).

   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 on the two.

2. Select appropriate outcomes and click the > button. To select all, click the >> button.

   
   Description of the illustration ht_abrupt.gif
   
   

3. Click the icon to the right of the Routing Condition field to display the Expression Builder window 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 below a specific amount, no approval is required by their manager.

4. Click OK to return to the Human Task editor.

   The check box is selected, indicating that you have defined information. You can click the icon to the right of the Enable abrupt completion condition check box to edit this information.

15.6.6.1 Overview or Escalation and Expiration Policy

This section provides an overview of how specifying the expiration duration at this level makes this setting the expiration duration of the task across all the participants.

For example, participant LoanAgentGroup and participant Supervisor have 3 days to act on the task between them, as shown in Figure 15-21:

Figure 15-21 Expire After Policy

Description of the illustration ht_esc.gif

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 of the participant's level, 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 to interpret the participant level expiration for the participants is described below:

• Management Chain — Each participant in the management chain gets the same expiration duration. 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 task expires and the escalation and renewal policy is applied.

• Sequential list of approvers — Each assignment in the management chain gets the same expiration duration as the one specified in the sequential list of approvers. Note that 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 task expires and the escalation and renewal policy is applied.

• Group vote

  • In a group vote 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 is the same as 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.

    • No expiration duration, otherwise.

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

In the following routing slip sample, participant Loan Agent Group has an expiration duration of 1 day and participant Loan Agent Supervisor does not have any expiration duration on the task, even though an expiration duration is specified at the routing slip level. In this example, the routing slip is treated just as if there were no expiration duration specified at the routing slip level.

<routingSlip xmlns="http://xmlns.oracle.com/pcbpel/workflow/routingslip">
  <expirationDuration>PT10D </expirationDuration>

  <participants>

    <participant name="Loan Agent 1" expirationDuration="PT2D">
      <resource isGroup="true" type="STATIC">jcooper</resource>
    </participant>
    <participant name="Loan Agent 2">
      <resource isGroup="true" type="STATIC">jstein</resource>
    </participant>

    <managementChain name="Loan Approval Chain" 

                     expirationDuration="PT2D">
      <resource isGroup="true" type="STATIC">wfaulk</resource>
      <levels type="STATIC">1</levels>
      <title type="STATIC">Vice President</title>
    </managementChain>

    <participant name="Reviewer">
      <resource isGroup="true" type="STATIC">sfitzger</resource>
    </participant>
  </participants>

</routingSlip>

Table 15-8 demonstrates the expiration policy. Note that the management chain in the above example evaluates to two users — wfaulk and cdickens (manager of wfaulk).

1. Select an escalation and expiration policy. You can enter a fixed time or a dynamic time by clicking the icon to the right of the By Expression field to display the Expression Builder window.

15.6.6.2 Never Expire Policy

1. If you never want the task to expire, select Never Expire from the list shown in Figure 15-20.

15.6.6.3 Expire After Policy

1. If you want the task to expire, select Expire after from the list shown in Figure 15-20.

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

   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.

   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.

   Figure 15-22 indicates that the task expires in 3 days.

   Figure 15-22 Expire After Policy

   
   Description of the illustration ht_esc.gif
   
   

15.6.6.4 Renew After Policy

1. If you want to extend the expiration period when the user does not respond within the allotted time, select Renew after from the list shown in Figure 15-20.

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

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

   Figure 15-23 Renew After Policy

   
   Description of the illustration ht_esc2.gif
   
   

15.6.6.5 Escalate After Policy

1. If you want to escalate the task (for example, to the user's manager) if the user does not respond within the allotted time, select Escalate after from the list shown in Figure 15-20.

2. Specify the following additional values:

   • Maximum Escalation Levels

     Number of management levels to which to escalate the task

   • Highest Approver Title

     The title of the highest approver (for example, self, manager, director, or CEO).

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

   Figure 15-24 Escalate After Policy

   
   Description of the illustration ht_esc3.gif
   
   

15.6.7.1 Notifying 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.

1. Click a type in the Task Status column to display the complete list of task types:

   • Assign—when the task is assigned to users or a group. This action captures the following actions:

     • Task is assigned to a user

     • Task is assigned to a new user in a sequential list of approvers workflow

     • Task is renewed

     • Task is delegated

     • Task is reassigned

     • Task is escalated

     • Information for a task is submitted

   • Complete

   • Error

   • Expire

   • Request Info

   • Update Outcome

   • Suspend

   • Withdraw

2. 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.

3. Click an entry in the Recipient column 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 approved the task so far. This applies in a sequential list of approvers participant type where multiple users have approved the task and a notification must be sent to all of them.

   • Owner—the task owner

     See Also:

     "Configuring the Notification Channel"

15.6.7.2 Editing 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.

1. Click the icon in the Notification Header column to modify the default notification message.

   The Edit Notification Message window appears.

   
   Description of the illustration ht_notifmess.gif
   
   

   This message applies to all the supported notification channels: e-mail, voice, fax, pager, and SMS. E-mail and fax 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.

2. Modify the message wording as necessary.

3. Click OK to return to the Human Task editor.

15.6.7.3 Setting 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.

1. Select the number of reminders to send from the Remind list.

2. 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.

   
   Description of the illustration ht_remind.gif
   
   

15.6.7.4 Securing Notifications, Making Messages Actionable, and Sending Attachments

You can perform additional notification tasks in this section.

1. Select the corresponding check box for functionality you want to use.

2. Field	Value
   Make notifications secure (exclude details)	Select to make the notification message secure. If selected, a default notification message is used. There are no HTML worklist task details, attachments, or actionable links in the e-mail. Only the task number is in the message. See Also: "Sending Secure Notifications"
   Make e-mail messages actionable	Select to make e-mail notifications actionable. This enables you to perform task actions through e-mail. See Also: "Sending Actionable E-mails" for additional configuration details
   Send task attachments with e-mail notifications	Select to send task attachments with the notification message. See Also: "Sending Inbound and Outbound Attachments"

   
   

15.6.8.1 Specifying 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 the steps below.

1. Implement interface oracle.bpel.services.workflow.assignment.dynamic.IDynamicTaskEscalationFunction. This implementation has to be available in the classpath for the server.

2. Change the file SOA_Oracle_Home\bpel\system\services\config\wf-dynamic-assign-cfg.xml to add a new function:

   <dynamicAssignmentFunctions>
   
     <function name="MANAGERS_MANAGER"
    classpath="oracle.bpel.services.workflow.assignment.dynamic.patterns.
    TaskEscalationManagersManager">
     </function>
   
   </dynamicAssignmentFunctions>
   
   

3. Enter the function name as defined in the wf-dynamic-assign-cfg.xml file for the escalation rule in the Specify Escalation Rule field.

   See Also:

   "Custom Escalation Function"

15.6.8.2 Specifying WordML Style Sheets for Attachments

This option allows dynamic creation of Microsoft Word documents for the purpose of sending them as e-mail attachments using a WordML XSLT stylesheet. The XSLT stylesheet is applied on the task document.

1. Click the flashlight icon to select a WordML style sheet as an attachment.

15.6.8.3 Specifying Style Sheets for Attachments

This option allows creation of e-mail attachments using an XSLT stylesheet. The XSLT stylesheet is applied on the task document.

1. Click the flashlight icon to select a stylesheet as an attachment.

15.6.8.4 Specifying Multilingual Settings

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

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

• Displaying the XML element and attributes names in the payload display of the Oracle BPEL Worklist Application. The key name in the resource bundle must be the same as the name of the XML element and attributes for internationalization of XML element names in the Oracle BPEL Worklist Application.

• Making e-mail notification messages available in different languages. At run time, specify the XPath extension function hwf:getTaskResourceBundleString(taskId, key, locale?) 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).

1. Click Configure Resource.

   The Resource Details window appears.

   
   Description of the illustration ht_resource.gif
   
   

2. Enter the name of the resource used in the resource bundle.

3. Click the flashlight icon to select the JAR or ZIP resource bundle file to use. The resource bundle can be part of your BPEL suitcase.

4. Click OK to return to the Human Task editor.

   See Also:

   "Configuring Messages in Different Languages"

15.6.8.5 Overriding Default System Actions

The actions performed from the Oracle BPEL Worklist Application are common to all business processes. However, you can restrict some actions in a particular business process.

For example, assume that in a loan approval process, the business requirement is to never suspend a loan application. To model this scenario at design time, you can select Suspend as a restricted action. When an action is selected as restricted, the Oracle BPEL Worklist Application does not display the action for this task.

By default, these actions are available on all tasks based on the user's privileges. The task owner or bpeladmin administrator can always perform any of these actions on processes they own.

1. Click Configure Actions.

2. Select the system actions allowed on a task. By default, all are selected and available (unrestricted).

   
   Description of the illustration ht_sysact.gif
   
   

   The following system actions can be restricted by unselecting them:

   • Suspend — Enables task owners (or users with the BPMWorkflowSuspend privilege) to put a workflow temporarily on hold. Task expiration and escalation do not apply until the workflow is resumed. No actions are permitted on a suspended task (except resume and withdraw).

   • Push back — Sends the task one level back in the workflow. For example, assume the task was routed to the LoanAgentGroup and then to jstein. If jstein now pushes the task back, it goes back to the LoanAgentGroup.

   • Renew — If a task is about to expire, a task assignee can renew the task and request more time to perform the task. This operation is not allowed if the process designer has restricted task renewal on the workflow.

   • Skip current assignment — Skips the current assignment and moves to the next assignment or picks the outcome as set by the previous approver if there are no more assignees.

   • Adhoc Route — Enables a user to enter an outcome and then route the task in an adhoc fashion to the next user who must review the task.

   • Request Information — Any workflow participant can request information from the task initiator or any of the prior approvers of the task. When the requested information is submitted, the task is assigned to the user who requested the information.

   • Delegate — Any workflow participant can delegate the task to another user. In this case, the other user is acting on behalf of the current assignee. When the task is delegated, it resides on both users' worklists until the original assignee or the delegated person acts on it.

   • Reassign — Enables the current assignee of the task to transfer it to another user or group. In this case, the task is moved from the worklist of the current assignee to the new assignee.

   • Escalate — Escalates a task to their manager for further action.

   • Withdraw — Enables the task initiator to withdraw any pending task if they no longer want to send it through the workflow. A task owner can also withdraw a task on behalf of the initiator. When a task is withdrawn, the business process is called back with the state attribute of the task set to Withdrawn.

3. Click OK to return to the Human Task editor.

15.6.8.6 Overriding Default Exception Management

Tasks can error due to incorrect assignments. Incorrect assignments can occur for any of the following reasons:

• Invalid assignees — The task assignee user or group is not a valid user in the system.

• Invalid dynamic assignment — When assignees are specified to be dynamic, the dynamic XPath expression is not evaluated.

In the above cases, the task is marked as errored. By default, the life cycle of the task is completed with that action.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. The error assignee can perform one of the following actions:

• Adhoc route — route the task to the actual users assigned to the task. Adhoc route 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 errored.

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

1. Click Configure Assignment.

2. Select the error assignees.

   
   Description of the illustration ht_erroras.gif
   
   

15.6.8.7 Specifying Callback Classes on Task Status

You can register callbacks for the workflow service to call during the life cycle of a task. The callback class has to implement the interface oracle.bpel.services.workflow.task.IRoutingSlipCallback. Make the callback class available in the classpath of the server.

1. Click Configure Callbacks.

2. Click the + sign to add a callback to the table. A callback named OnAssigned is automatically added to the Callback column.

   
   Description of the illustration ht_callback.gif
   
   

3. Click OnAssigned to display a list of additional callback values to select for this column.

   The following callbacks are available:

   • onCompleted — This callback is invoked when the task is completed, expired, withdrawn, or errored.

   • onAssigned — This callback is invoked when the task is assigned to a new set of assignees due to the following actions:

     • outcome update

     • skip current assignment

     • override routing slip

   • onUpdated — This callback is invoked for any other update to the task that does not fall in the onTaskComplete or onTaskAssigned callback. This includes updates on a task due to request for information, submit information, escalation, reassign, and so on.

   • onSubtaskUpdated — This callback is invoked for any update to a subtask.

4. Click Java in the Type column to display a list of additional values for this column.

5. Click the empty field in the Value column to enter a value. The value is the complete class name of the Java class that implements oracle.bpel.services.workflow.task.IRoutingSlipCallback.

6. Click OK.

15.6.8.8 Allowing Task and Routing Customization in BPEL Callbacks

The Allow task and routing customization in BPEL callbacks check box must be selected if you select the check box of the same name on the Human Task - Advanced tab shown in Figure 15-28. Selecting both check boxes updates the metadata for callbacks.

15.7.3.1 Specifying the Task Title

1. Enter the task title in the Task Title field through one of the following methods. This is a mandatory field. Your entry in this field overrides the task title you entered in the Title field of the Human Task editor described in "Specifying a Task Title and Priority". The title displays the task in the Oracle BPEL Worklist Application during run time.

   • Enter the title manually.

   • Click the icon to the right of the field to display the Expression Builder window to dynamically create the title.

   You can also mix static text and dynamic expressions in the same title. To include dynamic text, place your cursor at the appropriate point in the text and click the icon on the right to invoke the Expression Builder window.

15.7.3.2 Specifying the Task Initiator and Task Priority

1. Enter the initiator (for example, jcooper) or click the icon to the right of the Initiator field to display the Expression Builder window for dynamically specifying an initiator. This field is optional.

   The initiator is the user who initiates a task. The initiator can view their created tasks from the Oracle BPEL Worklist Application and perform specific tasks defined in the System Action Details window, such as withdrawing or suspending a task. If not specified, the initiator defaults to the task owner specified on the Advanced tab of the Human Task window. The initiator defaults to bpeladmin if a task owner is also not specified.

2. Select a priority value between 1 (the highest) and 5 from the Priority list. This field is provided for user reference and does not make this task a higher priority during run time. The priority can be used to sort tasks in the Oracle BPEL Worklist Application. This priority value overrides the priority value you select in the Priority list of the Human Task editor.

15.7.3.3 Specifying Task Parameters

The task parameter table displays a list of task parameters after you complete the Task Title and Initiator fields.

1. Click the flashlight in the BPEL Variable column to map the task parameter to the BPEL variable. You must map only the task parameters that carry input data. For output data that is filled in from the worklist, you do not need to map the corresponding variables.

   The Task Parameters window appears.

2. Expand the Variables navigation tree and select the appropriate task variable.

   
   Description of the illustration ht_taskparam.gif
   
   

3. Click OK.

   The Human Task window appears as follows.

   
   Description of the illustration ht_humantask.gif
   
   

4. Click Apply.

5. If you want to define advanced features for the human task activity, click the Advanced tab and go to section "Defining the Human Task Activity Advanced Features". Otherwise, click OK to close the Human Task window.

15.7.4.1 Specifying a Scope Name and a Global Task Variable Name

You are automatically provided with default scope and global task variable names during human task activity creation. However, you can specify custom names that are used to name the scope and global variable during human task activity creation.

1. Enter the name for the BPEL scope to be generated in the Scope Name field.

   This BPEL scope encapsulates the entire interaction with the workflow service and BPEL variable manipulation.

2. Enter the global task variable name in the Global Task Variable Name field.

   This is the name of the BPEL task variable used for the workflow interaction.

15.7.4.2 Specifying a Task Owner

1. Enter the task owner name in the Owner field or click the icon to the right to use the Expression Builder to dynamically specify the owner of this task.

   The task owner can view tasks belonging to business processes they own and perform operations on behalf of any of the task assignees. Additionally, the owner can also reassign, withdraw, or escalate tasks.

   If you do not specify a task initiator on the General tab of the Human Task window, it defaults to the owner specified here. If an owner is not specified, it defaults to the bpeladmin administrator.

15.7.4.3 Specifying an Identification Key

1. Enter an optional identification key value in the Identification Key field.

   The identification key can be used as a user-defined ID for the task. For example, if the task is meant for approving a purchase order, the purchase order ID can be set as the identification key of the task. Tasks can be searched from the Oracle BPEL Worklist Application using the identification key. This attribute has no default value.

15.7.4.4 Including the Task History of Other Human Tasks

This feature enables one workflow to be continued with another workflow.

1. Select the Include task history from check box to extend a previous workflow task in the BPEL process. Selecting this check box includes the task history, comments, and attachments from the previous task. This provides you with a complete end-to-end audit trail.

   When a workflow task is continued with another workflow, the following information is carried over to the new workflow:

   • Task payload and the changes made to the payload in the previous workflow

   • Task history

   • Comments added to the task in the previous workflow

   • Attachments added to the task in the previous workflow

   In the Include task history from list, all existing workflows are listed. Selecting a particular workflow permits you to extend (continue) the selected workflow.

   For example, a hiring process is used to hire new employees. Each interviewer votes to hire or not hire a candidate. If 75% of the votes are to hire, then the candidate is hired; otherwise, the candidate is rejected. If the candidate is to be hired, an entry in the HR database is created and the human resources contact completes the hiring process. The HR contact also needs to see the interviewers and the comments they made about the candidate. This process can be modeled using a group vote for the hiring. If the candidate is hired, a database adapter is used to create the entry in the HR database. After this, a simple workflow can include the task history from the group vote so that the hiring request, history, and interviewer comments are carried over. This simple workflow is assigned to the HR contact.

   See Also:

   "Including the Task History from Other Workflows"

15.7.4.5 Allowing Task and Routing Customizations in BPEL Callbacks

1. Select the Allow task and routing customizations in BPEL callbacks check box to notify the BPEL process using OnMessage callbacks every time a task is routed to a different user or when the task status changes. You must also select the check box of the same name in the Advanced Settings section of the Human Task editor shown in Figure 15-26 in order to update the metadata for callbacks.

   In these callbacks, you can call the Task Service to change the routing or update the current assignees. This option impacts the BPEL code generated to interact with the Task Service.

   If this option is not selected, the client process gets notified only when the task completes or when it expires or errors out.

2. Click OK to close the Human Task window.

3. Go to the Human Task editor for this human task (the .task file).

4. Expand the Advanced Settings section at the bottom of the editor.

5. Click Allow task and routing customization in BPEL callbacks.

   This check box must be selected to use callbacks. This enables you to update the metadata.

15.7.5.1 BPEL Callbacks

If intermediary events need to be propagated to the BPEL process instance, select the Allow task and routing customization in BPEL callbacks check box in both the Advanced tab of the Human Task window and the Advanced Settings section of the Human Task editor. When these options are selected, the workflow service invokes callbacks in the BPEL instance during each update of the task. The callbacks are listed in the TaskService.wsdl file and described below:

• onTaskCompleted — This callback is invoked when the task is completed, expired, withdrawn, or errored.

• onTaskAssigned — This callback is invoked when the task is assigned to a new set of assignees due to the following actions:

  • Outcome update

  • Skip current assignment

  • Override routing slip

• onTaskUpdated — This callback is invoked for any other update to the task that does not fall in the onTaskComplete or onTaskAssigned callback. This includes updates on tasks due to request for information, submit information, escalation, reassign, and so on.

• onSubTaskUpdated — This callback is invoked for any update to a subtask.

Figure 15-31 shows how a workflow interaction with callbacks is modeled in Oracle BPEL Process Manager. Once this task is initiated, a while loop is used to receive messages until the task is complete. The while loop contains a pick with four onMessage branches — one for each of the above-mentioned callback operations. The workflow interaction works fine even if nothing is changed in the onMessage branches, meaning that customizations in the onMessage branches are not required.

In this scenario, a workflow context is captured in the BPEL instance. This context can be used for all interaction with the workflow services. For example, if you want to reassign a task if it is assigned to a group, then you need the workflow context for the reassignTask operation on the Task Service.

It is recommended that any user customizations be done in the first assign, AssignTaskAttributes, and that AssignSystemTaskAttributes not be changed.

Figure 15-31 Workflow Interaction Modeling (with Callbacks)

Description of the illustration bpmdg052.gif

Figure 15-32 shows a workflow interaction in Oracle JDeveloper.

Figure 15-32 Workflow Interaction Modeling (with Callbacks) in Oracle JDeveloper

Description of the illustration vacationreq2.gif

15.7.5.2 Including the Task History from Other Workflows

When the task history is included in a workflow, the generated BPEL process described in the previous two sections is similar, with the following differences:

• The BPEL variable from the workflow whose task history is to be included is reused and no new BPEL variable is created.

• The first invoke activity invokes the reinitiate operation instead of the initiate operation.

  See Also:

  "Including the Task History of Other Human Tasks"

15.7.6.1 Payload Updates

The task carries a payload in it. If the payload is set from a business process variable, then an assign activity with the name copyPayloadFromTask is created in each of the case and otherwise branches to copy the payload from the task back to its source. If the payload is expressed as other XPath expressions (such as ora:getNodes(...)), then this assign is not created because of the lack of a process variable to copy the payload back. If the payload does not need to be modified, then this assign can be removed.

15.7.6.2 Case Statements for Other Task Conclusions

By default, the switch activity contains case statements for the outcomes only. The other task conclusions are captured in the otherwise branch. These conclusions are as follows:

• The task is withdrawn

• The task is errored

• The task is expired

If business logic must be added for each of these other conclusions, then case statements can be added for each of the preceding conditions. The case statements can be created as shown in the following BPEL segment. The XPath conditions for the other conclusions in the case activities for each of the preceding cases are shown in bold.

<switch name="taskSwitch">
  <case condition="bpws:getVariableData('SequentialWorkflowVar1',
'/task:task/task:state') = 'COMPLETED' and
bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:conclusion') = 'ACCEPT'">
    <bpelx:annotation>
      <bpelx:pattern>Task outcome is ACCEPT
      </bpelx:pattern>
    </bpelx:annotation>
      ...
  </case>
  <case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') = 'WITHDRAWN'">
    <bpelx:annotation>
      <bpelx:pattern>Task is withdrawn
      </bpelx:pattern>
    </bpelx:annotation>
     ...
  </case>
  <case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') = 'EXPIRED'">
    <bpelx:annotation>
      <bpelx:pattern>Task is expired
      </bpelx:pattern>
    </bpelx:annotation>
     ...
  </case>
  <case condition=
"bpws:getVariableData('SequentialWorkflowVar1', '/task:task/task:state') = 'ERRORED'">
    <bpelx:annotation>
      <bpelx:pattern>Task is errored
      </bpelx:pattern>
    </bpelx:annotation>
     ...
  </case>
  <otherwise>
    <bpelx:annotation>
      <bpelx:pattern>Task is EXPIRED, WITHDRAWN or ERRORED
      </bpelx:pattern>
    </bpelx:annotation>
      ...
  </otherwise>
</switch>

15.8.2.1 Preview Release of Task Display Form Support for ADF Data Controls

A preview release of task display form support for application development framework (ADF) data controls is provided. Very minimal support is provided with this preview release. Note the following limitations:

• There is no support for complex XSDs with recursive elements.

• Task forms generated with ADF data controls cannot be edited.

Follow these procedures to use this preview release:

1. Open an operating system command prompt.

2. Open Oracle JDeveloper in preview mode:

   JDev_Oracle_Home\jdev\bin\jdev.exe -J"-Dpreview_mode=true"
   
   

   Note that Auto Generate Task Form With ADF Datacontrols now appears as a menu option when you right-click the folder of the human task, as shown in Step 2 of "Selecting a Task Display Form".

3. Open the SOA_Oracle_Home\j2ee\OC4J_Home\config\server.xml file.

   where OC4J_Home is the name of the OC4J container for your install type:

   • home — for the Oracle Application Server SOA Basic install type

   • OC4J_SOA — if you accepted the default value for the Oracle Application Server SOA Advanced install types

4. Add the following line under the <shared-library name="oracle.bpel.common" version="10.1.3"> section:

   <import-shared-library name="adf.oracle.domain"/> 
   
   

5. Restart Oracle Application Server SOA Suite for the changes to take effect.

15.8.3.1 Payload File for the Autogenerated JSP

Two files are automatically generated to display the payload for the autogenerated JSP:

• A default JSP file named payload-body.jsp. This file is added to the HTML root directory of your project, which is by default the public_html directory.

• A mapping XML file named payload-body.xml. This file is added to the same directory of your project as payload-body.jsp.

  Note:

  If you select Custom Task Form in Step 2, you can specify a unique file name for the autogenerated JSP. The mapping XML file is created based on the JSP file name. You can also select the payload elements to include in the autogenerated JSP. For example, if the JSP file is named autogenerate-body.jsp, then the mapping XML file is named autogenerate-body.xml.

  See "Generating a Custom Task Display Form" for details.

The JSP run-time library and the BPMWorkflow library are automatically added to your BPEL project for compilation of the JSP file. The default JSP is designed with two goals in mind:

• To present you with a simple form; that is, an XSD tree with a depth of more than three must be shown in a more readable way in the JSP.

• The default JSP must require minimum modification. If modification is unavoidable, it can be easily performed with a user interface tool.

To attain these goals, instead of presenting a tree structure that mimics the payload XSD structure, the default JSP groups the entire payload structure in sections. It groups simple types that belong to the same parents and makes them sections.

For example, assume you provide the following payload XSD:

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://www.mycompany.com/mycompany"
        xmlns:mp="http://www.mycompany.com/mycompany">

  <element name="myCompany" type="mp:myCompanyType"/>

  <complexType name="myCompanyType" >
    <sequence>
      <element name="board" type="mp:boardType" />
      <element name="CEO" type="string"/>
      <element name="department" type="mp:departmentType" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <complexType name="boardType">
    <sequence>
      <element name="size" type="int" />
      <element name="head" type="string" />
    </sequence>
  </complexType>

  <complexType name="departmentType">
    <sequence>
      <element name="size" type="int" />
      <element name="head" type="string" />
      <element name="function" type="string" />
    </sequence>
  </complexType>

</schema>

This XSD has the structure shown in Figure 15-33.

Figure 15-33 Structure of the XSD for myCompanyType

Description of the illustration wf43.gif

In the default JSP, based on the structure of the leaf nodes, there are three sections: {size, head}, {CEO}, and {size, head, function}. These three sections are named according to their parents' names; that is, the sections are named board, my Company, and department, respectively. In the board section, there are two fields, size and head. Each of these fields are in an editable HTML input type.The section department is different from other sections and can have multiple occurrences (maxOccurs > 1). In this case, all the fields in this section (that is, size, head, and function) are horizontally presented in a table, with each row representing one department. This is called a table section. There is a plus (+) button for adding a row (department) and a minus (-) button for subtracting a row (department) for the department table section.Unlike a regular section, it is not necessarily true that all the fields belong to the same XSD parent in a table section. For example, suppose the head element has two elements: employeeNumber and dateOfBirth. Since these two elements have maxOccurs set to less than or equal to 1, they are shown in the same department table section. This is a desired behavior, because adding a row in the department table not only adds a size and a function field, but also adds the head information fields in the same department row. This makes it easy to move through complicated payload instances.

Nested multiple (maxOccurs > 1) elements are supported. Assume the department element has a groupMember child element whose maxOccurs is unbounded. In that case, the parent element department is presented in a table section while the child groupMember elements are presented in different child table sections. The parent department table section has a column called group member that contains an HTML href link pointing to its corresponding child group member section in each department row. Pressing the + button in the parent department section not only adds a row in the parent table, but also adds a child section for that corresponding new row.

The default JSP in the current release has the following limitations:

• XSDs that contain recursive elements are not supported.

• The default JSP shows all the simple types defined in the payload XSD. If multiple simple types belong to the same XSD choice block, all these simple types are shown in the default JSP. Although simple types are preserved in the JSP, XSD restrictions are not relevant.

• Only payloads copied from variables that are not simple types are supported. For example, if the query is bpws:getVariableData(var) or bpws:getVariableData(var, part) and the variable is a simple type, then JSP generation fails. Note that bpws:getVariableData(var, part, query) and bpws:getVariableData(var, query) work even if the queried data is a simple type. You only need to make sure the variable itself is not a simple type.

• XSI extensions are not supported

• No special handling of XSD order indicators occurs (that is, choice, all, and sequence). For example, the default JSP does not check if you entered both firstname and lastname:

  <xs:element name="person">
   <xs:complexType>
     <xs:all>
       <xs:element name="firstname" type="xs:string"/>
       <xs:element name="lastname" type="xs:string"/>
     </xs:all>
   </xs:complexType>
  </xs:element>
  

/* Modify the code below when necessary */

15.8.4.1 Autogenerated JSP

This option enables you to automatically generate a form for the payload of the task. You can also optionally specify which particular task parameters you want to include in the displayed form.

1. Select Auto JSP from the Body list in the Rendering section.

   An icon displays to the right of Body.jsp in the Source section.

2. Click the icon.

   The Payload Mapping window appears.

   
   Description of the illustration ht_taskform2.gif
   
   

   This window enables you to select message attributes.

3. Select message attributes to include in the autogenerated JSP.

4. Click OK to return to the Task Form Display window.

15.8.4.2 Custom JSP

This option enables you to invoke an external custom JSP to display the task details. You can also specify URL parameters to pass to this JSP at run time. Three parameters are passed in by default — taskID, version, and workflowContext. Additional parameters must be explicitly specified.

1. Select Custom JSP from the Header list in the Rendering section.

   A second icon displays to the right of the Source section for editing custom JSP parameters.

2. Enter the custom JSP file name in the Source field or click the first icon to select the JSP file to use. This JSP is used in the project and deployed with the other JSP files.

3. Click the second icon to specify run time JSP parameters.

   The Payload Mapping window appears. This window enables you to add input JSP parameters.

   
   Description of the illustration ht_taskform3.gif
   
   

4. Add a parameter by clicking the + sign.

5. Add a name in the Name column.

6. Click the icon to the right of the row to display the Expression Builder window to dynamically enter a value for the XPath column.

   For this example, the custom JSP is using a parameter named PRIORITY to receive the task ID from the request. Therefore, PRIORITY is specified as the name and /tns:task/tns:systemAttributes/tns:PRIORITY is specified as the XPath expression.

   See Also:

   "Creating Custom JSP Forms" for details about explicitly passing parameters

15.8.4.3 Default JSP

This option provides the default Header1.jsp and Footer1.jsp files to display the header and footer regions, respectively.

15.8.4.4 XSL

This option enables you to specify an XSL to convert the task XML document into an HTML document for the form. Note that this is useful only to create read-only forms.

1. Enter the HTTP location in the Source field or click the first icon to select the input XSL file to use.

15.8.6.1 Adding Update Support in the Custom JSP

To add update support in the custom JSP, you can write the servlet that uses the remote task service APIs to update the custom JSP task values:

1. Get the task object by using the same steps as used in the custom JSP.

2. Query the task object and set the values based on the custom JSP form.

   For example, if the custom JSP form allows a user to update the priority attribute, then get the priority JSP form value and call task.setPriority(newvalue);.

3. Use the remote task service API to update the task.

4. Get the value from servlet parameter WORKLIST_NEXT_PAGE_PARAMETER_NAME, which the custom JSP page includes as a hidden parameter.

5. Redirect the page to the URL.

15.11.3.1 Creating the Vacation Request Process and Importing the Schema

1. Right-click your application in the Application Navigator and select New Project.

2. Select BPEL Process Project.

3. Create an asynchronous BPEL process with the name VacationRequest.

4. Click Next.

5. Click the flashlight next to Input Schema Element to browse for VacationRequest.xsd in

   SOA_Oracle_Home\bpel\samples\demos\VacationRequest\bpel
   
   

6. Click Open.

   The Type Chooser window appears.

7. Expand and select Imported Schemas > VacationRequest.xsd > VacationRequestProcessRequest.

8. Click OK.

9. Click the flashlight next to Output Schema Element.

10. Expand and select Imported Schemas > VacationRequest.xsd > VacationRequestProcessResponse.

11. Click Finish.

    The schemas are now imported into the project. VacationRequest.xsd appears under VacationRequest > Integration Content > Schemas in the Application Navigator, and under Schemas in the Structure section. The BPEL process—a Receive activity (receiveInput) and an Invoke activity (callbackClient)—is displayed.

12. Select Save from the File main menu.

15.11.3.2 Adding a Human Task to the Order Approval Process

1. Drag and drop a Human Task activity between receiveInput and callbackClient.

2. Click the Create Task Definition icon (second icon).

   
   Description of the illustration wf_task_def.gif
   
   

3. Enter VacationApproval for the human task name and click OK. (Accept the default location.)

   The VacationApproval.task file is created.

   The Human Task editor is displayed.

4. For Title, enter Vacation Approval.

5. Accept the default values for Priority and Outcomes.

6. For Parameters, click the + icon on the right side of the window.

   The Add Task Parameter window is displayed.

7. Click Element and then the flashlight icon.

8. In the Type Chooser window, expand and select Project Schema Files > VacationRequest.xsd > VacationRequestProcessRequest, and click OK.

   
   Description of the illustration ht_typechooser.gif
   
   

9. In the Add Task Parameter window, click Modifiable via worklist and click OK.

   This ensures that you can modify task data using the Oracle BPEL Worklist Application.

10. In the Assignment and Routing Policy section, click the + icon on the right side of the window.

    The Add Participant Type window is displayed.

11. For Type, select Single Approver.

    This participant type acts alone on the task.

12. For Label, enter Vacation Approver.

13. Click By expression.

    In this example, you assign the task to the manager of the vacation requester.

14. Click the icon to the right of the Dynamic User Xpath field to display the Expression Builder window.

15. Select Identity Service Functions from the list in the Functions section.

16. Double-click getManager.

17. Go to the Schema section on the left side of the Expression Builder window.

18. Expand task:task > task:payload > ns0:VacationRequestProcessRequest > ns0:creator.

19. Click Insert Into Expression.

    The Expression Builder window appears as follows:

    
    Description of the illustration ht_vacreq1.gif
    
    

20. Click OK to return to the Add Participant Type window.

21. Click OK to return to the Human Task editor.

22. Click the + sign to expand the Expiration and Escalation Policy section.

23. Select Expire after from the drop-down list.

24. Click Fixed Duration and select 1 from the Day list.

25. Select Save from the File main menu.

26. Click the X next to VacationApproval.task to close the Human Task editor.

15.11.3.3 Assigning Input and Output Parameters for the Human Task

1. Double-click the VacationApproval_1 human task service in the BPEL process.

   
   Description of the illustration ht_vacreq2.gif
   
   

   This displays the Human Task window.

2. In the Task Title field, enter the word for after the words Vacation Approval.

3. Click the icon at the right to display the Expression Builder window.

4. In the BPEL Variables section, expand and select inputVariable> payload > client:VacationRequestProcessRequest > client:creator.

5. Click Insert Into Expression.

   The XPath expression appears in the Expression section.

   
   Description of the illustration ht_vacreq3.gif
   
   

6. Click OK.

   The XPath expression is appended to the task title.

7. Click the icon to the right of the Initiator field to display the Expression Builder window.

8. Repeat Steps 4 through 6 to insert the same XPath expression in the Initiator field.

   
   Description of the illustration ht_vacreq4.gif
   
   

9. Click the flashlight icon under the BPEL Variable column.

   The Task Parameters window appears.

10. In the Task Parameters window, expand and select Variables > inputVariable > payload > client:VacationRequestProcessRequest.

11. Click OK.

12. In the Human Task window, click OK.

13. Select Save from the File main menu.

15.11.3.4 Creating a Task Form for the Worklist

1. In the Application Navigator, right-click the VacationApproval folder and select Auto Generate Simple Task Form.

   This automatically generates a task form file.

2. Close payload-body.jsp by clicking the X sign at the top.

15.11.3.5 Modeling the Task Outcome

1. Double-click VacationRequest.bpel.

2. Expand the taskSwitch Switch activity.

3. Drag and drop an Assign activity to below the copyPayloadFromTask Assign activity in the <case Task outcome is APPROVE> section of the Switch activity.

4. Double-click the Assign icon to display the Assign window.

5. Click the General tab.

6. Enter assignVacationApproval1 in the Name field.

7. Click Apply.

8. Click the Copy Operation tab.

9. Click Create and select Copy Operation.

10. Enter the following details:

    Field	Value
    From
    Type	Expression
    Expression	string('Approved')
    To
    Type	Variable
    Variables	Expand and select Variables > outputVariable > payload > client:VacationRequestProcessResponse > client:result Note: The namespace number values (for example, client, ns1) can vary. Use the namespace values that automatically appear.

    
    

11. Click OK to close the Create Copy Operation window and the Assign window.

12. Repeat Steps 3 through 11 to create an Assign activity below the copyPayloadFromTask Assign activity in the <case Task outcome is REJECT> section. Enter the same details as described above, with the following exceptions:

    • Name it assignVacationApproval2

    • Set the Expression field to string('Rejected')

13. Repeat Steps 3 through 11 to create an Assign Activity below the copyPayloadFromTask Assign activity in the <otherwise> section. Enter the same details as described above, with the following exceptions:

    • Name it assignVacationApproval3

    • Set the Expression field to string('Rejected')

14. The process looks as follows:

    
    Description of the illustration ht_vacreq5.gif
    
    

15. Select Save from the File main menu.

16. Click the - sign to close the taskSwitch Switch activity.

15.11.3.6 Validating, Compiling, and Deploying the Order Approval Process

1. Go to the Application Navigator section.

2. Right-click VacationApproval.

3. Select Deploy > my_integration_server_connection > Deploy to default domain.

   This compiles the BPEL process. Check for errors by clicking the buttons at the bottom of the window. If there are no errors, deployment was successful.

15.11.3.7 Running the Order Approval Process

1. Log into Oracle BPEL Control by selecting Start > All Programs > Oracle - Oracle_Home > Oracle BPEL Process Manager > BPEL Control.

   The Dashboard tab of Oracle BPEL Control appears.

2. Enter the following details to log into Oracle BPEL Control and click Login:

   Field	Value
   Username	oc4jadmin
   Password	welcome1

   
   

3. Click VacationApproval in the Deployed BPEL Processes list.

4. Enter jcooper for the creator of the vacation.

5. Enter appropriate values for the remaining fields.

6. Click Post XML Message.

   The BPEL Processes tab displays a message similar to the following:

   Test Instance Initiated
   
   

7. Click the Instances tab at the top.

8. Click the OrderApproval instance.

   A message appears indicating that the instance is active.

9. Select Start > All Programs > Oracle - Oracle_Home > Oracle BPEL Process Manager > Sample Worklist Application to access the login window for Oracle BPEL Worklist Application:

10. Log in as jstein/welcome1.

    The user jstein is the manager of jcooper. This displays Oracle BPEL Worklist Application. A task waiting to be approved appears.

11. Select Claim in the Actions list for the task to approve.

12. Click Go.

    The task details and payload information appear.

13. Review the information. For example, the following information appears if you copied and pasted in the contents of OrderBookingPO_1.xml.

14. Select Approve from the Task Action list and click Go.

15. Log out as user jcooper.

16. Log into Oracle BPEL Worklist Application as jstein/welcome1.

17. Select Approve from the Actions list and click Go.

    After processing, no tasks appear in Oracle BPEL Worklist Application.

18. Log out.

19. Return to Oracle BPEL Control.

20. Click the Instances tab at the top.

21. Click the VacationApproval instance.

    A message appears indicating that the instance has completed.

22. Click the Audit and Flow links to observe additional details about the completed OrderApproval process.

15.12.2.1 Security in SOAP Web Services

SOAP Web services also support Web service security. When Web service security is used, the workflow context does not need to be present in the SOAP input. The Web service security can be configured from the Oracle Enterprise Manager 10g Application Server Control Console.

15.12.2.2 Security in EJBs

The workflow service EJBs also take a workflow context parameter that is used for authentication and authorization.

15.12.2.3 Creating Workflow Context on Behalf of a User

The authenticate API operation on the task query service can create the workflow context on behalf of a user by passing the user ID and password of an admin user in the request. An admin user is a user who has the BPMWorkflowAdmin role. This created context is as if it was created using the password on behalf of the user.

In this example, the workflow context is created for user jcooper.

ITaskQueryService taskQueryService = …. 
String realm = …;
IWorkflowContext wfCtx = 
    taskQueryService.authenticate('bpeladmin', 'welcome1', realm, 'jcooper');

15.12.5.1 Creating Users and Groups

You use directory-specific tools to create realms, users, or groups. For example:

• To create users and groups when using OID, you use the Oracle Delegated Administration Services tools. See Oracle Identity Management Guide to Delegated Administration for more information.

• To create user and group credentials when using the XML-based JAZN provider, you use the JAZN Admintool to modify the jazn-data.xml file. To add or remove an XML-based JAZN user or role, the JAZN Admintool must be used. You can manually edit the users-properties.xml file to specify detailed user properties that JAZN does not support.

  For example, to add a user to a specified realm, issue the following command:

  java -jar jazn.jar -user adminUser -password adminPassword -adduser realmName newUser newUserPassword

  The JAZN Admintool provides different command options. You can list all the options and their syntax with the -help option, as in:

  java -jar jazn.jar -help

• If you are using a third-party LDAP server or a custom user repository, you must use the specific tools available for that directory.

15.12.5.2 Identity Service Providers

Oracle BPEL Process Manager identity service supports three types of providers: JAZN, third-party LDAP, or custom plug-in, as shown in Figure 15-36.

Figure 15-36 Identity Service Providers

Description of the illustration bpmdg034.gif

The identity service providers perform the following operations:

• Authentication—authenticates users given their username and password

• Authorization—determines roles and group memberships for a specific user. These roles are then used to control access to various work items and operations on the worklist.

• Retrieve user properties—includes contact information such as first name, last name, phone, e-mail, preferred notification channel, language preference, time zone, and organization details such as manager name and reportees.

15.12.5.3 User and Role Properties

The identity service supports the following user properties:

• Display name

• Given name, middle name, and last name

• Description

• Title

• E-mail address

• Telephone number

• Home phone number

• Mobile phone number

• Fax number

• Pager number

• Manager ID

• Owners (applies to groups and roles, but not users)

• Time zone

• Language preference (Java locale)

• Notification preference (preferred notification channel)

The preceding properties are optional for Oracle BPEL Process Manager users. However, some features, such as task notification, are not available if the contact information is not present in the directory or in the users-properties file for the JAZN XML-based provider. Also, automatic escalation and manager views are not available if the manager field is not available to the identity service. If the user is not listed among the owners of the group, they cannot modify the rule defined for the group.

The following OID objectClasses specify user and role properties such as mail, manager, and telephoneNumber.

• top

• person

  • cn

  • sn

  • description

  • telephoneNumber

• organizationalPerson

  • title

  • telephoneNumber

  • facsimileTelephoneNumber

• inetOrgPerson

  • uid

  • displayName

  • givenName

  • manager

  • mail

  • homePhone

  • mobile

  • pager

  • preferredLanguage

• orclUserV2

  • middleName

  • orclTimeZone

  • orclWorkflowNotificationPref

• groupOfUniqueNames

  • description

  • owner

  • uniqueMember

• orclGroup

  • displayName

  • mail

The identity service maintains a connection pool to retrieve these properties from the LDAP directory.

If you are using the XML-based JAZN provider, the same entries are represented as XML elements in the users-properties.xml file in

SOA_Oracle_Home\bpel\system\services\config

15.12.5.4 Multirealm Support

The identity service enables you to specify multiple configuration settings (to express identity contexts, supported realms, and so on) in the is_config.xml file. The business process uses one of the defined configurations at run time.

The configuration must specify the realm name to enable a business process to resolve the context at run time. For the JAZN provider, the realm name must match one of supported JAZN realm names. Otherwise, a run time exception is thrown. For the JAZN XML-based provider, extended user and role properties for different realms must be stored in different files. For the LDAP provider, the realm name can be any unique name, while the context is defined by the LDAP URL, user search base, and role search base nodes in the LDAP server tree. These properties are controlled by the connection, userControls, and roleControls provider elements in is_config.xml.

If the is_config.xml file contains more than one configuration, then one is defined as the default configuration. The default context is used by the BPEL process if no specific context information is found at run time. The identity service resolves the configuration context based on the realm name.

15.12.5.5 Authentication, Authorization, and Identity Service Providers

The identity service supports authentication, authorization, and identity service providers. The identity service provider is the default pseudoservice provider. It must be defined for each configuration in the is_config.xml file. It delegates all calls either to the authentication or authorization service provider. By default, all three service providers share the same context setting defined in the identity provider.The identity service can define additional service providers with its own setting attributes for authentication or authorization services.If the provider service attribute is set to Authentication, the setting and the provider context are used only for all authentication calls for the configuration. If the provider service attribute is set to Authorization, the setting and provider context are used only for authorization calls.

15.12.9.1 Internationalization of Attribute Labels

Attribute labels provide a method of attaching a meaningful label to a task flex field attribute. It can be desirable to present attribute labels that are translated into the appropriate language for the locale of the user.

To achieve this, you can add entries to the WorkflowLabels.properties resource property file, and associated resource bundles in other languages. This file exists in the SOA_Oracle_Home\bpel\system\services\config\wfresource directory.

Entries for flex field attribute labels must be of the form:

FLEX_LABEL.[label name]=Label Display Name

For instance, the entry for a label named Location is:

FLEX_LABEL.Location=Location

Note that adding entries to these files for attribute labels is optional. If no entry is present in the file, the name of the attribute label as specified using the API is used instead.

15.13.1.1 Implementing a Dynamic Assignment Function

To implement your own dynamic assignment function, write a Java class that implements one or both of the following interfaces:

oracle.bpel.services.workflow.assignment.dynamic. IDynamicUserAssignmentFunction
oracle.bpel.services.workflow.assignment.dynamic. IDynamicGroupAssignmentFunction

If your dynamic assignment function selects users, implement the first interface. If it selects groups, implement the second interface. If it allows the selection of both users and groups, implement both interfaces.

The two interfaces above both extend the interface oracle.bpel.services.workflow.assignment.dynamic.IDynamicAssignmentFunction.

Your Java class should also implement the methods in that interface.

These interfaces as shown below:

public interface IDynamicAssignmentFunction 
{
  /**
   * Sets the initialization parameters required by the function (if any)
   * This function is called automatically by the DynamicAssignmentRegistry
   * on registration of a new function. Initialization parameters can be
   * specified in the xml definition of the function in the dynamic assign
   * config file
   * @param initParams Map of String parameter values keyed by String parameter
   * names
   * @throws DynamicAssignmentException if implementation of method finds invalid 
   * parameters
   */
  public void setInitParams( Map initParams ) throws DynamicAssignmentException;
  
   
   /**
   * Gets the name of this Dynamic Assignment Function 
   * @return String the name of the Dynamic Assignment Function 
   */
   public String getFunctionName();
   
 
  /**
   * Gets a description of this Dynamic Assignment Function
   * @return  String description of function
   */
   public String getDescription();
}
public interface IDynamicGroupAssignmentFunction extends
 IDynamicAssignmentFunction
{
  /**
    * This method contains the implementation of the Assignment Function
    * Given a group name, it will return a subgroup in that group, 
    * according to the assignment pattern implemented
    * @return String name of group 
    * @param groupName String name of group to select group from 
    * @param realm String name of Identity Service realm the group belongs
    * to. If realm is null, the default Identity Service realm will be used.
    * @param parameters String[] optional array of parameter values.
    * Use of parameter values is implementation-specific.
    */
    public String getGroupAssignment( String groupName, String realm, String[]
 parameters )
      throws DynamicAssignmentException;
  /**
    * This method contains the implementation of the Assignment Function
    * Given an arbitrary list of groups, it will return a group in that 
    * list, according to the assignment pattern implemented
    * @return String name of group 
    * @param groupNames List of groups to select from 
    * @param realm String name of Identity Service realm the groups belong
    * to. If realm is null, the default Identity Service realm will be used.
    * @param parameters String[] optional array of parameter values.
    * Use of parameter values is implementation-specific.
    */
    public String getGroupAssignment( List groupNames, String realm, String[]
 parameters )
      throws DynamicAssignmentException;
}
public interface IDynamicUserAssignmentFunction extends IDynamicAssignmentFunction
{
  /**
    * This method contains the implementation of the Assignment Function
    * Given a group name, it will return a user in that group, 
    * according to the assignment pattern implemented
    * @return String username of user 
    * @param groupName String name of group to select user from
    * @param realm String name of Identity Service realm the group belongs
    * to. If realm is null, the default Identity Service realm will be used.
    * @param parameters String[] optional array of parameter values.
    * Use of parameter values is implementation-specific.
    */
    public String getUserAssignment( String groupName, String realm, String[]
 parameters )
      throws DynamicAssignmentException;
   /**
    * This method contains the implementation of the Assignment Function
    * Given an arbitrary list of users, it will return a user in that 
    * list, according to the assignment pattern implemented
    * @return String username of user 
    * @param usernames List of usernames to select user from 
    * @param realm String name of Identity Service realm the users belong
    * to. If realm is null, the default Identity Service realm will be used.
    * @param parameters String[] optional array of parameter values.
    * Use of parameter values is implementation-specific.
    */
    public String getUserAssignment( List usernames, String realm, String[]
 parameters )
      throws DynamicAssignmentException;
}

The dynamic assignment framework also provides the utility class oracle.bpel.services.workflow.assignment.dynamic.DynamicAssignmentUtils.

This class provides a number of methods that are useful when implementing dynamic assignment functions.

These include:

/**
   * Method returns a list of users belonging to the specified group
   * that are available (i.e. not on vacation etc.)
   * @return List of String usernames of available users
   * @param  group - name of group to lookup users for
   * @throws DynamicAssignmentException if error encountered looking up 
   * group, or checking users.
   */
  public static List getAvailableUsersFromGroup( String group, String realm )
    throws DynamicAssignmentException
    /**
   * Method returns a list of users from the specified list
   * that are available (i.e. not on vacation etc.)
   * @return List of String usernames of available users
   * @param usernames - List of String usernames to check
   * @param realm - realm that users belong to
   * @throws DynamicAssignmentException if error encountered looking up 
   * group, or checking users.
   */
  public static List getAvailableUsersFromList( List usernames, String realm )
    throws DynamicAssignmentException
  /**
  * Method uses the specified group name to lookup the sub-groups belonging to
  * that group using the identity service. 
  * @return List of String names of groups
  * @param groupName name of group to lookup
  * @param realm to lookup group in - if null, then use identity service default
  * @realm
  * @batam boolean - directsOnly: if true return only the direct sub-groups
  * of this group. If false, return all groups belonging to this group.
  * @throws DynamicAssignmentException if group could not be found
  */
  public static List getGroupsFromGroup( String groupName
                                       , String realm
                                       , boolean directsOnly )
    throws DynamicAssignmentException
  /**
  * Method uses the specified group name to lookup the users belonging to that
  * group using the identity service. 
  * @return List of String usernames of user
  * @param groupName String name of group to lookup
  * @param realm to lookup group in - if null, then use identity service default
  * @realm
  * @throws DynamicAssignmentException if group could not be found
  */
  public static  List getUsersFromGroup( String groupName, String realm ) 
    throws DynamicAssignmentException
  /**
   *Method returns the default identity management realm for the Identity Service
   *Instance.
   */
  public static String getIDServiceDefaultRealm( ) throws
 DynamicAssignmentException
  
  /**
  * Method checks WF Schema to determine if the specified user is available 
  * (i.e. they are not on vacation etc.).
  * @return true if user is available, false if they are on vacation
  * @param username
  * @param realm
  */
  public static boolean isUserAvailable( String username, String realm )
    throws DynamicAssignmentException

15.13.1.2 Configuring Dynamic Assignment Functions

Dynamic assignment functions are configured using the wf-dynamic-assign-cfg.xml file in the SOA_Oracle_Home\bpel\system\services\config directory.

Each dynamic assignment function must have an entry in this file, in the form of a <function> tag.

The function tag must contain two attributes:

• name — the name of the function.

• classpath — the classpath of the class that implements the function.

In addition, the function tag can optionally contain any number of <property> tags. These tags pass initialization parameters to the dynamic assignment function. Each property tag must contain a name attribute. The value of the property is specified in the body of the tag.

The property values specified in these tags are passed as a map (indexed by the value of the name attributes) to the setInitParameters method of the dynamic assignment functions.

Two of the functions have initialization parameters. These are:

• ROUND_ROBIN — The parameter MAX_MAP_SIZE specifies the maximum number of sets of users or groups for which the function can maintain ROUND_ROBIN counts. The dynamic assignment function holds a list of users and groups in memory for each group (or list of users and groups) on which it is asked to execute the ROUND_ROBIN function.

• most-productive — The parameter DEAFULT_TIME_PERIOD specified the length of time (in days) over which to calculate the user's productivity. This value can be overridden when calling the most-productive dynamic assignment function. Use an XPath function by specifying an alternative value as the third parameter in the XPath function call.

15.13.1.3 Configuring Display Names for Dynamic Assignment Functions

The runtime config service provides methods for returning a list of available user and group dynamic assignment functions. These functions return both the name of the function, and a user-displayable label for the function. The functions support localization of the display name, so that it displays in the appropriate language for the context user. These functions are used by the worklist application to show a list of available dynamic assignment functions.

To specify display names (and appropriate translations) for your dynamic assignment functions, add entries to the resource property file WorkflowLabels.properties, and associated resource property files in other languages. This file exists in the SOA_Oracle_Home\bpel\system\services\config\wfresource directory.

Entries for dynamic assignment functions must be of the form:

DYN_ASSIGN_FN.[function name]=Function Display Name

For instance, the entry for the ROUND_ROBIN function is:

DYN_ASSIGN_FN.ROUND_ROBIN = Round Robin

Note that adding entries to these files for dynamic assignment functions is optional. If no entry is present in the file, then the name of the function (for example, ROUND_ROBIN') is used instead.

15.13.2.1 Assignment Service Overview

The assignment service determines the following task assignment details in a workflow:

• The assignment when the task is initiated

• The assignment when the task is reinitiated

• The assignment when a user updates the task outcome. When the task outcome is updated, the task can either be routed to other users or completed.

• The assignees from whom information for the task can be requested

• If the task supports reapproval from the Oracle BPEL Worklist Application, a user can request information for reapproval.

• The users who reapprove the task if reapproval is supported.

The workflow service identifies and invokes the assignment service for a particular task to determine the task assignment.

For example, a simple assignment service iteration is as follows:

1. A client initiates an expense approval task whose routing is determined by the assignment service.

2. The assignment service determines that the task assignee is jcooper.

3. When jcooper approves the task, the assignment service assigns the task to jstein. The assignment service also specifies that a notification must be sent to the creator of the task, jlondon.

4. jstein approves the task and the assignment service indicates that there are no more users to which to assign the task.

15.13.2.2 Implementing an Assignment Service

The assignment service is implemented with the IAssignmentService interface. The workflow service passes the following information to the assignment service to determine the task assignment:

• Task document — The task document that is executed by the workflow. The task document contains the payload and other task information like current state, and so on.

• Map of properties — When an assignment service is specified, a list of properties can also be specified to correlate callbacks with backend services that determine the task assignees.

• Task history — The task history is a list of chronologically ordered task documents to trace the history of the task. The task documents in this list contain a subset of attributes in the actual task (such as state, updatedBy, outcome, updatedDate, and so on).

15.13.2.3 Example of Assignment Service Implementation

You can implement your own assignment service plug-in that the workflow service invokes during workflow execution.

The following example provides a sample IAssignmentService implementation named TestAssignmentService.java.

/* $Header: TestAssignmentService.java 24-may-2006.18:26:16 rarangas Exp $ */
/* Copyright (c) 2004, 2006, Oracle. All rights reserved.  */
/*
   DESCRIPTION
    Interface IAssignmentService defines the callbacks an assignment 
    service will implement. The implementation of the IAssignmentService 
    will be called by the workflow service
   PRIVATE CLASSES
    <list of private classes defined - with one-line descriptions>
   NOTES
    <other useful comments, qualifications, etc.>
   MODIFIED    (MM/DD/YY)
      rarangas  01/30/06 - 
 */
/**
 *  @version $Header: IAssignmentService.java 29-jun-2004.21:10:35 rarangas Exp
 $
 *  @author  rarangas
 *  @since   release specific (what release of product did this appear in)
 */
package oracle.bpel.services.workflow.test.workflow;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import oracle.bpel.services.workflow.metadata.routingslip.model.*; 
import oracle.bpel.services.workflow.metadata.routingslip.model.Participants;
import oracle.bpel.services.workflow.metadata.routingslip.model.ParticipantsType.*;
import oracle.bpel.services.workflow.task.IAssignmentService;
import oracle.bpel.services.workflow.task.ITaskAssignee;
import oracle.bpel.services.workflow.task.model.Task;
public class TestAssignmentService implements
 oracle.bpel.services.workflow.task.IAssignmentService {
    static int numberOfApprovals = 0;
    static String[] users = new String[]{"jstein", "wfaulk", "cdickens"};
    public Participants onInitiation(Task task, 
                                     Map propertyBag) {
        return createParticipant();
    }
    public Participants onReinitiation(Task task, 
                                       Map propertyBag) {
        return null;
    }
    public Participants onOutcomeUpdated(Task task, 
                                         Map propertyBag,
                                         String updatedBy,
                                         String outcome) {
        return createParticipant();
    }
    public Participants onAssignmentSkipped(Task task, 
                                            Map propertyBag) {
        return null;
    }
    public List getAssigneesToRequestForInformation(Task task, 
                                                    Map propertyBag) {
        List rfiUsers = new ArrayList();
        rfiUsers.add("jcooper");
        rfiUsers.add("jstein");
        rfiUsers.add("wfaulk");
        rfiUsers.add("cdickens");
        return rfiUsers;
    }
    public List getReapprovalAssignees(Task task, 
                                       Map propertyBag,
                                       ITaskAssignee infoRequestedAssignee) {
        List reapprovalUsers = new ArrayList();
        reapprovalUsers.add("jstein");
        reapprovalUsers.add("wfaulk");
        reapprovalUsers.add("cdickens");
        return reapprovalUsers;
    }
    private Participants createParticipant() {
        if (numberOfApprovals > 2) {
            numberOfApprovals = 0;
            return null;
        }
        String user = users[numberOfApprovals++];

        ObjectFactory objFactory = new ObjectFactory();
        Participants participants = objFactory.createParticipants();
        Participant participant = objFactory.createParticipantsTypeParticipant();
        participant.setName("Loan Agent");
        ResourceType resource2 = objFactory.createResourceType(user);
        resource2.setIsGroup(false);
        resource2.setType("STATIC");
        participant.getResource().add(resource2);

        participants.getParticipantOrSequentialParticipantOrAdhoc().
          add(participant);
        return participants;
    }

}

15.13.2.4 Deploying a Custom Assignment Service

You must use one of the following methods to make an assignment service implementation class and its related classes available in the class path of Oracle BPEL Process Manager:

• Load your classes in the SOA_Oracle_Home\bpel\system\classes directory and unzip your JAR files in the same directory.

• Change the Oracle BPEL Process Manager shared library to include your JAR files.