AWE Overview

HCM 9.1

PRESENTED BY:

Paul Gryfakis
Principal Consultant / HCM
Practice

MARCH 2011
 Agenda & Objectives
OBJECTIVES
• Provide an overview of the
PeopleSoft Approval Workflow
Engine (AWE)
• Provide a technical overview of an
AWE implementation
• Allow time for a Q&A Session
2 >> © 2011 Optimum Solutions Group, LLC
» Introduction
» What is the Approval Workflow Engine (AWE)?
» Review AWE Components
» Describe the AWE Support Objects
» Registering & Configuring AWE Transactions
» Demonstrate Custom AWE Approval Process
» Review Custom AWE Components
» Questions and Answers
 What is AWE?

3 >> © 2011 Optimum Solutions Group, LLC

 What is the Approval Workflow Engine (AWE)?

• Provides the framework and capabilities for creating, running, and

managing approval processes.
• Uses a series of database objects combined with application component
configuration settings to determine how to process approvals using
workflow.
• Originally introduced in an 8.x release of PeopleSoft’s Supply Chain
Management (SCM) application.
• Delivered with Peopletools

4 >> © 2011 Optimum Solutions Group, LLC

 Challenges With Traditional Workflow

• Traditional Workflow consisted of:

• Business Processes
• Activities
• Events
• Requires development in
Application Designer
• Not configurable online

5 >> © 2011 Optimum Solutions Group, LLC

 What is AWE?

• The AWE framework is made up of 20 workflow events that can be

configured.
• Sample Common Events

Event
On Process Launch
Route for Approval
On Final Approval
On Final Denial
Triggered when the AWE transaction is initiated
Triggered each time an approval is routed
Triggered when all approval steps have been
approved
Triggered when an approver denies the approval
request.

6 >> © 2011 Optimum Solutions Group, LLC

 What is AWE? – Visual Workflow Example

• On Process Launch Example – Originator View

• Route for Approval Example – 1ST Approver View

• Example after 1st step approver

• Route for Approval Example – 2nd Approver View

7 >> © 2011 Optimum Solutions Group, LLC

 What is AWE? – Visual Workflow Example

• On Header Approve Example

• On Header Deny Example

8 >> © 2011 Optimum Solutions Group, LLC

 What is AWE? – Visual Workflow Example

• On Header Approve Example

• On Header Deny Example

9 >> © 2011 Optimum Solutions Group, LLC

 AWE Support Objects

10 >> © 2011 Optimum Solutions Group, LLC

AWE Support Objects

• The building blocks of objects and definitions that will be used within the
framework for the AWE process:
» Record Objects
• Header Record
• Cross Reference Record
» Processing Logic
• Event Handler
• Ad Hoc Access Class (optional)
• Thread Class (optional)
» Notifications
• Email Template
• Email Template SQL Object
• User List Definitions
Record Objects – Header Record

• Highest-level transaction record having a 1-to-1 relationship with

the transaction (same key structure)
• Each transaction that is submitted should have only one row in the
Header Record
• Can be a staging table, or the transaction table
Record Objects – Cross Reference Record

• The AWE uses this record as its only link between itself and the
transaction (Header Record).
• Your application does not need to retrieve any information off this
record and should never update this record.
• The cross-reference record is simply a record containing the
delivered EOAW_XREF_SBR as well as all the key fields from the
applications header record MARKED AS NON-KEY fields.
 Processing Logic – Event Handler Class

• The AWE is designed around a series of specific, pre-defined events.

• The event handler class is where the logic resides on what processing should
take place for each event.
• This allows the adopting application to assign specific pieces of PeopleCode to
be fired during these events.
Processing Logic – Ad Hoc Access Class

• Allows each application to extend the core AWE logic.

• By creating an Adhoc access class, you can control when a user is
allowed to modify the approval path and participants.
Processing Logic – Ad Hoc Access Class cont’d

Ad Hoc Logic Code Example:

Method allowInsert
If IsUserInRole(“ExpensesAdministrator”) then
Return True
Else
Return False
End-if;
End-method;
Processing Logic – Thread Class

• The Thread Class relates to what is displayed on the Status Monitor.

• The threadDescr class allows you to override this default and display
something more meaningful to the user.
Notifications – Email Template

• Anytime the AWE triggers an email notification based on the rules that are
set in the Configure Transactions component, it will construct the email
based on the assigned template.
• Navigation: Set Up HRMS > Common Definitions > Approvals > Generic
Templates
Notifications – Email Template cont’d

