This chapter provides an overview of the approval transaction registry, lists prerequisites, and discusses how to:
Register approval transactions.
Configure approval transactions.
The approval transaction registry is the interface application that developers use to register an application with the Approval Framework. Transactions that require approvals are candidates for being linked to Approval Framework. You use the Register Transactions page to link the components, event handler, records, and classes that you created into the approval process for an application transaction, such as a requisition or purchase order. Application developers register the main records and components that make up the transaction, then functional business analysts select the approval transaction on which to base the approval process definition.
Note. Any PeopleSoft delivered approvals will already have the Approval Transaction Registry populated. No additional configuration is typically needed.
Before defining the transaction registry:
Create a Transaction Handler Application class that extends an approved event handler class delivered by Approval Framework.
Create transaction data sources, as needed.
Create views on transaction tables that will serve as criteria sources.
Use the Register Transactions component to register an approval transaction. The transaction definition is the metadata that describes the transaction setup to the Approval Framework.
Page Name |
Definition Name |
Navigation |
Usage |
EOAW_TXN |
Enterprise Components, Approvals, Approvals, Transaction Registry |
Register the approval transaction. |
Access the Register Transactions page (Enterprise Components, Approvals, Approvals, Transaction Registry).
Application developers use this page to register a PeopleSoft application, such as eProcurement or job offer, with the Approval Framework. Using this page, you can define how the system interacts with portions of the application that you have defined for approvals. The transaction definition is the metadata which describes the transaction make up to the approval framework. In some cases, you might add a transaction to enhance an existing transaction or make changes to a transaction.
Use this page to define:
Worklist approvals.
Approval event handler class.
Transaction approval levels.
Email notifications.
Ad hoc approver class logic.
Process ID |
Enter a name the system uses to track this Approval Framework process for a transaction. You can also enter a description for the approval process. |
Object Owner ID |
Select the PeopleSoft application to which this object belongs. |
Select the table used to manage application specific transaction records and associate them with the approval process run time instances. Each time a request launches an approval process, the system tracks the process by the header and line-level records of the application. To relate the approval process instance to the transaction instance, the cross-reference table holds the correspondence. For a given application transaction record, this cross-reference information helps you determine the pending Approval Framework process and to define to the application which transaction is being approved or denied. Application developers must create a record containing the applications keys, and include the Approval Framework-supplied subrecord EOAW_XREF_SBR. Developers must also build the underlying table. |
|
Worklist Prefix |
Enter a prefix to identify the worklist to a specific application. Every application using the Approval Framework shares the same business process and activities, which can cause a problem identifying specific worklist instances. This prefix will allow worklists to be sorted by application. The prefix should be used:
|
Identify whether you will be using email or worklist notification, or both.
Enable Notifications |
Determine what type of notifications your company will use. The options include:
|
Notification Strategy |
It allows the email to be processed immediately (Online Processing) or offline (Offline Processing) through NEM (Notification and Escalation Manager). |
Use Email Approvals |
Defines that you are going to use email approvals with workflow. |
Form Generator Package Root |
This package root reads the threads provided by the Form Generator Class, and creates a form from an existing email collaboration definition. |
Form Generator Class Path |
Calls the From Generator Class which receives a list of threads to be approved and a language code. This class returns a runtime class, which will add the appropriate recipients and send the emails. |
Internal URL Definition
Use this section to define the internal URL to identify the URL base, portal and node. Internal URL is used to send email to a user either in batch or Integration Broker process. When the process is run online, the built-in properties %Portal and %Node are used.
External URL Definition
Use this section to define the external URL to identify the URL base, portal and node. External URL is used to notify any step that has a been set to External.
Identifies the default component that users should go to when selecting a worklist entry.
Menu Name |
Select the menu name that contains the component you want to register for the Worklist. |
Approval Component |
Select the component on which the approval is going to be based. |
Use this section to define the application class used to monitor events for this transaction. Each time an event occurs, the Approval Framework notifies the application. For applications to receive the notifications, application developers must extend the event handler class, ApprovalEventHandler.
When a transaction results in an action from the Approval Framework, the event handler class you specify how to proceed with the transaction.
The event handler base class defines the handler methods that you can override by extending classes. The extending class must have a no-argument constructor, since the system instantiates the class with no arguments.
This table explains some of the various event handler methods for which the system passes arguments to provide the specific context for each event, and gives examples of how an application, in this case PeopleSoft eProcurement, may act:
Event |
Parameters |
Possible Application Actions |
PROCESS_LAUNCHED |
|
|
HEADER_DENIED |
Header record |
|
LINE_DENIED |
Line-level record |
Deduct the line amount from the header, and delete or otherwise deactivate the line item. |
HEADER_APPROVED |
Header record |
|
LINE_APPROVED |
Line level record |
Source the line item if it's configured for sourcing. |
PROCESS_TERMINATED |
Header record |
Log the event on the application, possibly highlighting changes since the previous submission. This might be useful for approvers who acted on the previous submission of this request. |
ALL_LINES_PROCESSED |
Header record |
Note. The system calls this method only if the last stage
is at the line-level, and the analyst has configured the process to trigger
LINE_APPROVED end calls as individual lines are approved. |
Root Package ID |
Select the parent application class through which events are exposed. This defines the action to take based on events. |
Path |
Select a path that uses a specific class within the root package. |
See Enterprise PeopleTools PeopleBook: PeopleCode Developer's Guide.
See Using Approval Framework Base Classes.
Approval Status Monitor
Use this section to control how the system processes ad hoc approvers. Any approver can add or remove ad hoc approvers.
Adhoc Package |
Select the ad hoc application class package that you want to use for ad hoc approvals. |
Adhoc Class |
Select the ad hoc application class path. Adding approvers and reviewers is handled by the class you define here. If no class is specified, then the system default class is used. If the transaction has further restrictions an application developer needs to create a class that will be defined here. |
Thread Package |
The package here defines how the transaction details are displayed in the system in the status monitor. Behind the scene approvals are defined with a sequence number, this allows for a user friends display. Important! Leave this field blank if the transaction is set up on the Configure Transactions page to send notifications to participants with a URL pointing to an alternate page other than the default destination (as specified in the Events section). For example, you might configure the transaction to generate a URL within each notification that takes an approver to the default component page to approve or deny any given request, and generate another URL for other participants to access a separate page (as specified for that group of users in the Notifications section) and perform other actions pertaining to the request. To ensure that the URLs are created correctly for all approval participants, do not enter a thread package. |
Thread Class |
Enter the specific class within the thread description package and the worklist description that sets the display details. |
Use this section to define if the transaction is to be approved at the header or line level and what level the application supports.
Level |
Select Header or Line, which determines the levels that are enabled by the application for approvals. The first row will always be the header level. |
Record (Table) Name |
Select the database table that represents this transaction level. |
Level Record Key Field Label IDs |
Use this section to identify the label IDs that are used when viewing the Monitor Approvals page. All key field names appear for each record (table) name that is listed. |
Use the Configure Transactions page to select and define elements that determine what triggers a notification, who receives the notification, and the content of the notification. Notifications are mapped to work with the approval transaction registry and include menus and components and SQL definitions.
Page Name |
Definition Name |
Navigation |
Usage |
EOAW_TXN_NOTIFY |
Enterprise Components, Approvals, Approvals, Transaction Configuration |
Use the Configuration Transactions page to configure how the system uses the particular implementation of approval triggers. |
Access the Configure Transactions page (Enterprise Components, Approvals, Approvals, Transaction Configuration).
Use this page to select and define elements that determine what triggers a notification, who receives the notification, and the content of the notification. Notifications are mapped to work with the approval transaction registry and include menus and components and SQL definitions. The events for which the system sends notifications include:
Launch of the approval process on a transaction.
Queue of approval step to an approver.
Queue of a review step to a reviewer.
Denial of a line or header.
Approval of a line or header.
Completion of the approval process.
Recipients of notifications include requesters, approvers, and reviewers, who can receive their notifications through either worklist entries or email notification. When using email notifications, business analysts must create email templates.
Ad Hoc Approver Options
Approver User Info View |
Provides details about which view a user sees when using the Approval Monitor. Note. Data in this view dictates what is displayed in the approver links. |
Ad Hoc User List |
This is a filter used to display only a list of users who can be ad hoc approvers. |
Notification Options
This section appears when the Use Email Approvals check box is selected for the Process ID on the Register Transactions page.
Send Email Approvals to All |
Select to send email notifications to all approvers. |
Email Approval User List |
Specify exactly which users should be allowed to do their approval by using email. Note. If the user receiving the notification also falls into the email approval user list, then they receive an email approval rather than a standard email notification. |
Delivery Method |
Define whether you wish the users to receive their email approvals as text within the email, or as attachments. |
Perform Sent-To Security Check |
Selecting this check box informs the system that you want it to verify the security of the person the notification is sent to. Note. This security check is only performed on new approvals. |
User Utilities
User Utilities are the mechanism that the user changes to modify the behavior of delegation and reassignment.
User Utilities Package |
Select the parent application class through which alternate users are selected. |
User Utilities Path |
Select a path that uses a specific class within the root package. |
Events
Use the events section to define event parameters to trigger workflow notification.
Level |
Select Header or Line to determine the level at which you want a notification sent for an event. For each of these events to be notified, you must select the level of the transaction. |
Event |
Select the event for which you want to send a notification. The approver is always notified of an event. The requester and the system administrator is notified when an error occurs. Event values include: Ad Hoc Delete: Send a notification when a step is removed from the approval process through the status monitor. Ad Hoc Insert: Send a notification when a step is added to the approval process through the status monitor. Hold Step: Send a notification when a thread is placed on hold. Locked Out: Send a notification when the application workflow engine (AWE) encounters a user whose account has been locked out. No Approver Necessary: Send a notification when a thread does not route because no approval is necessary. On Error: Send a notification when a thread encounters a routing error. On Escalate: Send a notification when a thread is escalated through the NEM process. On Final Approval: Send a notification when a thread is approved and there are no more steps to process. On Final Denial: Send a notification when a thread is denied and there are no more steps to process. On Process Launch: Send a notification when an approval process is submitted. On Reactivate: Send a notification when a step is reactivated for a thread. On Reassign: Send a notification when a thread is reassigned to a new approver. On Step Complete: Send a notification when a step no long has pending threads. On Terminate: Send a notification when a thread is terminated. Processing Complete: Send a notification when an approval process is complete. Push Back: Send a notification when a thread is pushed back from one step to the prior step. Request Information: Send a notification when the Request Information action is called by the application. Request Information Added: Send a notification when a comment is added for a thread and that thread has been placed on hold. Route for Approval: Send a notification when a thread is routed to an approver. Route for Review: Send a notification when a thread is routed to a reviewer. Note. The Lock Out, On Process Launch, and Processing Complete events are for header level only. |
Menu Name |
Select the menu name that contains the component you want the notification recipient to link to. This identifies where the person should go upon notification. If you do not enter values, the recipient is sent to the same menu and component that is defined for the Worklist Approval component. |
Approval Component |
Select the component you want to make available to the notification recipient. |
Page Name |
The page defined is the page approvers are redirected to from the URL sent within the email notification. |
Menu Action |
This is the action of the page users see when directed to the page from the URL sent within the email notification. |
SQL Object Identifier (structured query language object identifier) |
Select the SQL definition identifier you want to use to get content for the email. The SQL must accept bind inputs equal to the number of keys at the notification level. For example, header or line keys. |
Notifications
Use the Notifications section to define who to notify and how to notify them in addition to the defaults determined in the Events section of this page.
Participant |
Define the user who is notified when this event takes place.
|
Channel |
Defines how the participant will be notified. Values are:
Note. Routing preferences can also be set up in PeopleTools, Security, User Profiles, Workflow. From there you have two options. You can select Worklist User and or Email User. |
User List |
Select either Dynamic or User List as the participant. The option becomes active when you select one of these values. |
Template Name |
Select the generic template you want to use for the email content of this notification. You define the contents of the email using the Generic Template page. |
Menu Name, Approval Comment, Page Name, Menu Action, and SQL Object Identifier |
All of these fields have the same definition as the corresponding fields in the Events section of this page. |
Number of Hours |
Enter a number that determines how many hours between notifications. |
Max Notification (maximum notification) |
Enter a number that determines the maximum number of notifications sent. If the approver does not take action, an escalation is sent to the administrator. |