< Name of the document>

Contents

Contents..................................................................................................1 Introduction.............................................................................................2 Customizations involved in AWE................................................................3 Step 1 - Header record:............................................................................................3 Step 2 - Creation of cross-reference record: ............................................................3 Step 3 - Manually Inserting row into EOAW_IDS record:............................................4 Step 4 - Creation of Event Handlers Application Package and Application Class.......4 Step 5 - Creation of SQL/PSQuery/App Class for Approver User list...........................6 Step 6 - Approver User Info View:.............................................................................7 Step 7 - SQLs for sending E-mail notifications through Workflow Generic Template..9 Step 8 - Implementing Approval Status Monitor .....................................................10 Step 9 - Implementing Thread Description Class....................................................13 Step 10 The PostBuild code required to intiate AWE............................................15 Configurations involved in AWE...............................................................17 Step 1 - Register Transaction.................................................................................17 Step 2 - Creating Workflow Generic Templates and Configuring Transaction:.........19 Step 3 - Creating Approver User List.......................................................................24 Step 4 - Setting up Approval process......................................................................25 Example of the Approval through AWE:....................................................28 Step 1 - Submission ...............................................................................................28 Step 2 - Approval...................................................................................................30 E-mail Notification example.....................................................................33 Ad-hoc Approver Example........................................................................33 Important Records in AWE.......................................................................35 Reference(s)...........................................................................................35

2010 Infosys Technologies Limited, India

< Name of the document>

Introduction

The Approval Workflow Engine (AWE) also known as PeopleSoft Approval Framework is the engine that provides the framework and capabilities for creating, running and managing approval processes. The engine uses a series of database objects combined with application component configuration settings to determine how to process approvals using workflow. Prior to AWE, many PeopleSoft applications were relied on Virtual Approval or Legacy Workflow for managing their workflow transactions. The legacy system requires advanced technical skills in PeopleSoft to create and maintain these workflows (creating Business Processes, activities, PeopleCode etc.) unlike Approval Workflow Engine which provides an alternative workflow that is much easier to create, configure, and maintain. All steps in AWE can be configured using standard PeopleSoft pages. The technical person only needs to create the supporting definitions which will be used in configuration of AWE. Approval workflows are triggered when requesters submit a transaction, such as an Expense Report. The application hands the transaction over to the Approval Workflow Engine, which finds the appropriate approval process definition and launches the approval workflow. A set of approvers then carries out tasks related to the transaction. The Approval Workflow Engine enables three levels of users to develop, configure, and use transaction approvals that meet their organizational requirements. For example, the process of submitting an Expense Report and getting it approved requires defining who will approve the Expense Report, the order in which they will approve it, and how it will be routed to approvers. This document mainly covers technical aspects of AWE and the configurations involved in the entire Approval process. This is illustrated with example of one simple page and component from where the submitted transaction will be processed through AWE. This document will be useful in implementing AWE for applications where PeopleSoft has not delivered any Approval Workflow.

Customizations involved in AWE

2010 Infosys Technologies Limited, India

< Name of the document>

Approval Workflow Engine requires developing supporting PeopleTools objects which will provide required data to the configuration done by functional user. These supporting PeopleTools objects involved can be Records, SQLs and Application Classes. Following are some steps involved in developing these custom supporting definitions. Note: The delivered AWE objects mentioned in this document are from FSCM Application Version 9.1. There was different naming convention for PeopleTools objects in earlier releases of FSCM and HCM. For example, AWE objects are starting with PTAF in 9.0 version or with SAC_AW in 8.9 version. The code snippets given below should work in earlier version by replacing EOAW with appropriate string (PTAF for 9.0 or SAC_AW for 8.9). Before proceeding with below steps, it is assumed that the appropriate menu, component and pages are already in place for the application where AWE is required to be implemented. Step 1 - Header record: The header record is one of the most important records used in Approval Process. Header record should have one-to-one relationship with the transaction i.e. there should be only one row for the given transaction ID (e.g. Expense Header record for T&E or PV_REQHDR_AW_VW record for ePro) Following screenshot shows sample Transaction Header record (INF_TEST_REQ) used in our example

