Skip Headers
Oracle® Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management
11g Release 1 (11.1.1.4.0)

Part Number E15176-04
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
View PDF

26 Using Approval Management

This chapter describes the Approval Management extensions (AMX) to the human workflow services of Oracle SOA Suite. The human workflow service is responsible for handling all interactions with users or groups participating in the business process. It does this by creating and tracking tasks for the appropriate users in the organization. Users typically access tasks through a variety of clients, including the worklist application, email, portals, or custom applications.

AMX enables you to define complex task routing slips for human workflow by taking into account business documents and associated rules to determine the approval hierarchy for a work item. Additionally, AMX lets you define multi-stage approvals with associated list builders based on supervisor or position hierarchies. You define the approval task in the Human Task Editor of Oracle JDeveloper, and associate the task with a BPEL process.

For more information about human tasks, see the following chapter and appendix in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite:

This chapter includes the following sections:

26.1 Introduction to Approval Management

Approval Management extensions extend human workflow services with complex approval patterns. It serves as a sophisticated "Assignment Manager" for human workflow. Some of the key workflow features that are provided include:

AMX provides the following additional features:

26.1.1 AMX Components

Figure 26-1 shows the key AMX and human task integration components. These components are described in subsequent sections of this chapter.

Figure 26-1 Overall Architecture

Overall Architecture

The human workflow service enables users to model human interactions as part of a business process. The human workflow service handles requests based on task and rules metadata. It consists of the following set of core services:

  • Task service

  • Task query service

  • User metadata service

  • Task metadata service

  • Identity service

  • Notification service

  • Assignment manager

These services are described in detail in the chapter "Designing Task Display Forms for Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite. AMX serves as a sophisticated assignment manager within human workflow allowing you to model complex approval patterns based on business rules.

The core components required for approval management include the following:

  • Human Task Editor in JDeveloper

    This task editor is used to define the metadata for a human task and the routing slip. The task editor lets you define such things as task parameters, outcomes, expiration and escalation, and notification settings. Some of the components added by AMX include the ability to do the following:

    • Define multi-stage approvals and associated approval list builders in JDeveloper.

    • Determine the approval hierarchy based on business documents (ADF objects) and business rules. This is done through Rules Designer in JDeveloper

  • Human workflow services

    Some of the key services that are required for handling complex approvals include the following:

    • Task Service - Responsible for creating and managing tasks in the dehydration store

    • Identity Service - Responsible for authentication and authorization of users and groups. The service can look up various user directories for authorization and contact information for users.

    • Task Query Service - Responsible for retrieving tasks for the web-based worklist application

    • Decision Service - Responsible for executing business rules related to approvals

  • Worklist Application

    The worklist is a web-based application that lets users access tasks assigned to them and perform actions based on their roles in the approval process. The worklist supports the following profiles:

    • Work assignee - An end user who is assigned a task. These users can view tasks assigned to them and perform actions, and also can define custom views and define routing rules for their tasks.

    • Process owner - Typically a business analyst responsible for managing certain types of approvals. These users can manage tasks for the processes they own, define approval groups, and change approval policies

    • Workflow administrator - Typically a system administrator responsible for managing errored tasks, and administering and monitoring work queues. This user also may use Oracle Enterprise Manager to monitor the health of the workflow services.

26.2 Understanding Approval Management Concepts

As described earlier, AMX extends human workflow services with additional functionality to handle complex approval patterns.

Some human workflow concepts with which you must be familiar are the following:

These concepts are described in the following chapters in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite:

The sections that follow describe new concepts introduced to handle complex approvals.

26.2.1 Task

A task handles approvals. A different task is created for each approval requirement based on the business served by it. For example, an approve new expense report task or an approve new purchase order task.

Some of the standard metadata for a task include the following:

  • Task attributes such as title, outcomes (approve, reject, and so on) priority, expiration and others

  • Task parameters that may be based on simple primitive types, XML elements, or external entities such as ADF view objects

  • A complex approval task that may include one or more stages to identify the key milestones within the approval sequence. For more information see Section 26.2.3, "Stages."

  • Expiration and escalation policy

  • Notification settings for notifying various participants

  • List builders within stages, which are based on names and expression, management chain, supervisory, position, job-level hierarchy, or approval groups. For more information, see Section 26.2.4, "List Builders."

  • Approval task configurations, including policies for substitution and modification of approvers, configuration of self-approval, and repeated approvers. For more information, see Section 26.2.1, "Task."

    Figure 26-2 shows the various stages in a sample approval pattern.

    Figure 26-2 Approval List Structure

    Approval List Structure

These are described in more detail in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

The approval pattern consists of four stages:

  • Header approval

  • Line approval

  • Receipt verification

  • Payment

Header approval runs in parallel with line approval and receipt verification. After these stages run, the payment stage runs.

Each of the four stages has list builders. Multiple list builders in a stage can run in serial or parallel to one another. One or more approvers can exist within each list builder. Figure 26-3 illustrates these concepts.

Figure 26-3 Stages and Their List Builders

Stages and Their List Builders

These concepts are described in the sections that follow.

26.2.2 Service Data Objects

ADF Business Components objects can be exposed easily as Service Data Objects (SDOs) through the service interface. This provides a flexible way to accept business entities. Subsequently, supporting SDOs natively, enables us to accept multiple business entities. This also lays the foundation for future Flexfield SDO support. Since an SDO is a structured XML, you can pass it in as static XML through the task payload.

A collection is defined in an entity parameter for the task. It enables access to a portion of the business entity as an XML fragment retrieved by an XPATH expression. Keys allow us to identify the primary keys in this fragment.

An entity parameter is the definition that tells us how to access an SDO or a static XML. An entity parameter captures the following information for an SDO:

  • Identity of a reference in the overall SCA process, including the Web service definition language (WSDL) for the SDO web service

  • Method to invoke

  • Input message to the web service

  • Output message to the web service

  • Collections

An entity parameter captures the following information for a static XML:

  • XSD for the static XML

  • Collections

For example, an expense voucher can have hierarchical groupings of header, lines, and cost centers. For approval policy purposes, you may only define a collection on header and lines if these are the only components required for determining the set approvers. It is not necessary to map as collections those parts of the business document that are not necessary to define rules.

For more information, see "Implementing Business Services with Application Modules" and "Integrating Service-Enabled Application Modules" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

26.2.3 Stages

A stage is a set of approvals related to a collection. The same collection can be associated with multiple approval stages.

Figure 26-4 illustrates the mapping of stages and collections.

Figure 26-4 Mapping of Stages and Collections

Mapping of Stages and Collections

Each approval stage is associated with a collection. In Figure 26-4, there are four stages in the approval.

  • Header Approval is associated with the Expense Header collection.

  • Receipt Verification is associated with the Expense Header collection.

  • Payment is associated with the Expense Header collection.

  • Line Approval is associated with the Expense Lines collection.

A compound approval may consist of multiple stages and then can be modeled in serial or parallel with each other. Each stage consists of list builders to determine the list of approvers.

Optionally, each list builder can be associated with an approval policy, that is, a set of rules. At run time, the appropriate set of approvals are returned based on the list builders used within the stage and on the associated policies.

26.2.4 List Builders

As described in Section 26.2.3, each approval stage consists of list builders to determine the actual list of approvers. The following list builders are supported.

  • Names and Expressions

    Enables you to construct a list using static names, or names coming from XPath expressions.

  • Approval Groups

    Includes predefined approver groups in the approver list. Approval groups can be static or dynamic.

  • Job Level

    Ascends the supervisory hierarchy, starting at a given approver and continuing until an approver with a sufficient job level is found.

  • Position

    Ascends the position hierarchy, starting at a given approver's position and continuing until a position with a sufficient job level is found.

  • Supervisory

    Ascends the primary supervisory hierarchy, starting at the requester or at a given approver, and generates a chain that has a fixed number of approvers in it.

  • Management Chain

    Enables you to construct a list based on management relationships in the corresponding user directory.

    The management chain participant type only supports parallel routing when the first assignee in the management chain is a single user. You cannot specify parallel participants such as a set of users or a group, as the initial assignees in the management chain.

  • Rule-based

    Enables you to model rules that return different list-builder types based on different conditions. For example, if you model a supervisory list builder with rules, the rule can return only the supervisory list builder. If you model a rule-based list builder, the rule can return different list-builder types.

Note:

The Approval Groups, Job Level, Position, and Supervisory list builders are specific to AMX, and are described in detail in Section 26.3.6.3, "How to Model and Configure List Builders."

For information about the Names and Expressions, Management Chain, and Rule-based list builders, see "Creating a Single Task Participant List" in the "How to Assign Task Participants" section in the "Creating the Human Task Definition with the Human Task Editor" chapter in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.2.5 Task Operations

Most of the standard human task operations also are available on AMX-based tasks. Some of the common operations include the following:

  • User-defined outcomes - Business outcomes, such as "Approve" and Reject," that are associated with a task. When a user performs these types of actions, the task is removed from the user's "Inbox" and is marked as completed or moved to the next approver.

  • Delegate - Allows a user to assign a task to another person or role to act on his or her behalf.

  • Escalate - Allows a user or an administrator to escalate a task to the user's supervisor.

  • Reassign - Allows users to transfer a task to another user. From that point on, the new user's hierarchy is used for supervisor or other organization-based approvals.

  • Withdraw - Allows the task initiator or administrator to cancel or withdraw the task after the approval has started.

  • Request for Information - Allows a task approver to request information from any prior participant or the task initiator.

  • Pushback - Allows the task approver to push back the task to the previous approver to review it again.

  • Adhoc Insertions - Allows any task assignee to insert approvers in the generated approval list.

Note:

The position list builder does not allow the approver to delegate, escalate or perform adhoc insertions.

See the section "Acting on Tasks: The Task Details Page," in the chapter "Using Oracle BPEL Worklist Application" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite for a complete list of actions.

26.2.6 Business Rules for Approval

Approvers of a task can be defined either inline in a task definition or by using business rules to specify the list builders that identify the actual approvers of a task. In addition, you can use business rules to specify approver substitution and list modifications. These rules are defined with the help of Oracle Business Rules and can vary between organizations. Typically, however, they are defined by the customer.

Business rules are a combination of conditions and actions. Optionally, priority and validity periods can be defined for these rules. In Human Workflow rules, rule conditions are defined using fact types that correspond to the task, and to the task message and entity attributes (which are XML representations of SDO objects). Rule actions consist of approver list builders and their parameters. Approver list builders move up a particular hierarchy and construct or modify the approver list according to the parameters defined. Approver list builders are implemented as XML (JAXB) fact types.

For more information about these concepts, see the chapter "Overview of Oracle Business Rules" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.2.6.1 List Creation

A list creation policy includes rule conditions and actions that create the list builders.

The following example rules illustrate the configuration of the Supervisory list-builder parameters that create an approver list based on an SDO-based fact type.

Example 26-1 Rule 1

IF
ExpenseItems.ReceiptAmount < 200
THEN
call CreateSupervisoryList( levels:1, 
startingPoint:HierarchyBuilder.getPrinicipal("jstein",-1,"",""), 
uptoApprover:HierarchyBuilder.getPrinicipal("wfaulk",-1,"",""), 
autoActionEnabled:false,autoAction:null, 
responseType:ResponseType.REQUIRED,ruleName:"Rule_1",lists:Lists)

Example 26-2 Rule 2

IF
xpenseItems.ReceiptAmount >= 200
THEN
call CreateSupervisoryList( levels:1,
startingPoint:HierarchyBuilder.getPrinicipal("wfaulk",-1,"",""),
uptoApprover:HierarchyBuilder.getPrinicipal("cdickens",-1,"",""),
autoActionEnabled:false,autoAction:null, 
responseType:ResponseType.REQUIRED,ruleName:"Rule_2",lists:Lists)

For more information, see Section 26.3.6.4.1, "How to Create Lists."

26.2.6.2 Approver Substitution

Users, groups, and application roles appearing in a list can be substituted using list substitution. List substitution is available from Rules Designer and does not require any configuration in JDeveloper.

The following example rule illustrates approver-substitution usage.

Example 26-3 Approver-Substitution Usage

IF
ExpenseItems.ReceiptAmount < new BigDecimal(4000)
THEN
call Substitute(fromId:"jcooper", toId:"jstein", ruleName:"Substituted", 
substitutionRules: SubstitutionRules)

This rule implies that if the expense item amount is less than 4000, then substitute approver "jcooper," if present in the approver list, with approver "jstein."

For more information, see Section 26.3.6.4.2, "How to Make Approver Substitutions."

26.2.6.3 List Modification

Job Level and Position lists can be extended or truncated from rules. List modification is applied after list creation.

