awe overview 03082011

PRESENTED BY:

Paul GryfakisPrincipal Consultant / HCM Practice

MARCH 2011

AWE OverviewHCM 9.1

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

Agenda & Objectives

» 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

2 >> © 2011 Optimum Solutions Group, LLC

What is AWE?


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


Challenges With Traditional Workflow

• Traditional Workflow consisted of:• Business Processes

• Activities

• Events

• Requires development in

Application Designer

• Not configurable online


What is AWE?

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

• Sample Common Events


Event

On Process Launch Triggered when the AWE transaction is initiated

Route for Approval Triggered each time an approval is routed

On Final Approval Triggered when all approval steps have been approved

On Final Denial Triggered when an approver denies the approval request.

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



• On Header Approve Example

• On Header Deny Example


AWE Support Objects


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


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


Technical Review of Custom Example


Questions & Answers


Contact Information

Paul Gryfakis

Principal [email protected]


awe overview 03082011

Documents