Step 2 - Creation of cross-reference record: This will act as interface between transaction header record and AWE. The crossreference record is the only link between submitted transaction and AWE. This record is nothing but the combination of sub-record EOAW_XREF_SBR and the transaction keys from transaction header record. Following screenshot shows cross reference record INF_PTAFAW_XREF in our example (contains sub-record EOAW_XREF_SBR and keys from header record marked as non-keys):

2010 Infosys Technologies Limited, India

< Name of the document>

Step 3 - Manually Inserting row into EOAW_IDS record: EOAW_IDS is the AWE seed record which is used to create some of the key values for AWE like thread IDs. This record contains only two fields, EOAWCOUNTERNAME and EOAWCOUNTER. We need to set value of EOAWCOUNTERNAME to our crossreference record name (INF_PTAFAW_XREF) and EOAWCOUNTER to the initial value of thread ID we want to put (usually 1). The value provided for EOAW_IDS.EOAWCOUNTER field is the initial value of thread ID (INF_PTAFAW_XREF.EOAWTHREAD_ID) and AWE will begin incrementing this value when first transaction is submitted. The increment counter is 10 which is set at core app package level. So, this step will involve following manual INSERT on EOAW_IDS as PeopleSoft does not provide any user interface for maintaining values for thread IDs: INSERT INTO PS_EOAW_IDS VALUES ('INF_PTAFAW_XREF', 1) Once values are set in EOAW_IDS, it should not be updated in any case. Updating this record may leads to duplicate thread IDs in the system which may cause problems in Approval Process. Step 4 - Creation of Event Handlers Application Package and Application Class The event handlers handles different events triggered throughout the approval process like Transaction Submission, Approval, Denial etc. These event handlers should extend Class EOAW_CORE:ApprovalEventHandler from AWE core app package EOAW_CORE and should be registered in approval process set-up. The custom Event Handler application class should contain only methods specific to the business requirement. E.g. it may not be required for the business to implement functionality to put submitted transaction on Hold. In such cases, the custom Event Handler class should not contain method OnStepHold. This custom App Class is best place to modify the transaction in appropriate event e.g. the status of submitted transaction can be updated to Approved or Denied (APR or DEN) in methods OnHeaderApprove and OnHeaderDeny respectively.

2010 Infosys Technologies Limited, India

< Name of the document>

Following is the sample App Class code which implements OnHeaderApprove and OnHeaderDeny methods from delivered base class EOAW_CORE:ApprovalEventHandler. Ensure that, before overriding any method from super class, a call to super class method should be placed first. This will allow the logic of super class to get fired first.

Sample Code ApprovalEventHandler.txt

Step 5 - Creation of SQL/PSQuery/App Class for Approver User list AWE determines intended approvers for the submitted transaction from Approver User List. There are 4 types of Approver User List which can be configured at Enterprise Components > Approvals > Approval User List:

Role System will return all the users as approvers in the specified role to
the AWE at runtime.

2010 Infosys Technologies Limited, India

< Name of the document>

SQL Definition The SQL Object name created through Application Designer
should be entered here. The SQL Object must select OPRID in its select statement. The OPRIDs returned will be the approvers of transaction

PSQuery The PS Query created should be entered here. The PS Query type
should be Process and must select OPRID in its select statement.

Application Class A custom app package and app class should be created
which must extend the EOAW_CORE:Defn:UserListBase Class. Also, the class must have a GetUsers method and return an array of string containing OPRIDs which will act as approvers. Of the above 4 methods, App Class offers best flexibility to implement different logics to arrive at list of approver IDs. Following screen shots shows sample app class code which returns supervisor(s) of the employee submitting the transaction as an array of string:

2010 Infosys Technologies Limited, India

< Name of the document>

Sample Approver User List Code.txt