The following example rule illustrates list-modification usage.

Example 26-4 List-Modification Usage

IF
ExpenseItems.ReceiptAmount > new BigDecimal(3000)
THEN
Call Extend(ifFinalApproverLevel:3, extendBy:2,ruleName:"Modified",lists:Lists)

This rule implies that if the expense item amount is greater than 3000, and if the final approver in the approver list is of Job Level 3, then extend the approver list by at least two relative levels.

For more information, see Section 26.3.6.4.3, "How to Make List Modifications."

26.3 Designing Approval Management Tasks in Oracle JDeveloper

You design approval management tasks by defining a human task that provides the ability to model multi-stage approvals and determine the appropriate approvers based on approval policies for a business object and the associated HR hierarchy provider.

This section describes the overall modeling process and the specifics of the process you use to model approval management tasks in JDeveloper.

26.3.1 Introduction to the Modeling Process

The modeling process for designing approval management tasks includes the following:

  • Creating a human task definition

  • Creating a task display form using the Human Task Editor

Creating a human task definition includes the following tasks:

  • Specifying general information, such as task title and task-title globalization, outcomes, priority, owner, and category

  • Defining task parameters, including those with service data object (SDO) references

  • Specifying mapped attributes

  • Modeling task routing by specifying stages and list builders, and modeling any business rules that define the list builders

  • Defining escalation and renewal policies

  • Specifying notification settings

  • Modeling any advanced settings like callbacks, security access rules, and restricted assignment

Some of these procedures are discussed in the sections that follow. For information about those that are not discussed, see "Creating the Human Task Definition with the Human Task Editor" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

You also must create a task display using an ADF task flow to display the details of the approval. ADF task flows are used to model the user interface for the task details page. For more information, see "Designing Task Display Forms for Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.3.2 Before You Begin

Before designing approval management tasks, you must satisfy the following prerequisites:

  • You must have deployed SDO services.

  • You must have created a human task service component in which to design the approval task.

26.3.3 Specifying General Information

Some general information, including task title, outcomes, priority, owner, and category, is not specific to AMX.

For more information about these, see "How to Specify the Task Title, Priority, Outcome, and Owner" in the section "Creating the Human Task Definition with the Human Task Editor" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.3.3.1 Task-Title Globalization

The title attribute of the task object contains a user-friendly value that mainly is descriptive in nature. In AMX, the task title can be globalized so that it renders in the user's preferred language.

Title is defined in the *.task file for design time and in the WorkflowTask.xsd file for run time. Currently, the definition of these elements in both of these files are simple xsd:string types. For globalization, the structure and usage of these elements change to accommodate a mechanism that provides translatable, formatted strings.

The design-time metadata for these elements is enhanced to contain a value element and an optional set of parameters. Messages defined as an XPath expression or static have their information stored in the value element and require no parameters. Messages defined that rely on information in a resource bundle have a key stored in the value element with some parameters also defined.

The Human Task Editor provides a mechanism in the Expression Builder to enable the user to specify the resource key and parameters and, at the same time, generate the appropriate design time XML in the taskDefinition.

Figure 26-5 shows the globalization icon in the Human Task Editor.

Figure 26-5 Title Globalization Icon

Title Globalization Icon

The following procedure explains how to add translatable strings. It assumes that a resource bundle has been specified.

  1. Click the icon to display the Edit Translatable Strings dialog.

  2. Select a key from the dropdown list or click the plus sign (+) to create one.

    Figure 26-6 shows the Create a New Key dialog, which displays when the plus sign (+) on the Edit Translatable Strings dialog is clicked.

    Figure 26-6 Create a New Key Dialog

    Create a New Key Dialog
  3. Enter a name, the translatable text, and click OK.

    Figure 26-7 shows the Edit Translatable Strings dialog after a new key has been added.

    Figure 26-7 New Key Added

    New Key Added
  4. Use the Expression Builder to add values.

    Figure 26-8 shows the completed Edit Translatable Strings dialog.

    Figure 26-8 Translatable Text and Values

    Translatable Text and Values

    Note:

    The title value, or a definition of the title value can be set in two places: in the TaskDefinition XML (.task ) file, or in the bpel file. When set in the bpel file, this value takes precedence over the definition in the TaskDefinition. However, the value in the bpel file is not translatable.
  5. Click OK to close the dialog.

26.3.4 Specifying Task Parameters

Specifying task parameters includes the following tasks:

  • Creating SDO references

  • Defining entity parameters

  • Defining collections

26.3.4.1 How to Create Service Data Object (SDO) References

An SDO service can be invoked from workflow services to retrieve the SDO as XML. This invocation is in the form of a SOA web service call. When the SDO service WSDL URL is available, a web service reference should be added using the Create Web Service dialog.

To create a reference, enter the WSDL URL and select the port type from the available port types, as shown in Figure 26-9.

Figure 26-9 Web Service Reference

Web Service Reference

For information about creating SDOs, see "Introduction to References" in the section "Introduction to the SOA Composite Editor" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.3.4.2 How to Define Entity Parameters

The following procedure enables you to accept a service data object (SDO).

  1. Create a Service reference in the composite.

    This allows Fabric to create all the necessary wiring to a specific URL that points to a WSDL.

  2. Define the task payload as external and specify which workflow retrieves the SDO object.

    This creates task parameters representing the input and output to the SDO web service.

  3. Choose Entity.

  4. Define the collection, its XPATH expression, and its keys, as shown in Figure 26-10.

    Figure 26-10 Add Task Parameter: Define Collection

    Add Task Parameter: Define Collection
  5. Set the collection for the stage.

  6. Click OK.

The following procedure enables you to accept static XML.

  1. Provide the XSD where the schema is defined.

  2. Define the task payload parameter as static XML.

  3. Define the collection, its XPATH expression, and its keys.

  4. Set the collection for the stage.

  5. Click OK.

26.3.4.3 How to Define Collections

Collections are references to specific parts of a task message attribute, both static-XML based and entity attributes. After defined, collections can then be associated with stages to identify a stage as acting on a collection.

Defining a collection involves defining the name of the collection and the XPath to the collection element. If the collection is defined for an entity attribute, the keys for the collection element have to be specified as well. Each key has to be a direct child of the collection element. Figure 26-11 shows how collections are defined.

Figure 26-11 Defining Collections

Defining Collections

When you define a collection, JDeveloper automatically determines if it should be repeating element or not. This information is used when collections are associated with a stage. A non-repeating collection can be associated with a singular stage. A repeating collection, when associated with a stage, repeats the stage in parallel for each element in the collection at run time. For information about how the collection information is used in a stage, see Section 26.3.6.1, "How to Model and Configure Stages."

26.3.5 Specifying Mapped Attributes

Human workflow provides task-message attributes that you can use for storing use-case-specific data, such as data extracted from a task's payload. These attributes are also known as flexfield attributes or mapped flexfield attributes.

Mapped flexfield attributes allow payload values to be displayed as columns in the task listing, rather than being hidden in the task details. These values are stored in the human workflow database schema, and you can use them in queries, view definitions, and assignment rule definitions.

There are two types of message attributes:

  • public - Attributes mapped to specific task components at run time. These mappings can be changed at any time, and must be re-created when a task component is redeployed. For more information see the following sections in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite:

    • "How to Map Flex Fields" in the chapter "Using Oracle BPM Worklist"

    • "Introduction to Flex Fields" in the chapter "Introduction to Human Workflow"

  • protected - AMX-specific mappings between a task component and protected flexfield attributes defined at design time. They cannot be changed at run time, and are deployed along with the task component.

    Table 26-1 summarizes the 60 available protected flexfield attributes.

    Table 26-1 Protected Flexfield Attributes

    Name Description

    ProtectedTextAttribute1 - ProtectedTextAttribute20

    Stores text data, up to 2000 characters. The content in these fields is checked during keyword searches in the Worklist Application and through the task-query service.

    ProtectedFormAttribute1 - ProtectedFormAttribute10

    Stores text data, up to 2000 characters. The content in these fields is not checked during keyword searches in the Worklist Application.

    ProtectedURLAttribute1 - ProtectedURLAttribute10

    Stores text data, up to 200 characters. The content in these fields is not checked during keyword searches in the Worklist Application.

    ProtectedDateAttribute1 - ProtectedDateAttribute10

    Stores date information.

    ProtectedNumberAttribute1 - ProtectedNumberAttribute10

    Stores number information.


26.3.5.1 About Attribute Labels and Attribute-Label Mappings

Attribute labels are user-defined properties that allow a meaningful string to be applied to a particular flexfield attribute. The label should reflect the data to store in the attribute. For example, “CustomerName” for “ProtectedTextAttribute1,” “OrderNumber” for “ProtectedNumberAttribute2,” or “OrderDate” for “ProtectedDateAttribute1.”

A flexfield attribute can have multiple attribute labels defined for it. For example, the attribute “ProtectedTextAttribute1” could have the labels “CusomerName,” “PartId” and “EmployeeDepartment”.

Attribute-label mappings for protected attributes are defined at design time in the Human Task Editor. They define a mapping between a particular task component and an attribute label, and also specify how the value of the attribute should be populated. The same attribute label can be re-used in multiple mappings. This allows task components to map data having the same semantic meaning into a common attribute identified by a common label.

For example, PurchaseOrder, LoanRequest and ServiceRequest tasks all could define mappings to the “CustomerName” label. By sharing the same attribute labels across multiple task components, it is possible to construct worklist queries that query multiple task types and display or filter values from the common attribute labels. For example, it would be possible to construct a query that selected PurchaseOrder, LoanRequest, and ServiceRequest tasks, and then displayed the “CustomerName” as a column in the worklist task listing.

For more information, see Section 26.5.2, "How to Create Mapped Attribute Labels."

26.3.5.2 How to Define Attribute-Label Mappings

You define attribute-label mappings in the Mapped Attributes section of the Human Task Editor, as shown in Figure 26-12.

Figure 26-12 Mapped Attributes Section

Mapped Attributes Section

Use the following procedure to define attribute-label mappings:

  1. Click the Add icon to display the Add Mapped Attribute dialog, which is shown in Figure 26-13.

    Figure 26-13 Add Mapped Attribute Dialog

    Add Mapped Attribute Dialog
  2. Perform one of these options:

    • From the dropdown list, select the application server that contains the protected-attribute labels.

    • Click the Add icon to create a connection.

    • Click the Edit icon to edit an existing connection.

    The Attribute dropdown list populates with the available attribute labels from the specified server.

  3. From the dropdown list, select an attribute.

    Note:

    The list does not include any labels for flexfield attributes to which this task component is being mapped.
  4. At the Value field, specify a value using one of these options:

    • Enter an XPath expression that determines the value to be stored in the attribute.

    • Click the icon to create a value in the Expression Builder.

    • Leave the field blank to allow the value to be determined at run time.

    Usually, this XPath expression selects a value from the tasks's payload, but you can specify any valid expression that evaluates to a simple type, such as a string, a date, or a number.

    Be aware that specifying an XPath expression is not mandatory. You may prefer to set the value of the underlying flexfield-attribute value yourself. For example, you can add a custom assign activity to the BPEL process that initiates the task, or manipulate the Task object through the workflow service APIs.

  5. Enter a description. This is optional.

  6. Click OK.

26.3.6 Specifying Routing and Approval Policies

Specifying routing and approval policies includes the following tasks:

  • Modeling and configuring stages

  • Modeling task participants

  • Modeling and configuring list builders

  • Defining business rules

  • Using business rules to specify list builders

  • Using assignment-context information

  • Aggregating task approvals

26.3.6.1 How to Model and Configure Stages

Based on functional needs, you can add and arrange multiple stages in a structure that can be a combination of sequential and parallel stages. This section describes how to create sequential and parallel stages.

Use the following procedure to create a stage:

  1. In the Assignment and Routing section of the Human Task Editor, select a stage.

  2. Click the Add icon, and then select either Sequential stage or Parallel stage from the dropdown list, as shown in Figure 26-14.

    Figure 26-14 Create Stage

    Create Stage

    If you chose to create a sequential stage, the Assignment and Routing section looks like Figure 26-15.

    Figure 26-15 Add Sequential Stage

    Adds Sequential Stage

    If you chose to create a parallel stage, the Assignment and Routing section looks like Figure 26-16.

    Figure 26-16 Add Parallel Stage

    Add Parallel Stage
  3. Double-click the stage you just created, or select the stage and click the Edit icon.

    The Edit dialog displays, as shown in Figure 26-17.

    Figure 26-17 Edit Stage Dialog

    Edit Stage Dialog
  4. Enter a name for the stage.

  5. Choose one of these options:

    • Non Repeating - specifies that there is only one stage in parallel for each element in a collection

    • Repeat Stage in parallel for each item in a collection - specifies that the stage to repeat in parallel for each element in a collection. For example, if a purchase order contain 10 lines, the stage is repeated 10 times in parallel.

  6. From the dropdown list, select a collection.

  7. According to your selection, use one of these options:

    • If you selected Non Repeating, click OK to close the Edit dialog.

    • If you selected Repeat Stage in parallel for each item in a collection, additional options display, as shown in Figure 26-18.

      Figure 26-18 Edit Stage Dialog: Repeat Stage

      Edit Stage Dialog: Repeat Stage

      Do the following:

      • Select a default outcome.

      • Select a consensus percentage.

      • Choose either to trigger the outcome immediately or wait until all the votes are in before triggering the outcome.

      • Click OK to close the Edit dialog.

