Setting Up the Transaction Registry
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 Used to Set Up the Transaction Registry
Page Name |
Definition Name |
Navigation |
Usage |
---|---|---|---|
Register Transactions |
EOAW_TXN |
|
Register the approval transaction. |
Register Transactions Page
Use the Register Transactions page (EOAW_TXN) to register the approval transaction.
Image: Register Transactions page (1 of 3)
This example illustrates the fields and controls on the Register Transactions page (1 of 3). You can find definitions for the fields and controls later on this page.
Image: Register Transactions page (2 of 3)
This example illustrates the fields and controls on the Register Transactions page (2 of 3). You can find definitions for the fields and controls later on this page.
Image: Register Transactions page (3 of 3)
This example illustrates the fields and controls on the Register Transactions page (3 of 3). You can find definitions for the fields and controls later on this page.
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.
Notification Options
Identify whether you will be using email or worklist notification, or both.
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.
Default Approval Component
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. |
Approval Event Handler Class
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. The action the system takes depends on how the application developer defines the line sourcing. If the lines are sourced as they are approved, then nothing has to be done when all the lines are processed. This event is distinct from HEADER_APPROVED, and having a distinct notification simplifies the process. |
See PeopleTools: PeopleCode Developer's Guide
Approval Status Monitor
Use this section to control how the system processes ad hoc approvers. Any approver can add or remove ad hoc approvers.
Transaction Approval Levels
Use this section to define if the transaction is to be approved at the header or line level and what level the application supports.