Step 6 - Approver User Info View: Approver user info view displays information about approver (ID, Name, Dept etc) displayed on Approval Status monitor page. This is useful in identifying who the approver is for the submitted transaction. Following is the SQL for Approver user Info View (INF_TEST_APR_VW) for our example. This will display Approver ID, Dept, EMAILID along with operator ID name after clicking hyperlink against Approver Name on Approval Status Monitor page. Please refer Approval Status Monitor section for more details on this.

2010 Infosys Technologies Limited, India

< Name of the document>

Information from Approver user Info view:

2010 Infosys Technologies Limited, India

< Name of the document>

Step 7 - SQLs for sending E-mail notifications through Workflow Generic Template AWE uses standard Workflow Templates to send e-mail notifications to the intended recipients after completion of specific event like submission, Approval etc. Appropriate SQL object needs to be created in App Designer to populate the information about transaction in e-mail body.

Following is the SQL which we are going to use for sending e-mail Notifications for AWE after Transaction Submission, Approval and Denial. The order of SQL SELECT columns should match with Template Variables starting from %2 in Generic Template Definition. Please refer Configuration Section of AWE in this document for creation of Generic Templates and their mapping to the AWE Approval Process.

Here we are sending EMPLID, Name, Transaction ID, Description, Submission Date and Status for all 3 e-mail notifications of Submission, Approval and Denial of transaction. If it is required to send different data for each event, you need to create different SQLs for each event as per the need.

2010 Infosys Technologies Limited, India

< Name of the document>

Step 8 - Implementing Approval Status Monitor This is optional feature for AWE i.e. it is not mandatory to implement Approval Status monitor on the Transaction Pages for AWE to work.

The approval monitor helps in understanding the approval flow of the transaction. It shows the approver(s) involved in the process along with current approval state of the transaction.

Following steps needs to be followed to implement Approval Status Monitor:

Add the subpage EOAW_MON_SBP on the page where it is required to display Approval Monitor. In our example, the subpage EOAW_MON_SBP is added on custom page INF_TEST_APR_MON. A link is provided on main transaction page which will go to this page after transaction is submitted. This is shown in below screenshots:

2010 Infosys Technologies Limited, India

< Name of the document>

Approval Monitor page

Link to Approval Monitor page. This is enabled through PeopleCode, only when Txn is Submitted, Approved or Denied.

2010 Infosys Technologies Limited, India

< Name of the document>

Main Transaction Page from where Txn will be Submitted/Approved/Denied.

Call the delivered function createStatusMonitor at appropriate PeopleCode event. The current app instance of the approval process should be passed to this function.

For our example, we have put the following function test_req_aprvl_monitor just before transferring to INF_TEST_APR_MON which will create Approval Monitor on the intended page.

2010 Infosys Technologies Limited, India

< Name of the document>

createStatusMonitor function.txt

Note: The D in passing value for createStatusMonitor function indicates that Approval Monitor will be Display Only. This can be A also where multiple approvers can be added in the current Approval step which is called Ad-Hoc approver feature of AWE. Step 9 - Implementing Thread Description Class The thread description class is again an optional feature of AWE. The thread description class allows us to put meaningful description about the submitted thread on Approval Status Monitor page. By default, AWE will show keys from header record as a title for Approval Status Monitor which can be changed to any user defined meaningful text using Thread Description Class. The Thread Description Class also allows us to override the description of Worklist entry created when the transaction is submitted.

The thread description class must extend the class threadDescrBase from EOAW_MONITOR:MONITOR app package and it should contain the methods getThreadDescr (for overriding thread description on Approval Status Monitor) and getWorklistDescr (for overriding description of Worklist entry).

The thread description class will be then registered with Approval Process on Transaction Registry setup which is illustrated in Configuration section of this document.

Following code shows the implementation of methods getThreadDescr and getWorklistDescr for our example for changing description of thread on Approval Status Monitor and Worklist page.