26.3.6.2 How to Model Task Participants

Inside each stage you either can edit the default task participant or add new task participants. Task participants are assigned based on routing patterns, which can be any of the following:

  • Single

  • Parallel

  • Serial

  • FYI

For information on participant types and assigning task participants to a stage, see "How to Assign Task Participants" in the "Creating Human Task Definitions with the Human Task Editor" section in the "Designing Human Tasks" chapter in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

After selecting a routing pattern, you also must select and model a list builder. This process is discussed in more detail in Section 26.3.6.3, "How to Model and Configure List Builders."

26.3.6.3 How to Model and Configure List Builders

Stage uses a combination of list builders to generate the approver list. For more information, see Section 26.2.3, "Stages" and Section 26.2.4, "List Builders." You can only use each type of list builder only one time per stage. You can arrange these approver list builders in either sequential or parallel order. The order you select governs the order in which those approvers included in approver lists that are generated by list builders are assigned an approval task.

The following list builders are specific to AMX:

  • Approval Groups

  • Job Level

  • Position

  • Supervisory

Note:

For information about modeling other list builders, see "Creating a Single Task Participant List" in the "How to Assign Task Participants" section in the "Creating the Human Task Definition with the Human Task Editor" chapter in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Table 26-2 describes the AMX-specific list builders and the options available to them.

Table 26-2 List-Builder Options

Option Name Description List Builder

Value-based

Specifies constraints to build the list of participants based on provided values.

All Except Position

Rule-based

Specifies constraints to build the list of participants based on rules that are defined in the Rule Editor.

All

Name

The name of the approval group to use.

Approval Groups

Allow Empty Groups

Allows the use of approval groups with no members.

Approval Groups

List Ruleset

Name of the ruleset specifying constraints for building participant list.

All

Starting Participant

The first participant in a list, usually a manager.

Job Level

Position

Supervisory

Top Participant

The last participant in the approval. Approval does not go beyond this participant in a hierarchy.

Job Level

Position

Supervisory

Number of Levels

A positive number specifying the number of levels to traverse for Supervisory, or the number of job level for Job Level and Position. This number can be an absolute value, or a value relative to starting point or creator.

Job Level

Position

Supervisory

Relative to

A positive number specifying the number of levels to traverse for Supervisory, or the number of job level for Job Level and Position. Possible values are: starting point, creator and absolute.

Job Level

Position

Include all managers at last level

If the job level equals that of the previously calculated last participant in the list then it includes the next manager in the list.

Job Level

Utilized Participants

Utilizes only the participants specified in this option from the calculated list of participants. Available options are: Everyone, First and Last manager, Last manager.

Job Level

Position

Auto Action Enabled

Specifies if the list builder automatically acts on task based on the next option.

Supervisory

Job Level

Position

Auto Action

Specifies the outcome to be set. It can be null if auto action is not enabled.

Supervisory

Job Level

Position


If you do not configure the hierarchy provider plug-in, then the position list builder does not work.

When you define a hierarchy extension, if you do not define the property mustUseSpecifiedProvider then its default value is true..

You can configure the Supervisory and Job Level list builders not to throw an exception when there is a problem with the hierarchy plug in. To configure the list builders, you must add the mustUseSpecifiedProvider property to the workflow-identity-config.xml configuration file, and set the value attribute to false.

By default, the workflow-identity-config.xml file does not include the mustUseSpecifiedProvider property. If this property is present and its value is false, then, then the Supervisory and Job Level list builders use the LDAP management chain when there is a problem with the hierarchy plugin.

Example 26-5 shows a workflow-identity-config.xml file that specifies the mustUseSpecifiedProvider property. The value of this property is set to true so that the Supervisory and Job Level builders fail when the hierarchy plug in is not available.

Example 26-5 workflow-identity-config.xml Configuration File

<ISConfiguration xmlns="http://www.oracle.com/pcbpel/identityservice/isconfig"> 
  <configurations> 
    <configuration realmName="jazn.com"> 
      <provider providerType="JPS" name="JpsProvider" service="Identity"> 
        <property name="jpsContextName" value="default"/> 
        <property name="IdentityServiceExtension" 
                  value="HCMIdentityServiceExtension"/> 
      </provider> 
    </configuration> 
  </configurations> 
  <property name="caseSensitive" value="false"/> 
  <property name="mustUseSpecifiedProvider" value="true"/> <!-- Fail when the hierarchy plug ins are not available--> 
  <serviceExtensions> 
... 
</ISConfiguration> 
26.3.6.3.1 How to Model an Approval Groups List Builder

Approval groups are a statically defined or a dynamically generated list of approvers. Approval groups usually are configured by the process owner using the worklist application. Typically, they are used to model subject matter experts outside the transaction's managerial chain of authority, such as human resources or legal counsel, that must act on a task before or after management approval.

Static approval groups are predetermined lists of approvers, while dynamic approval groups generate approver lists at run time. Dynamic approval groups require:

  • delivery of an implementation according to the dynamic approver list interface by the developer

  • registration of the above implementation as a dynamic approval group using the Worklist Application's UI by the IT department

  • availability of the class file in a globally well-known directory that is part of the SOA class path

Note:

In Drop 8, an approval group is a flat list. Serial and parallel patterns no longer are defined.

For more information, see Section 26.5, "Using Approval Management Features of the Oracle BPM Worklist and Workspace."

Two views of the Approval Groups list builder are shown in Figure 26-19 and Figure 26-20.

Figure 26-19 Value-Based Approval Groups List Builder Dialog

Value-Based Approval Groups List Builder

Figure 26-20 Rule-Based Approval Groups List Builder Dialog

Rule-Based Approval Groups List Builder

To model an Approval Groups list builder, first specify if the list builder's attributes are to be value-based or rule-based, and then select the options on the corresponding dialog. For information about the options, see Table 26-2.

26.3.6.3.2 How to Model a Job Level List Builder

The Job Level list builder ascends the supervisory hierarchy, starting at a given approver and continuing until an approver with a sufficient job level is found.

Two views of the Job Level list builder are shown in Figure 26-21 and Figure 26-22.

Figure 26-21 Value-Based Job Level List Builder Dialog

Value-based Job Level List Builder

Figure 26-22 Rule-Based Job Level List Builder Dialog

Rule-based Job Level List Builder

To model a Job Level list builder, first specify if the list builder's attributes are to be value-based or rule-based, and then select the options on the corresponding dialog. For information about the options, see Table 26-2.

26.3.6.3.3 How to Model a Position List Builder

The Position list builder ascends the position hierarchy, starting at the requester's or at a given approver's position, and goes up a specified number of levels or to a specific position.

Figure 26-23 shows a view of the Position list builder.

Figure 26-23 Rule-Based Position List Builder Dialog

Rule-based Position List Builder Dialog

To model a Position list builder, first specify if the list builder's attributes are to be value-based or rule-based, and then select the options on the corresponding dialog. For information about the options, see Table 26-2.

26.3.6.3.4 How to Model a Supervisory List Builder

The Supervisory list builder ascends the primary supervisory hierarchy, starting at the requester or at a given approver, and generates a chain that has a fixed number of approvers in it.

Two views of the Position list builder are shown in Figure 26-24 and Figure 26-25.

Figure 26-24 Value-Based Supervisory List Builder Dialog

Value-based Supervisory List Builder

Figure 26-25 Rule-Based Supervisory List Builder Dialog

Rule-based Supervisory List Builder Dialog

To model a Supervisory list builder, first specify if the list builder's attributes are to be value-based or rule-based, and then select the options on the corresponding dialog. For information about the options, see Table 26-2.

26.3.6.4 How to Use Business Rules to Specify List Builders

Approvers of a task can be defined either inline in a task definition or by using business rules to specify the list builders that identify the actual approvers of a task. In addition, you can use business rules to specify approver substitution and list modifications. These rules are defined with the help of Oracle Business Rules and can vary between organizations. Typically, however, they are defined by the customer.

Business rules are a combination of conditions and actions. Optionally, priority and validity periods can be defined for these rules. In Human Workflow rules, rule conditions are defined using fact types that correspond to the task, and to the task message and entity attributes (which are XML representation of SDO objects). Rule actions consist of approver list builders and their parameters. Approver list builders move up a particular hierarchy and construct or modify the approver list according to the parameters defined. Approver list builders are implemented as XML (JAXB) fact types.

For more information about these concepts, see the chapter "Overview of Oracle Business Rules" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

The sections that follow explain list creation, approver substitution, list modification, and repeating node attributes using Oracle Business Rules.

26.3.6.4.1 How to Create Lists

You can use business rules to define the list builders you want to use. There are two types of business rules:

  • Rules that define the parameters of a specific list builder. In this case, the task routing pattern dialog is modeled to use a specific list builder. The parameters in the list builder come from rules. With this option, rules should return a list builder of the same type as the one modeled in JDeveloper. Figure 26-26 shows a sample configuration.

    Figure 26-26 Specific List-Builder Configuration

    Specific List-Builder Configuration
  • Rules that define the list builder and the list-builder parameters. In this case, the list itself is built using rules. Figure 26-27 shows a sample configuration.

    Figure 26-27 List Builder and Parameters Configuration

    List Builder and Parameters Configuration

In the rule dictionary, rule functions are seeded to facilitate the creation of list builders. These functions are the following:

  • CreateResourceList

  • CreateSupervisoryList

  • CreateManagementChainList

  • CreateApprovalGroupList

  • CreateJobLevelList

  • CreatePositionList

In Rules Designer, model your conditions and, in the action part, "call" one of the functions above to complete building your lists, as shown in Figure 26-28.

Figure 26-28 Modeling Conditions in Rules Designer

Modeling Conditions in the Rules Editor

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

  • startingPoint and topApprover - In JDeveloper, starting point and top approver are specified as users. In Rules Designer, you can build a HierarchyPrincipal as the starting point and top approver. To build a Hierarchy Principal, use the HierarchyBuilder function, as shown in Figure 26-29.

    Figure 26-29 HierarchyBuilder Function

    HierarchyBuilder Function
  • autoActionEnabled and autoAction - From Rules Designer, you can configure that the users resulting from a particular list builder can act automatically on the task.

  • responseType - If the response type is REQUIRED, the assignee has to act on the task; otherwise, the assignment would be converted to an FYI assignment.

  • ruleName - Rule name is used to create an assignment reason. Rule set name + "_" + rule name is used as a key to look up the resource bundle for a translatable reason for assignment. This resource is looked up first in the project resource bundle, then in the custom resource bundle, and last in the system resource bundle.

  • lists - This is an object that is a holder for all the lists that are built. Clicking this option shows a pre-asserted fact 'Lists' object to be used as the parameter.

Figure 26-30 and Figure 26-31 show examples of rules.

Figure 26-30 Example Rules (1)

Example Rules (1)

Figure 26-31 Example Rules (2)

Example Rules (2)

Note:

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

If the rules have the same priority, they are fired in random order, the first one fired is selected.

WARNING:

An improper or incomplete rules definition in a list-creation rule set can cause run-time errors. Errors can be caused by the following:

  • No rule was defined in the rule set.

  • None of the conditions defined in the rule was met.

Ensure that rules are properly defined to handle all conditions.

26.3.6.4.2 How to Make Approver Substitutions

List substitution enables you to substitute users, groups, and application roles that appear in a list. List substitution is available from Rules Designer and does not require any configuration in JDeveloper. In each rule dictionary there is a pre-seeded rule set named "SubstitutionRules." Also in the rule dictionary, a "Substitute" rule function is seeded to configure list substitutions. Table 26-3 lists the "Substitute" functions and their parameters.

Table 26-3 "Substitute" Function Parameters

Parameter Description

fromId

The ID of the user/group/application role from which to substitute.

toId

The ID of the user/group/application role which to substitute to.

ruleName

Used to create an assignment reason. Rule set name + "_" + rule name is used as a key to look up the resource bundle for a translatable reason for assignment. This resource is looked up first in the project resource bundle, then in the custom resource bundle, and last in the system resource bundle.