• Each Generic Template has a section to define what parameters will be

passed to the template
• The 1st parameter is reserved for a URL generated to link to the
transaction
• After the 1st parameter, all other parameters are populated via a SQL
definition defined on the transaction configuration
Notifications – Email Template SQL Object

• You must create SQL Object(s) if you wish to use bind values in your email
notifications to display data.
Notifications – User List Definitions

• User List object definitions are pieces of logic that, when instantiated at
runtime, return a list of PeopleSoft operator IDs.
• Userlists are used primarily to define who the system needs to route a
transaction to at the Step level of an Approval Process Definition.
• A set of pre-defined user lists based on typical HCM direct reports
hierarchies are delivered
Notifications – User List Definitions cont’d

There are four types of User Lists you can define to help the system resolve who the next approver
is for a given transaction.

1. Role – The system will return all the users in the specified role to the engine at runtime.

2. SQL Definition – You need to enter SQL Object name they have created through Application
Designer. The SQL Object must select OPRID in its select statement.

3. Query – You need to enter Query Name they have created through Application Designer. As
with the SQL Definition, the Query must select OPRID in its select statement.

4. Application Class – You need to provide Application Package Name and Application Class
name. The application class must Extend the PTAF_CORE:Defn:UserListBase Class.

Include User as Input – If this checkbox is turned on, then requester’s OPRID or the previous
approver’s OPRID will be used to resolve the bind variable for SQL Object and Query.

Transaction Keys as Input – If this checkbox is turned on, the transaction data record passed into
the AWE will be used to resolve the bind variable for SQL Object and Query.
 Registering and Configuring
AWE Transactions

23 >> © 2011 Optimum Solutions Group, LLC

Registering Transactions in AWE

The recommended steps for setting up your transactions to use AWE are as
follows:
1. Approval Transaction Registry – Where you register your transaction in
AWE
2. Workflow Transactions - Where you link the self service transaction
name to the process ID used in AWE
3. Configure Transactions - where you define among other things the
notifications behavior for each transaction.
4. Approval Process Definition - where you define your approval processes
and criteria, if any
Register the AWE Transaction

• Used to register a PeopleSoft Enterprise application's transaction with the

Approval Framework.
• Using the Register Transactions page, developers define how the system
interacts with portions of the application that have been defined for
approvals.
• Navigation: Set Up HRMS > Common Definitions > Approvals >
Transaction Registry
Register the AWE Transaction cont’d

• Register the AWE Transaction

» Assign the Cross Reference table
Register the AWE Transaction cont’d

• Assign the Event Handler Class, Ad Hoc, and Thread Classes

• Assign a header record
Workflow Transactions

• Register self-service transactions that use the Approval and Delegation

framework
• Navigation: Set Up HRMS > Common Definitions > Approvals > Workflow
Transactions
Transaction Configuration

• Use the Transaction Configuration page to define how to handle the various
events of the approval process (e.g. Approval Launch, Final Approval, Denial)
» Configure Approval Menu/Component/Page
» Configure SQL object for workflow
» Configure Notifications
Approval Process Setup

• Define one or more

process definitions
for each of your
transactions.
• Define the number
of stages, paths,
and steps required
for each process
definition.
• Define criteria (if
any) that the AWE
will use to
determine which
process definition,
path, or step to use
at run time.
Security – Permission Lists and Roles

• The HCM Shared Components team delivered three new permission lists
and one new role to support AWE.
Implementing the Status Monitor

• Used to display a graphical representation of the approval process status

for a particular transaction
• To implement the Status Monitor in your transaction, perform the following
steps
» 1) Add the sub-page HCSC_MON_SBP wherever you would like the display the
status monitor.
Implementing the Status Monitor cont’d

2) In an appropriate PeopleCode event, instantiate the status monitor

interface class. For example:
Application PeopleCode to Instantiate AWE

• Calls to the AWE are best located in SavePostChange PeopleCode

events.
• If a transaction is submitted to the AWE before the transaction is saved
and then an error occurs after the call to the API, the situation could arise
where the AWE is now tracking a transaction that does not exist.
 Custom AWE Demonstration

35 >> © 2011 Optimum Solutions Group, LLC

 Technical Review of Custom
Example

36 >> © 2011 Optimum Solutions Group, LLC

 Questions & Answers

37 >> © 2011 Optimum Solutions Group, LLC

 Contact Information

Paul Gryfakis
Principal Consultant
847.274.3890
paul_gryfakis@optimumsolutions.com

38 >> © 2011 Optimum Solutions Group, LLC