2010 Infosys Technologies Limited, India

< Name of the document>

This method will put the text Employee ID : before EMPLID value, Test Request ID: before INF_TEST_REQ_ID value and Status before status value on Approval Status Monitor page.

2010 Infosys Technologies Limited, India

< Name of the document>

This method will put the text Test Request for Employee ID: before EMPLID value and Request ID: before Test request ID value for the Worklist entry on Worklist page

Following is the entire app package code for Thread Description:

ThreadDescriptionClass.txt

Step 10 The PostBuild code required to intiate AWE The best place to initiate AWE app classes is from Component PostBuild Event as it will allow us make any final, AWE-related user interface changes (like hiding/un-hiding buttons). Also it is feasible to create objects for LaunchManager and ApprovalManager application classes in the component PostBuild event, and then storing those objects as component-scoped variables which can be further used throughout component scope.

2010 Infosys Technologies Limited, India

< Name of the document>

Following screenshot shows sample PostBuild code in our example for initiating LaunchManager and ApprovalManager application classes.

Further, we can just put some logic to call method appropriate to the event occurred e.g. if submit button is pressed, we can call DoSubmit from LaunchManager class. Similary we can call DoApprove and DoDeny from ApprovalManager class. It may be desirable to call these methods after successful save rather than calling them on FieldChange of buttons. This will avoid any validation error which might occur during save processing thereby putting erroneous transaction in the system. Following screenshot shows submit button code and SavePostChange code for DoSubmit method:

2010 Infosys Technologies Limited, India

< Name of the document>

Configurations involved in AWE

Now as we have developed necessary PeopleTools objects required for AWE, we will see the different set-ups involved for AWE to run successfully. Note: The navigations used here are from FSCM 9.1 version. For earlier releases, the AWE setups are mostly located at Setup Financials/Supply Chain > Common Defnitions > Approvals for FSCM and Setup HRMS > Common Definitions > Approvals for HCM. Step 1 - Register Transaction Navigation: Enterprise Components > Approvals > Approvals > Transaction Registry

The transaction registry is first set-up page for AWE. A new process ID will be created in this step which will be used in subsequent set-up pages.

To create approval process, select Add a new value from above navigation and add name of the Approval Process (Test_submit_Req for our example).

Refer following screenshot of Transaction Registry page for approval process in our example:

2010 Infosys Technologies Limited, India

< Name of the document>

2010 Infosys Technologies Limited, India

< Name of the document>

This page involves following configurations:

Setting up cross reference record created in Step 2 of Customization Section for AWE

Notification Options for AWE. Options are for Email, Worklist or both Email and Worklist.

Default Approval Component from where the Approval/Denial of submitted transaction will happen.

Setting up Approval Event handler Package and Class created in Step 4 of Customization Section for AWE

Setting up Thread Description class for Approval Status Monitor created in Step 9 of Customization Section for AWE and Ad-hoc Approver Classes, if implemented

Transaction Approval Levels (either Header or Line level approval). A record name has to specify here which will be transaction header record for Header level approval or transaction detail record for Line level approval

Step 2 - Creating Workflow Generic Templates and Configuring Transaction: This involves two steps: 1) creating the notification templates for the e-mail notifications to be sent 2) configuring these templates and other notification options for the approval process created.

2010 Infosys Technologies Limited, India

< Name of the document>

Creating Workflow Generic Templates: Navigation: PeopleTools > Workflow > Notifications > Generic Templates

Add a new value for the Generic Template.

o Specify the description, sender, Subject and message text which will be used for sending e-mail notifications

Add the Template Variables. Template variables are bind variables whose values will be used from the SQL created in Step 7 of Customization Section at runtime for the given transaction ID and Emplid. Here, the bind %1 is reserved by PeopleSoft for URL to be included in the e-mail notifications. The order of remaining bind variables starting from %2 should match the order of SQL SELECT columns of the SQL in step7.

Following is the screenshot of Generic Template Test Request Routing used in our example for sending e-mail to the approver when Transaction is submitted:

2010 Infosys Technologies Limited, India

< Name of the document>

Configuring Transaction

Navigation: Enterprise Components > Approvals > Approvals > Transaction Registry

Search for the Approval Process created in Step 1

2010 Infosys Technologies Limited, India

< Name of the document>

Configure the Approver User Info view created in step 6 of Customization Section.

o In the Event Section Select Event as Route for Approval and add Approval Menu, Component and Page

o o

Select SQL object created in step 7 of Customization Section.

Under the grid Notifications, select Participant as Approvers, Channel Both and select Generic Template name created earlier.

The event Route for Approval will be triggered after submitting the transaction and the Generic template configured at this event will be used for sending e-mails. Similarly, we can configure for events On Final Approval and On Final Denial for triggering emails for Approval and Denial of the transaction. Following is the screenshot of the Transaction Configuration page:

2010 Infosys Technologies Limited, India

< Name of the document>

2010 Infosys Technologies Limited, India

< Name of the document>

Step 3 - Creating Approver User List User list is used to find approvers for the submitted transaction. The PeopleTools object created in Step 5 of Customization Section should be configured here. Following is the screenshot of User List Test Submit Req created for our example where App Class created in Step 5 of Customization Section is configured as an Approver User List.

The check box Include Users as Input if checked, will pass current user ID to the SQL/PSQuery as a runtime value and the check box Transaction Keys as Input if checked, will pass key values from Transaction Header record for the current transaction as a runtime values to SQL/PSQuery. The SQL/PSQuery should have appropriate bind variables as per these checkboxes.

2010 Infosys Technologies Limited, India

< Name of the document>

Step 4 - Setting up Approval process Navigation: Enterprise Components > Approvals > Approvals > Approval Process Setup

The AWE uses all of its approval stages, steps and paths from this setup. This involves following configurations:

Definition criteria This is used to determine which Definition ID to use at runtime to process the approval. If App Class is selected, the app class should extend EOAW_CRITERIA:CriteriaBase and implement the "Check" method

Alert Criteria This is used to determine if messages (Alerts) should be displayed as part of the approval process.

Both Alert and Definition Criteria are set to Always True in our example.

Definition ID The name of the approval process that was determined upon entry to this component.

Admin Role This is the approvals administrator for this approval definition. This roleuser will have access to Enterprise Components > Approvals > Approvals > Monitor Approvals to perform Admin actions like adding additional approvers to the step (ad-hoc approvers).

Stages A stage is a high level grouping of approval paths. Paths within the same stage are carried out in parallel. In order to achieve sequential path processing, paths need to belong to separate stages. If the process requires going through various approval levels, then as many required stages should be implemented. E.g. Expense Report approval process ERApproval goes through 6 different stages of Approval like HR Supervisor, Pre-pay auditor, Proj Approvers etc.

2010 Infosys Technologies Limited, India

< Name of the document>

Paths Approval Paths are logical groupings of approval steps. Again, paths belonging to the same stage are carried out in parallel. A dynamic source for the path allows users to define one step and requires no step criteria. The AWE will dynamically figure out whether or not to route the transaction to next level or approver(s). When using the Dynamic source, the system uses the user list on the step definition to initialize the steps in the path. The single step definition is repeatedly run, until the step's user list returns no more approvers. All these instances are queued in sequence. While, Static source allows users to define a static number of approval steps and it indicates that you want the system to use the individual user-defined steps when it processes an approval.

Steps Steps represent the individual approval steps within a path. Once all steps in all Paths of particular stage are completed in Approval, the AWE proceeds to next Stage of Approval.

Criteria Criteria can be defined at Process, Path and Step level. There are three types of criteria that can be defined:

Always True Always true simply means that whenever the system

evaluates this criteria it will always return a True to the engine. So whatever process you have associated with these particular criteria will always get executed.

Application Class - If App Class is selected, the app class should extend