substitutionRules

An object that is a holder for all the substitutions. Clicking this option shows a pre-asserted fact 'SubstitutionRules' object to be used as the parameter.


Figure 26-32 shows a sample approver-substitution action.

Figure 26-32 Sample Approver-Substitution Action

Sample Approver-Substitution Action
26.3.6.4.3 How to Make List Modifications

List modification enables you to extend or truncate the Job Level and Position list builders from rules. List modification is applied after the list is created. This feature does not require any configuration from JDeveloper. In each rule dictionary there is a pre-seeded rule set named "ModificationRules." This rule set is called only when the Job Level and Position list builders are asserted in the list that created the rule sets. Only the highest priority applicable rule is applied.

In Rules Designer, rule functions are seeded to facilitate list modifications. These functions are the following:

  • Extend

  • Truncate

These rule functions are shown in Figure 26-33.

Figure 26-33 Rule Functions

Rule Functions

Extend and truncate parameters are listed in Table 26-4 and Table 26-5.

Table 26-4 "Extend" Function Parameters

Parameter Description

ifFinalApproverLevel

The level at which final approver is at or below.

extendBy

The number of levels to add to the final job level.

ruleName

Used to create an assignment reason. Rule set name + "_" + rule name is used as a key to look up the resource bundle for a translatable reason for assignment. This resource is looked up first in the project resource bundle, then in the custom resource bundle, and last in the system resource bundle.

lists

An object that is a holder for all the lists that are built. Clicking this option shows a pre-asserted fact 'Lists' object to be used as the parameter.


Table 26-5 "Truncate" Function Parameters

Parameter Description

afterLevel

The level after which to truncate.

ruleName

Used to create an assignment reason. Rule set name + "_" + rule name is used as a key to look up the resource bundle for a translatable reason for assignment. This resource is looked up first in the project resource bundle, then in the custom resource bundle, and last in the system resource bundle.

lists

An object that is a holder for all the lists that are built. Clicking this option shows a pre-asserted fact 'Lists' object to be used as the parameter.


Figure 26-34 shows a sample list-modification action.

Figure 26-34 Sample List-Modification Action

Sample List-Modification Action
26.3.6.4.4 How to Define Repeating-Node Attributes of a Business Rule Condition

When defining a business rule, you can base a rule condition on an attribute that comes from a repeating node. For example, there can be multiple line items for each purchase-order header in a purchase-order scenario. In this case, PurchaseOrderHeader is a non-repeating node, and PurchaseOrderLines is a repeating node.

When defining a rule like the following:

IF line item's amount is <50000, THEN create supervisory list containing jcooper up to two levels

the amount is an attribute of line, that is, it is an attribute of a repeating node.

Use the following procedure to define repeating-node attributes:

  1. In Rules Designer, select Facts.

    A list of facts displays, as shown in Figure 26-35.

    Figure 26-35 Facts List

    Facts List
  2. Edit each appropriate fact to ensure that it is visible, as shown in Figure 26-36.

    Figure 26-36 Edit XML Fact Dialog

    Edit XML Fact Dialog
  3. In Rules Designer, select a rule and then click Add icon (+).

    A rule-definition section displays, as shown in Figure 26-37.

    Figure 26-37 Rule-Definition Section

    Rule-Definition Section
  4. Click the double down arrows to the left of the rule name to show advanced settings, as shown in Figure 26-38.

    Figure 26-38 Advanced Settings

    Advanced Settings
  5. Select Tree Mode, then click <fact type> to display a list of options from which to choose a ROOT, as shown in Figure 26-39.

    Figure 26-39 ROOT Options

    ROOT Options
  6. Define the rule conditions.

26.3.6.5 How to Use Assignment Context

Assignment context is information that is present in the task. During a task's life cycle, it progresses through various assignees. As the context of the task assignees changes, the assignment-context value also changes.

When browsing through the history of a task, you can see the various assignment contexts that the task contained during its life cycle. The Worklist Application uses assignment context when it displays task history.

26.3.6.5.1 Configuring Assignment Context

You configure assignment context in the Add (or Edit) Participant Type dialog in JDeveloper in the following ways:

  • Select the Rule-based option in the Participant Type section.

    In this case, the assignment context is configured implicitly, behind the scenes. The Rules layer resolves the list of assignees based on the rule. As the task progresses through the various assignees, the assignment context value is computed based on the rule.

  • Expand the Advanced section to configure any number of assignment contexts.

    In this case, you can customize assignment contexts by entering your own information into the Assignment Conext fields. Figure 26-40 shows the fields.

    Figure 26-40 Assignment Context Section

    Assignment Context Section

    Table 26-6 contains field descriptions.

    Table 26-6 Assignment-Context Field Descriptions

    Field Description

    Name

    Assignment-context name, which can be whatever you choose. This is a string field.

    Value

    Assignment-context value, which can be whatever you choose. This is a string field.

    Type

    Associated with the Value field.

    Possible values are:

    • By name - A user-provided Value parameter.

    • By Expression - A Value parameter created by the Expression Builder.


26.3.6.6 How to Aggregate Task Approvals

A task can be assigned multiple times to one user during the task life cycle. The Human Task Editor enables you to configure how often a user sees the task.

The following procedure explains how to configure task-approval aggregation.

  1. In the Assigmnent and Routing Policy section of the Human Task Editor, select a stage and click the pencil icon to the right of "Task goes from starting to final participant."

  2. In the Configure Restricted Assignment dialog, select the Assignment tab.

    Figure 26-41 shows the tab selected in the dialog.

    Figure 26-41 Configure Restricted Assignment Dialog

    Configure Restricted Assignment Dialog
  3. Select a task-aggregation option from the dropdown list:

    • None - Indicates there is no approval aggregation, which means the user sees the task as many times as it is assigned to him or her.

    • Stage - A user sees the task only one time in a stage.

    • Task - A user sees the task only one time in the task life cycle.

  4. Click OK.

When the task is aggregated and assigned to a user, the task has a collection table in the Worklist Application that diplays all the collections in the task the user is approving. After the user performs an action, the action is recorded and then replayed to all the user's assignments, either in the stage or task.

An aggregated task is a proxy task for all the regular assignments. Only the following actions are permitted on an aggregated task:

  • Custom actions like approve/reject

  • Reassign

  • Acquire

The user can perform additional actions on the individual tasks, such as escalate, but those actions are not be recorded and played back for other tasks. Those actions are treated as actions on an individual task and not on an aggregated task.

26.3.7 Defining Escalation and Renewal Policies

This feature is not specific to AMX. For more information, see "Designing Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Note:

Escalation is only applicable to management chain.

26.3.8 Specifying Notification Settings

This feature is not specific to AMX. For more information, see "Designing Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.3.9 Using Advanced Settings

Using advanced settings includes the following tasks:

  • Specifying callbacks for notes, attachments, and validation

  • Defining security access rules

26.3.9.1 How to Add Callbacks for Notes, Attachments, and Validation

Callbacks are mechanisms that allow you to do the following:

  • Access notes and attachments associated with business objects from external content-management systems or custom schemas

  • Perform custom validation of workflow tasks at various points in a task life cycle by defining validation logic for each task action

Use the following procedure to add callbacks:

  1. From the Task Editor, expand the Advanced Settings section.

  2. Click Configure Callbacks....

    The Callback Details dialog opens, as shown in Figure 26-42.

    Figure 26-42 Callback Details Dialog

    Callback Details Dialog
  3. Click the Other Callbacks tab.

    Additional entry fields display, as shown in Figure 26-43.

    Figure 26-43 Other Callbacks Tab

    Other Callbacks Tab
  4. Use one of these options:

    • In the Comments Callback field, enter the appropriate Java class for the notes callback.

    • In the Attachments Callback field, enter the appropriate Java class for the attachments callback.

    • In the Validation Callback field, enter the appropriate Java classes, separated by commas, for the validation callback.

  5. Click OK.

26.3.9.2 How to Define Security Access Rules

Access rules restrict the actions that a user can perform by overriding default actions and permissions. At run time, the system checks every operation in a task against any defined access rules to see if a user is permitted to make changes, such as approve, add, delete, and so on If the user is not permitted to make changes, the operation errors out with an appropriate error message.

In AMX, access rules can be defined for Groups and Application Roles. For example, if an access rule is defined to restrict the "Withdraw" action for a group called Operators, then any user belonging to that group is not allowed to withdraw the task. Similarly, if an access rule is defined to restrict the "Withdraw" action for an application role called SOAAuditViewer, then any user who has been granted the SOAAuditViewer application role is not allowed to withdraw the task.

To define a security access rule:

  1. Expand the Advanced Settings section of the Human Task Editor, and locate the Override default access to task content and actions option, as shown in Figure 26-44.

    Figure 26-44 Access Rules Option

    Access Rules Option
  2. Click Configure Visibility....

    The Configure Task Content Access dialog displays, as shown in Figure 26-45.

    Figure 26-45 Configure Task Content Access Dialog (1)

    Configure Task Content Access Dialog (1)
  3. Click the Task Content or Task Actions tab to select it. (This procedure assumes the Task Content tab has been selected.)

  4. Select a task to edit and click the Edit icon.

    A second Configure Task Content Access dialog displays.

  5. From the dropdown list, select Group, as shown in Figure 26-46.

    Figure 26-46 Configure Task Content Access Dialog (2)

    Configure Task Content Access Dialog (2)

    The Identity Lookup dialog displays.

  6. Select an application server, realm, and appropriate groups, as shown in Figure 26-47.

    Figure 26-47 Identity Lookup Dialog

    Identity Lookup Dialog
  7. Click OK.

    The selected groups are added to the access rule, as shown in Figure 26-48.

    Figure 26-48 Groups Added to Access Rule

    Groups Added to Access Rule
  8. Click OK to close the dialog.

Use the same procedure to define access rules for Application Groups, with the following exceptions:

  • Click the Task Actions tab to select it.

  • Select Application from the dropdown list.

  • Select application roles to include in the access rule from the Select an Application Role dialog, as shown in Figure 26-49.

    Figure 26-49 Select an Application Role Dialog

    Select an Application Role Dialog

For more information, see the section "Specifying Access Rules on Task Content" in the chapter "Designing Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.4 Using the End-to-End Approval Management Samples

Table 26-7 shows the end-to-end workflow examples included in the ORACLE_HOME\samples\soa-infra\workflow directory.

In addition to the demonstration features listed in the table, all samples show the use of worklist applications and workflow notifications.

Table 26-7 End-to-End Samples

Sample Description Location

Expense Line Approval

Illustrates line-level approval with approval policy defined.

ORACLE_HOME\samples\soa-infra\workflow\amx \amx-101-expense-line

Employee Hiring

Illustrates ad-hoc insertion capabilities for an approval having two stages - Approval Group List Builder in "Order" voting regime and a Supervisory list builder.

ORACLE_HOME\samples\soa-infra\workflow\amx \amx-102-hiring-approval-group

Purchase Order Approval

Illustrates the Purchase Order approval scenario with header and line-level approvals.

ORACLE_HOME\samples\soa-infra\workflow\amx \amx-103-purchaseOrder-2dimensions

Employee Transfer

Illustrates the Employee Transfer scenario from one team to another through parallel job level participants.

ORACLE_HOME\samples\soa-infra\workflow\amx\amx-104-employee-transfer

Self Approval

Illustrates how to implement self-approval through auto-action rules.

ORACLE_HOME\samples\soa-infra\workflow\amx\amx-105-self-approval

Position List Builder

Illustrates the use of the Position list builder.

ORACLE_HOME\samples\soa-infra\workflow\amx\ amx-108-position-list


26.5 Using Approval Management Features of the Oracle BPM Worklist and Workspace

The Oracle Business Process Management (BPM) Worklist enables users to perform various approval-management tasks, including the following:

26.5.1 How to Use Task Forms

The human workflow service creates tasks for users to interact with the business process. Each task has two parts—the task metadata and the task form. The task form is used to display the contents of the task to the user's worklist.

The task form is designed in JDeveloper with Oracle Application Development Framework (Oracle ADF). For more information, see "Designing Task Display Forms for Human Tasks," in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Oracle BPEL Worklist Application displays all worklist tasks that are assigned to a user or a group. When a worklist user drills down into a specific task, the task display form renders the details of that task. For example, an expense approval task may show a form with line items for various expenses, and a help desk task form may show details such as severity, problem location, and so on.

The sections that follow describe the task form in the Worklist Application that users with administrator rights use to manage tasks. Figure 26-50 shows what a task form looks like.

Figure 26-50 Task Form in the Worklist Application

Task Form in the Worklist Application

