Wednesday Mar 27, 2013

Managing Workflow Notifications in Fusion Apps – An Example

This article illustrates an example of a system administrator viewing and taking action on SOA Human Workflow notifications generated by a composite process that underlies a Fusion Apps HCM Task. As part of the privileges granted by their enterprise role, the administrator is able for example to reassign, suspend, or withdraw the requested action in the task.

What is a Human Workflow?

Human Workflow is the component of Oracle’s SOA suite that allows humans to interact with a process. For example a manager might need to approve a purchase order or an expense report prior to the transaction (issuing a purchase order or reimbursement of expenses) being completed or perhaps to reassign a task they are unable to complete. In addition to allowing users of an application to interact with its processes, the capabilities of the Human Workflow include full task lifecycle management through the ability to reroute tasks, escalate them, and providing deadlines by which they must be completed, in addition to the presentation of tasks to the concerned user through the BPM Worklist application or other channels such as email.


The Task and its Rules

In our example we will use a Fusion HCM Transaction example to illustrate how a transaction is routed and what actions an administrator can take on that transaction.

The Table below lists Fusion Core HCM transactions that are enabled for approvals.

Seeded Approvals (Include 2 Levels of Supervisor chain)

Seeded Auto-Approved

Transfer

Manage Salary (typically configured to require approval)

Promotion

Manage Compensation (typically configured to require approval)

Change Manager

Share Information (requires approval by worker)

Change Location

Change Marital Status

Change Working Hours

Create Employment Terms

Terminate Work Relationship

Manage Employment

Hire an Employee

Manage Grades

Add a Non-worker

Manage Grade Ladders

Add a Contingent Worker

Manage Grade Rates

Add a Pending Worker

Manage Jobs

Create Work Relationship

Manage Locations

Manage Work Schedule Assignment

Manage Organizations

Manage Absence Records (1 level)

Manage Person

Manage Document Record (1 level)

Manage Positions

Submit Performance Document(1 level)


Add Goal (1 level)


Table 1.Fusion HCM Transactions


Let us start by looking at the Promotion Task and the rules associated with that task.

Figure 1 shows the composite process that handles the HCM Promotion task. This composite consists of several SOA components and includes the services and references in Figure 2.

2.tiff

Figure 1.Deployed Promotion Approvals Composite processes.

3.tiff

Figure2. Components of the Promotion Approval Composite

In Figure 3 below, the rule defined reads as follows: For the promotion process and for all cases (the condition 1=1 being always true) build the approval list based on the supervisory hierarchy and process the transaction two levels above the approver, starting with the approver’s manager and stopping with the user “douglas.mcneil” who happens to also be the CEO and the top node in the hierarchy.

Figure3. BPM Task Configuration Rules

The Administrator’s privileges

In Fusion Applications the ability to access functions across products is controlled by functional privileges granted to a user through APM (Access Provisioning Manager). The application role that allows an administrator to view all human tasks is “BPM Workflow System Admin Role”. Several of the seeded roles in the reference implementation inherit this duty. The table below shows the hierarchy for the Human Capital Management Application Administrator.

Level

Display Name

Role Name

Description

Inherited by

1

Human Capital Management Application Administrator

HRC_HUMAN_CAPITAL_

MANAGEMENT_APPLICATION_ADMINISTRATOR_JOB

Configures the Oracle Fusion Global Human Resources application and has access to all duty roles necessary to implement the Compensation, Workforce Deployment, and Workforce Development offerings.


2

BPM Workflow System Admin Role

BPMWorkflowAdmin

This role grants a user the privilege to perform administrative actions in the workflow functionality via the worklist UI. A user in this role will be able to view all tasks in the system, recover errored (incorrectly assigned) tasks, create approval groups and edit task configuration / rules DT@RT UI (both AMX functionality) This is a business administrator type role. This role is granted to SOAAdmin.

1

Table 2.Seeded Roles that provide access to all Tasks in the Worklist application

4.tiff

Figure4. Role hierarchy assigned to the administrator for the example in this document

The HCM Transaction

At the conclusion of a performance evaluation cycle, a manager determines that an employee is a candidate for a promotion. The Manager initiates the request from the Manager Resources Dashboard. The necessary adjustments are made to the employee’s Job, and Compensation details and the transaction is submitted.

7.tiff

Figure5a. Supervisory Hierarchy: Donald Alexander reports to Douglas McNeil

8.tiff

Figure5b. Supervisory Hierarchy: Stella Marcus reports to Donald Alexander

9.tiff

Figure5c. Supervisory Hierarchy: Jaime Gregg reports to Stella Marcus

Figures 5a, 5b, 5c show three levels in the supervisory hierarchy, the transaction we will use in our example below will be submitted for employee Jamie Gregg, and will be submitted by Stella Marcus her manager. Based on the approval rules we had defined earlier this promotion request will be routed to the next two levels in the hierarchy in sequence to Donald Alexander then Douglas McNeil.

The manager selects the Promote Action from the employee’s card in the Org chart

10.tiff

Figure6. The Manager Selects the Promote Action from the Org Chart.

The Manager Completes the promotion request and reviews the details prior to submission. The approval list is built in the last step of the transaction as illustrated in Figure 7a and 7b below.

11.tiff

Figure7a. There last step in the transaction is the review of the request prior to submission

12.tiff

Figure7b. The Approval list built in the last step of the transaction prior to submission.

Initiated transactions generate an instance of the composite process discussed earlier (see Figure 8 below) , and are available to the participants and administrator. The instance also retains the status and history of the transactions during its lifecycle and after completion.

13.tiff

Figure 8. TheTask instance in the Worklist of the Manager

After submission, the manager can review the initiated task and amend it by adding attachments or comments as seen in Figure 9 below.

Figure 9. Comments and Attachments added to the request

The Notification

Based on the rules applicable to the promotion transaction we discussed earlier, the process sends a request for approval to the manager of the requestor. However let us assume that Donald Alexander the manager of Stella Marcus and the the first of the two approvers is not available to take an action on the request. Stella makes a request via the comments field to have the administrator to skip the current stage and forward the request to the next approver.

The Administrator Action

The administrator Kyle Bailey searches for transactions assigned to Donald Alexander (Figure 10) and can perform the actions listed in Figure 11 namely skip the current assignment, suspend , withdraw or reassign the request to a different user .

16.tiff

Figure 10. Administrator queries tasks assigned to Donald Alexander

17.tiff

Figure 11. Actions an administrator can take on an assigned task

After reassignment of the task by the administrator to the next approver, Douglas McNeil can now see the Task in their worklist.

19.tiff

Figure 12. Worklist of the user to whom the task was reassigned

All changes made to to a task instance remain with the task and are viewable by all users who have access to that task namely the participants in the transaction (the approvers) and the administrator. A completed task with a full history of task actions and the participants who made them is shown in Figure 13 below.

20.tiff

Figure 13.Completed Task

References

Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite11g Release 1 (11.1.1) Part Number E10224-05 -- Chapter 27


Oracle SOA Suite Components



About

This blog shares with the broader Fusion Applications community instructional material in the areas of Enterprise Structures, Extensibility, Integration and Security with the a focus on implementation. This blog is updated by the Fusion Applications Implementation Solutions Task force, part of the Fusion Applications Fusion Architecture organization.

Search

Archives
« March 2013 »
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
28
29
30
31
      
Today