EOAW_CRITERIA:CriteriaBase and implement the "Check" method. If the Check returns True, the criteria will be true otherwise false.

User Defined - The User Defined criteria type allows you to set up rules

based on the fields that exist on the header record of your transaction and delivered operands using the user interface shown below

2010 Infosys Technologies Limited, India

< Name of the document>

Criteria Definition page

Following is the screenshot of the approval process for our example.

2010 Infosys Technologies Limited, India

< Name of the document>

Example of the Approval through AWE:

Now, as all technical and functional objects are in place, we can submit the transaction to AWE for the example we have taken in this document.

Step 1 - Submission 1. Navigate to main transaction page and submit the transaction

2010 Infosys Technologies Limited, India

< Name of the document>

Enter values and submit transaction

2010 Infosys Technologies Limited, India

< Name of the document>

This is the description coming from Thread Description Class

Approval Status Monitor

2.

Once the Submit is successful, user will be routed to Approval Status Monitor page which we have implemented in Step 8 of Customization Section. This will show with whom the transaction is currently pending as shown above. Also, note the description about key values on approval monitor which is coming from Thread Description Class we implemented in Step 9 of Customization Section.

3.

Clicking against hyperlink of Approver Name (Scott,William) on Approval Monitor will show information about the Approver coming from Approver User Info view which we have implemented in Step 6 of Customization Section.

Step 2 - Approval

1. For approval, login with the approver ID (KU0006) and go to Worklist. There will be worklist entry for the Test Request ID 00027. Also, note the description of hyperlink under Link column which is coming from Thread Description class

2. Click on the worklist entry to navigate to Approval Page for approving or denying the transaction

2010 Infosys Technologies Limited, India

Name of the document>

This is the description coming from Thread Description Class

<

3. Once the request is approved or denied, employee can see the same on Test Request page and on Approval Status Monitor.

2010 Infosys Technologies Limited, India

< Name of the document>

2010 Infosys Technologies Limited, India

< Name of the document>

E-mail Notification example

The e-mail notifications generated through Generic Templates for Submission and Approval event (configured in Step 2 of configuration section) may look like as shown below:

Submission E-mail Notification

Approval E-mail Notification

Ad-hoc Approver Example

System Admin role person can add additional approvers (called Ad-Hoc approvers) in the path by using Plus Button through Approval Monitor. This can be done by Approver also if Approval Status Monitor is implemented with parameter A to the createStatusMonitor function (refer step 8 from Customization Section).

2010 Infosys Technologies Limited, India

< Name of the document>

An Ad-hoc Application Class should be implemented and configured on Register Transactions page for Ad-hoc feature to work as desired.

Ad-hoc approvers can be added using this + button

2010 Infosys Technologies Limited, India

< Name of the document>

This completes the technical and functional steps involved in configuration of AWE for any application where systematic Approval workflow is desired.

Important Records in AWE

Following table list some of the important records in AWE: Record Name EOAW_IDS EOAW_STEPINST EOAW_USERINST EOAWCRTA EOAWUSER_LIST EOAW_NOTIFY EOAW_PATH EOAW_PRCS EOAW_STAGE EOAW_STEP EOAW_TXN EOAW_WL Description AWE Seed record. Contains cross-reference record and initial thread ID. Contains info on Approval Step Instance for all Steps in particular Stage. Contains info about every Step Instance from EOAW_STEPINST. It basically shows all the Approver Users involved for every step in the Approval Stage and Approval Status of every Step. Criteria Definitions for Approval Process. Approver User List for Approval Process. Contains Approval Events Notification data for Approval Process. Approval paths in Approval Process. Approval Process information. Approval Stages in Approval Process. Approval Steps in Approval Process. Approval Transaction Registry data. Approval Worklist data for Approval Process.

Reference(s) 1. PeopleSoft Enterprise FSCM 9.1 PeopleBook: Approval Framework Oracle Published Red Paper on Approval Workflow Engine

2.

2010 Infosys Technologies Limited, India