26.5.1.1 Header View

The Header view, shown in Figure 26-51, is created in JDeveloper using the header drop handler.

Figure 26-51 Header

Header

By default, the drop handler includes the Header fields listed in Table 26-8. However, you can include or remove any of the fields based on the use case.

Table 26-8 Header Fields

Field Description

Task Number

The number automatically assigned to the task.

State

The current status of the task.

Outcome

The user outcome. For examaple, if the user clicks Approve, the Outcome field displays "Approve."

Priority

The priority level assigned to the task.

Creator

The user who originated the task.

Created

The task's creation date.

Updated

The date the task was last updated.

Expires

The date the task expires.

Assignees

The name(s) of the administrator(s) to whom the task has been assigned.

Acquired By

The name of the user who claims the task before any action is taken on it.

Due Date

The date by which the task is due.


The Header also contains custom and system actions. Custom actions are those that depend on task metadata outcomes. For example, if the metadata contains Approve and Reject outcomes, then Approve andReject appear in the Header as custom actions. If the metadata contains more than two outcomes, then the custom actions appear in the Header as a dropdown list instead of separate buttons. In Figure 26-51, Approve and Reject appear as separate buttons. This indicates that the task metadata includes Approve and Reject outcomes.

System actions, such as Escalate, Suspend, and Resume, always appear in a dropdown list. The actions that appear depend on what the user is doing. For example, after a task has been initiated it can be withdrawn. Subsequently, if a user logs into the Worklist Application to view the details of an initiated task "Withdraw" appears in the list containing the available actions.

Table 26-9 lists all the actions the administrator can perform from the Header and their descriptions.

Table 26-9 Header Actions

Action Description

Reject

Enables the administrator to reject the task.

Approve

Enables the user to approve the task.

Delegate

Enables the administrator to assign a task to another person to act on his or her behalf.

Reassign

Enables the administrator to transfer a task to another administrator.

Suspend

Enables the administrator to suspend the task to work on it at a later time.

Resume

Enables the administrator to resume a suspended task.

Withdraw

Enables the administrator to withdraw an initiated task.

Escalate

Enables the administrator to escalate a task to a supervisor.

Delete

Enables the administrator to delete a task. Appears for all "To Do" tasks.

Purge

Enables the administrator to purge a task. Appears for all "To Do" tasks.

Go

Enables the administrator to "go" to the action selected from the dropdown list.

Save

Enables the administrator to save the task.


26.5.1.2 Task Payload View

The Task Payload view, shown in Figure 26-52, displays the details of the task parameters and provides the ability to update them. Any parameter that has been designed based on SDOs also can be viewed here. While the values of the general parameters are based on what was passed to the task or update by any user, the values of the SDO-based parameters reflect the current value of the business object as it was updated in the underlying application.

Figure 26-52 Task Payload

Task Payload

For more information, see "Designing Task Display Forms for Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.5.1.3 Task History View

The Task History view, shown in Figure 26-53, provides a graphical and tabular view of events in the task life cycle. In addition, if the Edit Approver Configuration option was selected in the designer, special controls in the tabular view that allow futire approvers to be edited are available. Any approver added manually can be deleted and new approvers can be added. Approver changes made in the tabular view are immediately reflected in the graphical view. When the task is saved or a custom action, such as approve or reject, is performed on the task, all approver-related changes also are saved.

Figure 26-53 Task History

Task History

If the Allow all participants to edit future participants option is selected while configuring the approval task, the history region displays additional actions that allow a participant to edit the future participants list. For more information, see Section 26.3.3, "Specifying General Information."

Figure 26-54 shows the addition of the Apply and Reset buttons.

Figure 26-54 Task History - Additional Actions

ask History - Additional Actions

Table 26-10 describes all additional approval-task actions.

Table 26-10 Edit Future Participants List Actions

Action Description

Add

Enabled when the user selects a future participant. When this option is selected, the Add Participant dialog opens and the user can insert ad- hoc participants.

Edit

Enabled when the user selects a participant that has been inserted ad hoc. When this option is selected, the Edit Participant dialog opens and user can move the position of an inserted participant.

Delete

Enabled when the user selects a participant that has been inserted ad hoc. When this option is selected, the corresponding participant is deleted.

Apply

Persists the edits to the future participant list.

Reset

Resets the edits from the future participant to a system-generated list.


Table 26-11 lists the actions the administrator can perform from the Task History view and their descriptions.

Table 26-11 Task History Actions

Action Description

Task Snapshot

Displays the task details for the selected version.

Full task actions

If checked, displays the full task-action history. If unchecked, displays only action history. By default, the box is unchecked.

All parent tasks

If checked, displays the parent task in a sub-task view. If unchecked, displays only the sub-task history. By default, the box is checked.

Show future approvers

If checked, displays the future approver with history. By default, the box is unchecked.


26.5.1.4 Comments and Attachments View

The Comments and Attachments view, shown in Figure 26-55, is created in JDeveloper using the task data control drop handler. It includes a text-entry field in which to enter comments about the task, and the functionality to attach supporting documents.

Figure 26-55 Comments and Attachments

Comments and Attachments

26.5.2 How to Create Mapped Attribute Labels

Mapped attributes are those that you can use for storing use-case-specific data, such as data extracted from a task's payload. You can view and create mapped attribute labels on the server using the Worklist Application.

Note:

You must have the workflow.mapping.protectedFlexfield privilege to create protected flexfield attributes. The default administrative user, weblogic, has this privilege.

For more information, see Section 26.3.5, "Specifying Mapped Attributes."

To view attribute labels:

  1. From the BPM Worklist Application main page, click the "Administration" link in the upper-right corner of the page.

  2. In the Administration pane, click the "Protected Flex Fields" link. A page similar to the one shown in Figure 26-56 displays.

    Figure 26-56 Flexfield Mapping: Protected

    Flexfield Mapping: Protected

    The page displays a list of existing attribute labels. You can filter the list by selecting an attribute type from the dropdown list. Clicking a specific label displays the list of mappings the attribute uses in the Details panel.

To create an attribute label:

  1. Click the Add (+) button. The Create Label dialog displays, as shown in Figure 26-57.

    Figure 26-57 Create Label Dialog

    Create Label Dialog
  2. Select an attribute type and task attribute from the dropdown lists.

  3. Enter a unique label name and a description.

  4. Click Create. The label is created and is made available for mapping in task components.

To delete an attribute label:

To delete an attribute label, first select it from the list of attribute labels. Then click the Delete (-) button.

Note:

Attribute labels can be deleted only if they are not used in any mappings.

26.5.2.1 Importing and Exporting Attribute-Label Definitions

If attribute labels have been defined on one server and must be re-created on another, you can use the user metadata migration utility to export a list of protected attribute labels from the server on which they were defined to an XML file. The utility then can deploy the attribute labels from this file to a new server. This eliminates the necessity to manually re-create the attribute labels manually in the Worklist Application. For more information, see Section 26.6, "Using the User Metadata Migration Utility."

26.5.2.2 Internationalizing Attribute Labels

When attribute labels are displayed to end users, for example in the task listing page of the Worklist Application, the label name specified when the label was created is used. In cases where users of different nationalities may see the label, a translation of the label name appropriate to the Worklist Application user's locale can be displayed instead. Translations of attribute labels can be customized using the WorkflowLabels.properties resource bundle.

For more information, see "Internationalization of Attribute Labels" in the chapter "Introduction to Human Workflow Services" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

26.5.3 Administering Approval Groups

An approval group consists of a name and a predefined set of users configured to act on a task in a certain pattern. This pattern is similar to a human workflow routing slip pattern where users can act on tasks in serial or parallel. An approval group also can contain a nested approval group in the pattern.

The name of an approval group is needed when specifying the approval group list builder as discussed in Section 26.3.6.3.1, "How to Model an Approval Groups List Builder." The pattern configured in the approval group is used by default to order the users who must act on the task. However, when creating the list builder, the default pattern can be overridden by specifying the voting regime.

The sections that follow describe the Worklist Application user interface that enables users with administrator rights to manage approval groups.

26.5.3.1 How to View Approval Groups

From the Oracle BPM Worklist home page, click the Approval Groups tab. A page similar to the one shown in Figure 26-58 appears.

Figure 26-58 Worklist Application: Approval Groups Tab

Worklist Application: Approval Groups Tab

The graphic shows that the "DisbursementTeam" approval group has two users, "bpalmer" and "rjames." The users act on a task in a specific sequence configuration.

26.5.3.2 How to Search for an Approval Group

You can search for an approval group either by user name or group name.

To search by user name:

  1. In the left navigation pane, select User from the dropdown list.

  2. Enter the full username for the user in the text-entry field. (You also can perform a wildcard search (*) with a partial username.)

  3. Click the action (>) button.

    A list of all approval groups to which the user belongs displays in the left navigation pane, as shown in Figure 26-59.

    Figure 26-59 User Name Search Results

    User Name Search Results

Clicking on the approval group name refreshes the details pane on the right with the structure of that group.

To search by group name:

  1. In the left navigation pane, select Group from the dropdown list.

  2. Enter the full group name in the text-entry field. (You also can perform a wildcard search (*) with a partial group name.)

  3. Click the action (>) button.

    A list of all matching approval groups displays in the left navigation pane, as shown in Figure 26-59.

    Figure 26-60 Group Name Search Results

    Group Name Search Results

Clicking on the approval group name refreshes the Details pane on the right with the structure of that group.

26.5.3.3 How to Add a Static Approval Group

The following procedure explains how to add a static approval group.

  1. In the left navigation pane, click the Add (+) button and select Create Static from the dropdown list, as shown in Figure 26-61.

    Figure 26-61 Create Approval Group: Select Static Group

    Create Approval Group: Select Static Group

    A page similar to the one shown in Figure 26-62 appears.

    Figure 26-62 Create Static Approval Group: Details

    Create Static Approval Group: Details
  2. Enter a new name for the group.

  3. Click Apply.

    You now can add members to the new approval group.

26.5.3.4 How to Add a New Member to a Static Approval Group

Members of a static approval group either can be users or other approval groups. The following procedure explains how to add a new user member to an approval group.

  1. From the page shown in Figure 26-62, click the Add (+) icon.

    The other icons enable you to edit, delete, and reorder members in the approval sequence.

    The Add to Group pop-up dialog appears, as shown in Figure 26-63.

    Figure 26-63 Add to Group Dialog

    Add to Group Dialog
  2. Select User.

  3. Select a user using one of these options:

    • Enter a full user name and click OK.

      The dialog closes and the new member appears in the Members section of the Details pane.

    • Click the magnifying glass to search for a user.

      If you click the magnifying glass, an Identity Browser pop-up dialog appears, as shown in Figure 26-64.

      Figure 26-64 Identity Browser: Add User

      Identity Browser: Add User
  4. Select Users from the dropdown list.

  5. Enter a full name in the text-entry field and click Search. (You also can perform a wildcard search (*) with a partial user name.)

    The Identity Browser dialog refreshes and the search results appear, as shown in Figure 26-65.

    Figure 26-65 Identity Browser: Search Results

    Identity Browser: Search Results
  6. Choose a user from the list.

    The details for that user appear in the Details section of the dialog.

  7. Click OK.

  8. Click OK again to close the Add to Group dialog.

    A node representing the selected user appears in the approval group structure in the Members section of the Details pane, as shown in Figure 26-66.

    Figure 26-66 Approval Group Structure

    Approval Group Structure

You can add more members to the approval group by repeating the steps above. The resulting approval group structure looks similar to the one shown in Figure 26-67.

Figure 26-67 Approval Group Structure: Multiple Members

Approval Group Structure: Multiple Members

26.5.3.5 How to Delete a Member from an Approval Group

The following procedure explains how to delete a member from an approval group.

  1. Choose the appropriate member node from the approval group structure.

  2. Click the Delete icon.

    The approval group structure refreshes and the member node has been deleted.

26.5.3.6 How to Move an Approval Group's Members

The following procedure explains to to change the sequence order of an approval group.

  1. Choose a member node to move.

  2. Use the Push Member Up (^) and Push Member Down (v) icons to move the member to the desired location.

Figure 26-68 and Figure 26-69 show the positions of rjames and jstein before and after a move.

Figure 26-68 Before Move

Before Move

Figure 26-69 After Move

After Move

26.5.3.7 How to Nest Approval Groups

The following procedure explains how to nest approval groups, that is, add an approval group to another approval group.

  1. Click the Add icon.

  2. Select Approval Group.

  3. Click the magnifying glass.

    Another Add to Group dialog appears.

  4. From the left pane, choose the approval group you want to add.

    Its structure appears in the right pane, as shown in Figure 26-70.

    Figure 26-70 Choose Approval Group to Nest

    Choose Approval Group to Nest
  5. Click OK.

  6. Click OK again to close the Add to Group dialog.

    The new approval group appears in the approval group's structure, as shown in Figure 26-71.

    Figure 26-71 Nested Approval Groups

    Nested Approval Groups

26.5.3.8 How to Rename an Approval Group

The following procedure explains how to rename an approval group.

  1. Enter the new name of the approval group in the Name field.

  2. Click Apply.

The name change also is reflected in other approvals groups in which this approval group is nested.

26.5.3.9 Using Dynamic Approval Groups

Dynamic Approval Groups provide a way to create approval groups through a custom Java class at run time. This requires the following:

  • Writing a custom dynamic approval group class for the custom implementation by the developer

  • Registering the custom dynamic approval group using the worklist apps UI by the IT department

  • Making the class file available in a globally well known directory that is part of the SOA class path

26.5.3.9.1 How to Write a custom Dynamic Approval Group Class

to define a dynamic approval group, the customer must define an implementation class using the interface file IDynamicApprovalGroup.java, defined by AMX for dynamic approval groups in the package oracle.bpel.services.workflow.task. This contains only one public method that gets the approval group members. The Task object is the only input parameter. The primary key list can be obtained from the task task/systemAttributes/collectionTarget.

Example 26-6 Implementation Class

************** IDynamicApprovalGroup.java ******************

public interface IDynamicApprovalGroup {

    /**
        *  Get members of this dynamic approval group 
        *  @param task Property bag containing information required to generate 
             the approver list
        *  @return list of IApprovalListMember including sequence, member, member_
             type; null for empty group
        *  The primary key list can be obtained from task:
             task/systemAttributes/collectionTarget
       */

   public List getMembers(Task task )
       throws WorkflowException; 
}
**********************************************************

Figure 26-72 shows a code snippet for a sample dynamic approval group class.

Figure 26-72 Code for Dynamic Approval Group Class

Code for Dynamic Approval Group Class
26.5.3.9.2 How to Register the custom Dynamic Approval Group Class

For more information, see Section 26.5.3.9.4, "How to Add a Dynamic Approval Group."

26.5.3.9.3 How to Make the custom Dynamic Approval Group Class Available

To make the class file available in a globally well-known directory that is part of the SOA class path, you must place your class files in the following WebLogic Server directory:

$BEAHOME/AS11gR1SOA/soa/modules/oracle.soa.ext_11.1.1/classes

For example, for the Java class oracle.apps.DynamicAG , the path would be $BEAHOME/AS11gR1SOA/soa/modules/oracle.soa.ext_11.1.1/classes/oracle/apps/DynamicAG.class. You must restart WebLogic Server after you place your class files there.

26.5.3.9.4 How to Add a Dynamic Approval Group

The following procedure explains how to add a dynamic approval group approval group.

  1. In the left navigation pane, click the Add (+) button and select Create Dynamic from the dropdown list, as shown in Figure 26-73

    Figure 26-73 Create Approval Group: Select Dynamic Group

    Create Approval Group: Select Dynamic Group

    A page similar to the one shown in Figure 26-74 appears.

    Figure 26-74 Create Dynamic Approval Group: Details

    Create Dynamic Approval Group: Details
  2. Enter a name and a class for the group.

  3. Click Apply to save the group.

26.5.3.10 How to Delete an Approval Group

The following procedure explains how to delete an approval group.

  1. In the left navigation pane, choose the approval group you want to delete.

  2. Click the Delete (-) button, as shown in Figure 26-75.

    Figure 26-75 Delete Approval Group

    Delete Approval Group

    A confirmation dialog appears.

  3. Click OK.

    The approval group is deleted.

Note:

If the approval group you deleted is nested in other approval groups, it also is deleted from those parent groups.

26.5.4 Using Task Configuration

Task Configuration in the Worklist Application lets business users and administrators review the rules that have been configured out of the box by the workflow designer. These pre-defined rules can be modified to customize the approval flow for a specific customer at any point in time based on the customer's applicable corporate policies.

For example, if a corporate policy requiring two levels of approvals for expense amounts greater than 1000 is changed to a policy requiring three levels, the customer can use this web-based application to change the rule rather than having its IT department first modify the rule in the underlying process and then deploy it again. Any change made to the rule is applied starting with the next instance; instances that are in progress use the current rule definitions.

Task Configuration enables you to edit the event driven and data-driven rules associated with an approval flow at run time; that is, when the workflow is deployed. The Event Driven and Data Driven tabs are accessible by clicking the main Task Configuration tab of the Administration section of the application. A screen similar to the one shown in Figure 26-76 displays.

Figure 26-76 Task Configuration: Main Tab

Task Configuration: Main Tab

The Tasks to be configured panel on the left lists all workflow tasks that have been configured to use approval-flow rules. It also provides a search capability. In the view mode, the right panel displays the default configuration and rules for overriding the approval-flow list builder configuration. The rule configurations are displayed based on the stages defined in the approval flow.

26.5.4.1 How to Edit Event-Driven Settings

This section contains information about event-driven settings, that is, task metadata.

Figure 26-77 shows an event-driven task configuration page.

Figure 26-77 Task Configuration: Event Driven

Task Configuration: Event Driven

Use the following procedure to edit an event-driven setting.

  1. Under the Task Configuration tab, click the Event Driven tab.

  2. In the Tasks to be configured pane, select a task. Then click the Edit (pencil) icon.

    The main page refreshes in edit mode, as shown in Figure 26-78.

    Figure 26-78 Task Configuration: Event Driven, Edit Mode

    Task Configuration: Event Driven, Edit Mode
  3. Make your changes and click Apply to save them

  4. Click Deploy to deploy your changes.

WARNING:

An improper or incomplete rules definition in a list-creation rule set can cause run-time errors. Errors can be caused by the following:

  • No rule was defined in the rule set.

  • None of the conditions defined in the rule was met.

Ensure that rules are properly defined to handle all conditions.

26.5.4.1.1 How to Specify Routing Settings

The Event Driven tab contains a limited set of the routing options available in the Human Task Editor.

Approval aggregation requirements can be any of the following, as shown in Figure 26-79:

  • None

  • Once per task

  • Once per stage

Figure 26-79 Routing Settings

Routing Settings
26.5.4.1.2 How to Define Expiration and Escalation Policies

Defining expiration and escalation policies in the Worklist Application is very similar to how it is done in the Human Task Editor. For more information, see the section "How to Escalate, Renew, or End the Task" in the chapter "Designing Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Figure 26-80 Expiration and Escalation Policies

Expiration and Escalation Policies
26.5.4.1.3 How to Specify Notification Settings

Creating or updating notification settings for a task in the Worklist Application s very similar to how it is done in the Human Task Editor. For more information, see the section "How to Specify Participant Notification Preferences" in the chapter "Designing Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

Figure 26-81 Notification Settings

Notification Settings
26.5.4.1.4 How to Allow Task Access

Access-rule settings can be set to control the actions a user can perform, and is very similar to how it can be done in the Human Task Editor. Content and action permissions can be specified based on the logical role of a user, such as creator (inititator), owner, assignee, and reviewers.

For more information, see Section 26.3.9.2, "How to Define Security Access Rules."

Figure 26-82 Task Access

Task Access

26.5.4.2 How to Edit Data-Driven Settings

Use the following procedure to edit a data-driven setting, that is, a rule or condition.

  1. Under the Task Configuration tab, click the Data Driven tab.

  2. In the Tasks to be configured pane, select a task. Then click the Edit (pencil) icon.

    The right panel refreshes in edit mode, as shown in Figure 26-83 and Figure 26-84.

    Figure 26-83 Task Configuration: Data Driven, Edit Mode (1)

    Task Configuration: Data Driven, Edit Mode (1)

    Figure 26-84 Task Configuration: Data Driven, Edit Mode (2)

    Task Configuration: Data Driven, Edit Mode (2)
  3. Update the rule name.

    The rule name appears as the rule reason in the history graph. If you defined a resource bundle, then the rule name is used to obtain the resource bundle and a translated text is displayed.

  4. Do any of the following:

    • Add

    • Update

    • Delete

    • Change assertions (which depend on the type of list builder for which the rule has been configured)

    • Add variables

  5. Click Apply when you have finished making your changes.

    The changes are saved to the rule definitions in the rules dictionary.

  6. Click Deploy to deploy the changes.

Section 26.5.4.2.1, "How to Add a Variable" and Section 26.5.4.2.2, "How to Define Conditions" discuss additional editing tasks.

26.5.4.2.1 How to Add a Variable

Use the following procedure to add a variable.

  1. Click Add variable.

    The Add Variable window displays, as shown in Figure 26-85.

    Figure 26-85 Add Variable Window with "Type" Dropdown List

    Add Variable Window with "Type" Dropdown List
  2. Enter a name for the variable.

  3. Click the down arrow to select a variable type from the dropdown list.

    The types displayed in the list correspond to those that are available in the rule dictionary (built-in and others that have been registered).

  4. Enter a value.

  5. Click OK.

    The variable can now be used to define conditions.

26.5.4.2.2 How to Define Conditions

You can set the left and right sides of a condition by selecting operands from condition browsers. Clicking the magnifying glass icon displays the browsers. Figure 26-86 shows the left condition browser.

Figure 26-86 Left Condition Browser

Left Condition Browser

The operator for comparing the operands of the condition changes based on the type of operand selected for the left side of the condition. Figure 26-87 shows the right condition browser.

Figure 26-87 Right Condition Browser

Right Condition Browser

You also can define more complex conditions using the Expression Builder.

For more information, see the section "Creating ADF Data Binding EL Expressions" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework. Also, see the section "Creating EL Expressions" in Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework.

26.5.4.2.3 How to Define Assertions

You can specify an assertion by selecting the appropriate rule function from the dropdown list.

26.5.5 Using the Task Listing Region

The task listing region in the BPM Worklist is available as standalone, reusable component that you can use to display a list of tasks in an embedding application. It is provided as an ADF library that you can include in the embedding application.

Figure 26-88 shows the task listing region.

Figure 26-88 Task Listing Region

Task Listing Region

26.5.5.1 How to Embed the Task Listing Region in an Application

The task listing region is exposed as a portlet and can be embedded in other applications.

The consumer application is developed using JDeveloper. The task list portlet then is embedded in a page in the consumer application. At run time, the login credentials passed to the consumer application are propagated to the WSRP producer and the portlet content is displayed on the page. The standalone task list portlet is deployed on the WLS PORTLET server, which would contact the remote WLS SOA server for workflow services. A separate portlet ear is provided for deployment on the portlet server.

Any consumer can use the task list portlet after registering to the portlet producer (WLS Portlet server).

To embed the task listing region in an application:

The task list ADF library adflibTaskListTaskFlow.jar file must be in the class path. This jar is available in JDeveloper in the BPM Worklist Components library.

  1. In JDeveloper, create a new Fusion Web Application(ADF) and provide a name; for example, "TaskListTaskFlowSample."

  2. Add adflibTaskListTaskFlow.jar task flow in the project's class path.

  3. Add the following libraries from Libraries and Classpath to the class path:

    • BPM Worklist Components

    • BPM Workflow

    • WSRP Container

  4. If you run your application on a non-SOA server, perform the steps listed in Section 26.5.5.1.1, "How to Deploy a Human Task Detail Page on a Remote Non-SOA Server." Otherwise, continue to step 5.

  5. Create a .jspx page. You can name it something like "testSample.jspx."

  6. Choose adflibTaskListFlow.jar from the Component Palette, and drag Tasklist-flow-definition onto the.jspx page as a region.

    The Edit Task Flow Binding dialog displays.

    Figure 26-89 Edit Task Flow Binding Dialog

    Edit Task Flow Binding Dialog

    Example 26-7 shows what is created in testSamplePagedef.xml.

    Example 26-7 testSamplePagedef.xml Code

    <taskFlow id="taskListtaskflowdefinition1"
       taskFlowId="/WEB-INF/taskList-task-flow-definition.xml
         #taskList-task-flow-definition"
       xmlns="http://xmlns.oracle.com/adf/controller/binding">
      <parameters>
        <parameter id="federatedMode" value="true"
           xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
        <parameter id="showServerColumn" value="true"
           xmlns="http://xmlns.oracle.com/adfm/uimodel"/>
      </parameters>
    </taskFlow>
    
  7. Add the following shared libraries to weblogic-application.xml:

    <library-ref>
        <library-name>oracle.soa.workflow</library-name>
    </library-ref>
    

    Note:

    Add the libraries appropriately if you have oracle.soa.workflow.wc installed on your server.
  8. From the Edit WAR Deployment Profile Properties dialog, select the following:

    • adflibTaskListTaskFlow.jar

    • adflibWorklistComponents.jar

    • wsrp-container.jar.

  9. From the Level menu, choose Secure > Configure ADF Security to secure the application, as shown in Figure 26-90.

    Figure 26-90 Securing the Application

    Securing the Application
  10. From the Configure ADF Security dialog, do the following:

    1. Select ADF Authentication.

    2. Select HTTP Basic Authentication.

    3. Click Finish.

  11. If you are using the task flow in the federated mode, see Section 26.5.5.1.2, "How to Use the Task Flow in the Federated Mode," for additional steps you must perform. Otherwise, continue to step 12.

  12. Create an EAR deployment profile, build an ear and deploy it.

  13. Go to the following URL: http://server:port/TaskListTaskFlowSample-ViewController-context-root/faces/testSample.jspx.

  14. From the popup dialog that displays, log in as any user. The task list for that user displays.

    The dropdown list contains all available servers. Selecting any combination of servers refreshes the task list to display all tasks that belong to those servers.

    If "showServerColumn" was passed as true, the server column, indicating the server to which the task belongs, displays in the task.

    Figure 26-91 Server Column

    Server Column
  15. Click any of the tasks titles to display a dialog containing the details of the task.

    Figure 26-92 Task Details

    Task Details
26.5.5.1.1 How to Deploy a Human Task Detail Page on a Remote Non-SOA Server

The following procedure is required if you run your application on a non-SOA server.

To deploy on a non-SOA server:

  1. Deploy the oracle.soa.workflow shared library on the non-SOA WLS server. Do the following:

    1. Navigate to http://remote_hostname:remote_port/console, where remote_hostname and remote_port are the host name and port for the remote non-SOA WLS server.

    2. Click the "Deployments" link, then click Install.

    3. Ensure the following value in the Path field is specified. Be sure to replace $ADE_VIEW_ROOT with the actual directory. For example:

      $ADE_VIEW_ROOT/fmwtools/fmwtools_home/jdeveloper/soa/modules/oracle.soa.workflow_11.1.1.

    4. Select oracle.soa.workflow.jar.

    5. Click Finish.

    6. Confirm that the oracle.soa.workflow(11.1.1,11.1.1) library has an Active State.

  2. Define the foreign JNDI on the non-SOA WLS server. Do the following:

    1. Navigate to http://remote_hostname:remote_port/console, where remote_hostname and remote_port are the host name and port for the remote non-SOA WLS server.

    2. Navigate to Domain Structure > Services > Foreign JNDI Providers.

    3. Click New.

    4. Enter the name ForeignJNDIProvider-SOA.

    5. Click OK.

    6. Click the "ForeignJNDIProvider-SOA" link.

    7. Replace soa_hostname and soa_port with the host name and port for the SOA WLS server.

    8. Enter the following values:

      - Initial Context Factory: weblogic.jndi.WLInitialContextFactory- Provider URL: t3://soa_hostname:soa_port/soa-infra- User: weblogic- Password: weblogic

      Note:

      The Provider URL is referring to the soa-infra application, not the domain. Do not change soa-infra to soa.
    9. Click Save.

  3. Define the JNDI links on non-SOA WLS server. Do the following:

    1. Navigate to http://remote_hostname:remote_port/console, where remote_hostname and remote_port are the host name and port for the remote non-SOA WLS server.

    2. Navigate to Domain Structure > Services > Foreign JNDI Providers.

    3. Click ForeignJNDIProvider-SOA.

    4. Select the Link tab, then click New.

    5. Enter the following values:

      - Name: RuntimeConfigService - Local JNDI Name: RuntimeConfigService - Remote JNDI Name: RuntimeConfigService

    6. Click OK.

    7. Repeat steps a through f to enter the following values for Name, Local JNDI Name, and Remote JNDI name:

      - ejb/bpel/services/workflow/TaskServiceBean - ejb/bpel/services/workflow/TaskMetadataServiceBean - TaskReportServiceBean - TaskEvidenceServiceBean- TaskQueryService- UserMetadataService

      Note:

      Specify "ejb/bpel/services/workflow/" for ejb/bpel/services/workflow/TaskServiceBean and ejb/bpel/services/workflow/TaskMetadataServiceBean only.
  4. Change system-jazn-data.xml on the remote non-SOA WLS server to include the grant for bpm-services.jar, as shown in Example 26-8. If you are deploying the ADF Task Flow for Human Task to the integrated WLS server, then you can locate the system-jazn-data.xml file in $ADE_VIEW_ROOT/system11.1.1.1.32.53.26/DefaultDomain/config/fmwconfig.

    Important: Be sure to replace $ADE_VIEW_ROOT with the actual path.. For example, /scratch/skaneshi/view_storage/skaneshi_d7b4/fmwtools/fmwtools_home/jdeveloper/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar.

    Example 26-8 bpm-services.jar Grant Code

    <grant>
         <grantee>
                 <codesource>
                    <url>file:$ADE_VIEW_ROOT/fmwtools/fmwtools_  
                      home/jdeveloper/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar</url>
                 </codesource>
         </grantee>
             <permissions>
                 <permission>
                     <class>oracle.security.jps.JpsPermission</class>
                     <name>VerificationService.createInternalWorkflowContext</name>
                 </permission>
                 <permission>
                     <class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
                     <name>credstoressp.credstore.BPM-CRYPTO.BPM-CRYPTO</name>
                     <actions>read,write</actions>
                 </permission>
                 <permission>
                     <class>oracle.security.jps.JpsPermission</class>
                     <name>IdentityAssertion</name>
                     <actions>*</actions>
                 </permission>
             </permissions>
         </grant>
    
  5. Restart the remote non-SOA WLS server.

  6. Deploy your application containing the human task detail UI to the remote non-SOA WLS server.

  7. Return to step 5 in Section 26.5.5.1, "How to Embed the Task Listing Region in an Application."

26.5.5.1.2 How to Use the Task Flow in the Federated Mode

If you are using the task flow in the federated mode, you must put wf_client_config.xml in the class path of the application. For more information, see Section 26.5.5.2, "How to Use Task Listing Region Parameters."

You also must enable global trust between the two servers. This is done so that the authenticated user is passed to all the federated servers defined in the client configuration file.

Important:

You must restart all the servers.

To use the task flow in the federated mode:

Perform the following procedure for all the servers defined in wf_client_config.xml:

  1. Log in to the WebLogic console.

  2. Under Domain Structures, click the soainfra domain name.

  3. Select the Security tab.

  4. Click the Advanced link located near the Save button.

  5. Enter a credential password of your choosing.

    Note:

    You must use this password for all SOA servers.
  6. Click Save.

  7. Restart the server.

  8. Return to step 12 in Section 26.5.5.1, "How to Embed the Task Listing Region in an Application."

Example 26-9 shows sample wf_client_config.xml code.

Note:

Put excludeFromFederatedList="true" in the <server> element if you do not want to include the server in the federated servers list.

Example 26-9 Sample wf_client_config.xml Code

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowServicesClientConfiguration xmlns="http://xmlns.oracle.com/bpel/services/client">
   <server name="default" default="true" excludeFromFederatedList="true">
      <localClient>
         <participateInClientTransaction>false</participateInClientTransaction>
      </localClient>
      <remoteClient>
         <serverURL>t3://sta00048.us.oracle.com:7001</serverURL>
         <initialContextFactory>weblogic.jndi.WLInitialContextFactory
         </initialContextFactory>
         <participateInClientTransaction>false</participateInClientTransaction>
      </remoteClient>
      <soapClient>
         <rootEndPointURL>http://sta00048.us.oracle.com:7001</rootEndPointURL>
         <identityPropagation mode="dynamic" type="saml">
            <policy-references>
               <policy-reference enabled="true" category="security"
                                 uri="oracle/wss10_saml_token_client_policy"/>
            </policy-references>
         </identityPropagation>
      </soapClient>
   </server>
   <server name="ERP">
      <soapClient>
         <rootEndPointURL>http://sta00147.us.oracle.com:7001</rootEndPointURL>
         <identityPropagation mode="dynamic" type="saml">
            <policy-references>
               <policy-reference enabled="true" category="security"
                                 uri="oracle/wss10_saml_token_client_policy"/>
            </policy-references>
         </identityPropagation>
      </soapClient>
      <remoteClient>
         <serverURL>t3://sta00147.us.oracle.com:7001</serverURL>
         <initialContextFactory>weblogic.jndi.WLInitialContextFactory
         </initialContextFactory>
         <participateInClientTransaction>false</participateInClientTransaction>
      </remoteClient>
   </server>

   <server name="CRM">
      <soapClient>
         <rootEndPointURL>http://sta00048.us.oracle.com:7001</rootEndPointURL>
         <identityPropagation mode="dynamic" type="saml">
            <policy-references>
               <policy-reference enabled="true" category="security"
                                 uri="oracle/wss10_saml_token_client_policy"/>
            </policy-references>
         </identityPropagation>
      </soapClient>
      <remoteClient>
         <serverURL>t3://sta00048.us.oracle.com:7001</serverURL>
         <initialContextFactory>weblogic.jndi.WLInitialContextFactory
         </initialContextFactory>
         <participateInClientTransaction>false</participateInClientTransaction>
      </remoteClient>
   </server>
</workflowServicesClientConfiguration>

26.5.5.2 How to Use Task Listing Region Parameters

Task listing region parameters control the display behavior of the embedded region. This section describes these parameters.

Display Parameters

  • federatedMode

    The task list displays in federated mode if this paramater is passed as true. To run the task flow in federated mode, you must pass the list of federated servers to the task flow using one of these options:

    • Put the client configuration file wf_client_config.xml in the class path (APP-INF\classes\wf_client_config.xml at the ear level or the WEB-INF\classes of the web application). The client configuration file contains all federated server details. For more information, see Section 26.5.5.1.2, "How to Use the Task Flow in the Federated Mode."

    • Construct a JAXB object, which contains the federated servers list. This JAXB object can be passed to the task flow through the federatedServers parameter. For information on how to construct the JAXB object, see the details of that parameter.

  • federatedServers

    This parameter displays a list of servers if the task flow is run in federated mode. Construct a JAXB object (WorkflowServicesClientConfigurationType) using the code shown below, and then pass it as a parameter to the task flow. Ensure that you set one server as the "default," as indicated (in bold type) in the code.

    A default server is used when you have many servers defined in wf_client_config.xml or in the JAXB object. However, the workflow client is preferred for a single server. There are a few legacy APIs that do not take the server name as parameter. To support these APIs, you must define one single server as default server; otherwise these APIs do not work.

    Example 26-10 Defining a Single Server

    import oracle.bpel.services.workflow.client.config.IdentityPropagationType;
    import oracle.bpel.services.workflow.client.config.PolicyReferenceType;
    import oracle.bpel.services.workflow.client.config.PolicyReferencesType;
    import oracle.bpel.services.workflow.client.config.RemoteClientType;
    import oracle.bpel.services.workflow.client.config.ServerType;
    import oracle.bpel.services.workflow.client.config.SoapClientType;
    import oracle.bpel.services.workflow.client.config.
    WorkflowServicesClientConfigurationType;
    
    WorkflowServicesClientConfigurationType wscct = new 
    WorkflowServicesClientConfigurationType();
    
    List<ServerType> servers = wscct.getServer();
    
    /**** Setting default server in the list ****/
    
    ServerType defaultServer= new ServerType();
    servers.add(defaultServer);
    
    defaultServer.setDefault(true);
    defaultServer.setExcludeFromFederatedList(true);
    
    defaultServer.setName("default");
    
    RemoteClientType rct = new RemoteClientType();
    rct.setServerURL("t3://sta00048.us.oracle.com:7001");
    rct.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory");
    rct.setParticipateInClientTransaction(false);
    server.setRemoteClient(rct);
    
    SoapClientType sct = new SoapClientType();
    PolicyReferencesType prts = new PolicyReferencesType();
    
    PolicyReferenceType prt = new PolicyReferenceType();
    prt.setEnabled(true);
    prt.setCategory("security");
    prt.setUri("oracle/wss10_saml_token_client_policy");
    prts.getPolicyReference().add(prt);
    
    IdentityPropagationType ipt = new IdentityPropagationType();
    ipt.setMode("dynamic");
    ipt.setType("saml");
    ipt.setPolicyReferences(prts);
    
    sct.setRootEndPointURL("http://sta00048.us.oracle.com:7001");  
    sct.setIdentityPropagation(ipt);        
    
    defaultServer.setSoapClient(sct);
    
    /****** Setting Federated Server 1 to the list ****/       
    
    ServerType server1 = new ServerType();
    servers.add(server1);
    server1.setName("Human Resource");
    
    RemoteClientType rct1 = new RemoteClientType();
    rct1.setServerURL("t3://stadl28.us.oracle.com:7001");
    rct1.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory");
    rct1.setParticipateInClientTransaction(false);
    server1.setRemoteClient(rct1);
    
    SoapClientType sct1 = new SoapClientType();
    PolicyReferencesType prts1 = new PolicyReferencesType();
    
    PolicyReferenceType prt1 = new PolicyReferenceType();
    prt1.setEnabled(true);
    prt1.setCategory("security");
    prt1.setUri("oracle/wss10_saml_token_client_policy");
    prts1.getPolicyReference().add(prt1);
    
    IdentityPropagationType ipt1 = new IdentityPropagationType();
    ipt1.setMode("dynamic");
    ipt1.setType("saml");
    ipt1.setPolicyReferences(prts1);
    
    sct1.setRootEndPointURL("http://stadl28.us.oracle.com:7001");
    sct1.setIdentityPropagation(ipt1);
    
    server1.setSoapClient(sct1);
    
    /****** Setting Federated Server 2 to the list ****/       
    
    ServerType server2 = new ServerType();
    servers.add(server2);
    server2.setName("Financials");
    
    RemoteClientType rct2 = new RemoteClientType();
    rct2.setServerURL("t3://sta00048.us.oracle.com:7001");
    rct2.setInitialContextFactory("weblogic.jndi.WLInitialContextFactory");
    rct2.setParticipateInClientTransaction(false);
    server2.setRemoteClient(rct2);
    
    SoapClientType sct2 = new SoapClientType();
    PolicyReferencesType prts2 = new PolicyReferencesType();
    
    PolicyReferenceType prt2 = new PolicyReferenceType();
    prt2.setEnabled(true);
    prt2.setCategory("security");
    prt2.setUri("oracle/wss10_saml_token_client_policy");
    prts2.getPolicyReference().add(prt2);
    
    IdentityPropagationType ipt2 = new IdentityPropagationType();
    ipt2.setMode("dynamic");
    ipt2.setType("saml");
    ipt2.setPolicyReferences(prts2);
    
    sct2.setRootEndPointURL("http://sta00048.us.oracle.com:7001");
    sct2.setIdentityPropagation(ipt2);
    
    server2.setSoapClient(sct2);
    
  • showServerColumn

    If the task flow is run in federated mode, the server column in the task list, by default, is not displayed. To display the column, this parameter must be passed as true.

  • wfCtxID

    This is a workflow context token string and is used to create workflow context inside the task flow. If the application Single Sign On is enabled or is secured using ADF security, this parameter is not required. The workflow context is shown below.

    Example 26-11 Workflow Context

    IWorkflowContext wfCtx =  wfSvcClient.getTaskQueryService().authenticate(username,
      password,
      realm,
      null;
    wfCtxID = wfCtx.getToken();
    
  • showViewsPanel

    The views panel displays only if passed as true. By default, it is not displayed.

  • showTaskDetailsPanel

    The task details panel displays only if passed as true. By default, it is not displayed.

  • refreshURL

    This string enables task details in the task listing region to display in an inline frame. If action is taken on the task details page, the action refreshes the task listing area with the p age URL in which the task flow/portlet is contained.

    Since the task flow does not know the URL of the container page, the URL must be passed as a parameter. Get the parameter by calling the getRequestURL() method on the request object. You can pass the full URL either by calling the getRequestURL() method on the request object, or by passing the URL using the following format:

    /context-root/faces/page-name 
    For example: /FederatedWorklist/faces/test.jspx
    
  • localeSource

    A string parameter that passes the locale source. It can be from the browser (BROWSER) or from the identity context (IDENTITY).

  • showActionDropdown

    The action dropdown does not display only if passed as false. By default, it is displayed.

  • showViewFilter

    The view filter dropdown does not display only if passed as false. By default, it is displayed.

  • showCreateTODOTaskAction

    Specifies if the Actions menu displays the TODO action. To hide the TODO action, set this parameter to false. By default the Actions menu inclueds the TODO action.

  • showAssignmentFilter

    The assignment filter dropdown does not display only if passed as false. By default, it is displayed.

  • showStatusFilter

    The status filter dropdown does not display only if passed as false. By default, it is displayed.

  • showSearchControl

    The search box does not display only if passed as false. By default, it is displayed.

  • displayColumnsList

    This comma-delineated list of strings enables the list of columns to be displayed in the region in the order specified.

  • sortColumn

    This string specifies the name of the column to be used for sorting tasks by default in the region.

  • sortOrder

    This string specifies the sort order for sorting tasks, that is ascending (ASC) or descending (DESC).

Filter Parameters

  • assignmentFilter

    This string specifies the value to be used as the selection of the assignment filter for tasks. If not set, the values default to My and Group. For more information, see Section 26.5.5.2.1, "Using Assigment Filter Constraints."

  • viewFilter

    This string specifies the value to be used as the selection of the view name to filter the tasks. If not set, the value defaults to Inbox.

  • taskTypesFilterList

    A strings parameter that specifies the comma-delineated list of the task type(s) to be used for filtering the tasks that are displayed.

  • attributesFilterOperator

    A string that specifies the operator (and/or) to be used as the predicate join criterion for the field-specified in Attribute Filter list.

  • attributesFilterList

    A string parameter that specifies the comma-delineated list of name value pairs to be used to filter tasks based on attribute values. (The name is task column name and value is column value.)

Example

If the user wants to see the task with attribute filter values as priority = 1 and status = ASSIGNED and promoted flexfield textAttribute1 = NorthAmerica, then the user would set the values as the following:

attributeFilterList: priority=1, status=ASSIGNED, textAttribute1=NorthAmerica

The attribute filter operator would be the following:

attributeFilterOperator: and 
26.5.5.2.1 Using Assigment Filter Constraints

The following is a list of assignment filter constraints:

  • My

  • Group

  • My+Group

  • Reportees

  • Creator

  • Owner

  • Reviewer

  • Previous

  • Admin

26.5.5.2.2 Passing Column Constraints

The list below contains the column constants that can be passed in thedisplayColumnList parameter. The constant value is the value that should be passed. For example, for TITLE_COLUMN = "title", the "title" should be passed, not "TITLE_COLUMN".

Primary Column Contraints


STARTDATE_COLUMN = "startDate";
TASKDEFINITIONNAME_COLUMN = "taskDefinitionName";
OWNERROLE_COLUMN = "ownerRole";
UPDATEDDATE_COLUMN = "updatedDate";
COMPOSITEVERSION_COLUMN = "compositeVersion";
CREATOR_COLUMN = "creator";
FROMUSER_COLUMN = "fromUser";
PERCENTAGECOMPLETE_COLUMN = "percentageComplete";
OWNERGROUP_COLUMN = "ownerGroup";
ENDDATE_COLUMN = "endDate";
COMPOSITENAME_COLUMN = "compositeName";
DUEDATE_COLUMN = "dueDate";
COMPOSITEDN_COLUMN = "compositeDN";
TASKDISPLAYURL_COLUMN = "taskDisplayUrl";
UPDATEDBY_COLUMN = "updatedBy";
OUTCOME_COLUMN = "outcome";
TASKNAMESPACE_COLUMN = "taskNamespace";
APPROVERS_COLUMN = "approvers";
APPLICATIONCONTEXT_COLUMN = "applicationContext";
OWNERUSER_COLUMN = "ownerUser";
CATEGORY_COLUMN = "category";
ACQUIREDBY_COLUMN = "acquiredBy";
ORIGINALASSIGNEEUSER_COLUMN = "originalAssigneeUser";

Other Column Constraints


ACQUIREDBY_COLUMN = "acquiredBy";
ASSIGNEDDATE_COLUMN = "assignedDate";
APPROVERS_COLUMN = "approvers";
ASSIGNEES_COLUMN = "assignees";
ASSIGNEESDISPLAYNAME_COLUMN = "assigneesDisplayName";
ASSIGNEEGROUPS_COLUMN = "assigneeGroups";
ASSIGNEEGROUPSDISPLAYNAME_COLUMN = "assigneeGroupsDisplayName";
ASSIGNEEUSERS_COLUMN = "assigneeUsers";
ASSIGNEEUSERSDISPLAYNAME_COLUMN = "assigneeUsersDisplayName";
OUTCOME_COLUMN = "outcome";
CREATEDDATE_COLUMN = "createdDate";
ELAPSEDTIME_COLUMN = "elapsedTime";
DIGITALSIGNATUREREQUIRED_COLUMN = "digitalSignatureRequired";
PASSWORDREQUIREDONUPDATE_COLUMN = "passwordRequiredOnUpdate";
ENDDATE_COLUMN = "endDate";
EXPIRATIONDATE_COLUMN = "expirationDate";
EXPIRATIONDURATION_COLUMN = "expirationDuration";
FROMUSER_COLUMN = "fromUser";
FROMUSERDSIPLAYNAME_COLUMN = "fromUserDisplayName";
HASSUBTASK_COLUMN = "hasSubtask";
STATE_COLUMN = "State";
TASKID_COLUMN = "taskId";
VERSION_COLUMN = "version";
TASKNUMBER_COLUMN = "taskNumber";
UPDATEDBY_COLUMN = "updatedBy";
UPDATEDBYDISPLAYNAME_COLUMN = "updatedByDisplayName";
UPDATEDDATE_COLUMN = "updatedDate";
VERSIONREASON_COLUMN = "versionReason";
CREATOR_COLUMN = "creator";
OWNERUSER_COLUMN = "ownerUser";
OWNERGROUP_COLUMN = "ownerGroup";
OWNERROLE_COLUMN = "ownerRole";
PRIORITY_COLUMN = "priority";
DOMAINID_COLUMN = "domainId";
INSTANCEID_COLUMN = "instanceId";
PROCESSID_COLUMN = "processId";
PROCESSNAME_COLUMN = "processName";
PROCESSTYPE_COLUMN = "processType";
PROCESSVERSION_COLUMN = "processVersion";
TITLE_COLUMN = "title";
TITLERESOURCEKEY_COLUMN = "titleResourceKey";
IDENTIFICATIONKEY_COLUMN = "identificationKey";
TASKDEFINITIONID_COLUMN = "taskDefinitionId";
TASKDEFINITIONNAME_COLUMN = "taskDefinitionName";
APPLICATIONNAME_COLUMN = "applicationName";
ASSIGNEETYPE_COLUMN = "assigneeType";
CATEGORY_COLUMN = "category";
COMPONENTNAME_COLUMN = "componentName";
COMPOSITEDN_COLUMN = "compositeDN";
COMPOSITEINSTANCEID_COLUMN = "compositeInstanceId";
COMPOSITENAME_COLUMN = "compositeName";
COMPOSITEVERSION_COLUMN = "compositeVersion";
CONVERSATIONID_COLUMN = "conversationId";
DUEDATE_COLUMN = "dueDate";
PARTICIPANTNAME_COLUMN = "participantName";
PERCENTAGECOMPLETE_COLUMN = "percentageComplete";
READBYUSERS_COLUMN = "readByUsers";
STARTDATE_COLUMN = "startDate";
PARENTTASKVERSION_COLUMN = "parentTaskVersion";
TASKGROUPINSTANCEID_COLUMN = "taskGroupInstanceId";
SUBTASKGROUPINSTANCEID_COLUMN = "subTaskGroupInstanceId";
ROOTTASKID_COLUMN = "rootTaskId";
PARENTTASKID_COLUMN = "parentTaskId";
CORRELATIONID_COLUMN = "correlationId";
TASKDISPLAYURL_COLUMN = "taskDisplayUrl";
STAGE_COLUMN = "stage";
LOCALE_COLUMN = "locale";

26.5.6 How to Use the Task History Region to Preview Approvers

The History component is an ADF declarative UI component used to render the past and future participants for an initiated task, and for a task before initiation. The component can edit the future participants, and can be embedded in any ADF page. Parameters are the following:

  • Task Object

  • Workflow Service Client

  • Workflow context

  • showTabularView

  • showGraphicalView

If any of the first three parameters are passed as null, or if the correlation ID of a task object is null, the component does not show the approval list. Instead, it shows a message explaining the possible cause why it failed to show the approval list. The last two parameters are used to indicate whether tabular or graphical views are to be shown. By default, both tabular and graphical views are shown. The value true/false can be passed to last two parameters.

26.6 Using the User Metadata Migration Utility

The user metadata migration utility, hwfMigrator, is a tool that automates the process of migrating Workflow user-configurable data from one SOA server to another by executing a shell script.

For more information about the user metadata migration utility, see Moving Human Workflow Data from a Test to a Production Environment in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.