Setting Up Dashboard Actions

This chapter provides an overview of dashboard actions and discusses how to set them up.

Understanding Dashboard Actions

This section discusses:

Actions.
Action architecture.
Action security.

Actions

Dashboard actions are the “operational” part of operational analytics, enabling a dashboard user to act on the data that the dashboard presents. For example, a user can send email, reassign leads, escalate cases, or cancel orders right in the dashboard, without returning to the underlying PeopleSoft Internet Architecture (PIA) system. For even greater efficiency, the dashboard user can select multiple transactions to include in the actions.

To perform an action, users first select the transactions to act on. Standard dashboard filters enable users to narrow the selection on a report to a particular set of transactions, then the users drill into an action form that presents a list of individual transactions that can be selected for action. The action form also includes group boxes for entering action-specific information such as email content, new lead assignees, and so forth.

For example, if the Support dashboard shows a growing call backlog, the call center manager might start by looking at the data in different ways to discover whether there are specific types of cases or particular provider groups that are responsible for large parts of the backlog. If a particular chart shows that provider group A has a disproportionately high backlog, then the manager can easily navigate to an action form that is already prefiltered to show the cases for that provider group. Depending on the action selected, the manager can reassign cases to another provider group or take another appropriate action.

Action Architecture

Users initiate actions from a dashboard action form, a type of report in Oracle Business Activity Monitoring (Oracle BAM). Information about submitted actions is saved to the active data cache (ADC). The data object that stores the action request has one row for each transaction in the action request, regardless of how many transactions the user submitted at once.

An alert monitors the data object where the action information is stored, and for each new row in the data object, the alert sends a message to the transactional system where the actions are performed.

As changes are made in the transactional system, the regular dashboard messaging system sends the updated data to the dashboard where it is immediately reflected in dashboard reports. If there are errors that prevent the action from happening, an error message is sent to the dashboard system and displayed as an alert.

The following diagram illustrates action architecture:

Action architecture

Dashboard-Side Architecture

Every dashboard action has the following Oracle BAM elements:

An action form where the user triggers the action.

The form is specific to a particular action. On the form, the user indicates which transactions are to be acted on and any additional parameters required by the action. For example, the action that reassigns cases requires an additional parameter for the new assignee. Not all actions require additional parameters.
A data object where information about submitted actions is stored.

When the user submits the action, the system saves the information to the ADC in a data object that is specific to the action. One row of data is created for each transaction that is impacted. Individual dashboard applications deliver plans that delete old data from action data objects.
An alert that sends a message to the transactional system for each row of data that is added to the data object.

Each message includes an action ID, transaction keys, and any necessary action parameters.

In addition to the data objects that are specific to individual actions, there is a common data object, /System/Action/ADC_ACTION, with fields such as action request ID that are common to all actions. The PT.Delete Action Request plan deletes all entries that are over three months old. An administrator must run this plan manually on a regular basis.

PIA-Side Architecture

In the PIA system, a central action handler receives the action messages and invokes the application classes that execute the actions. Actions must be predefined in the system so that the action handler can invoke the appropriate application class based on the action ID.

Action Security

Within PIA, you associate actions with PeopleTools roles so that only users with the specified roles are able to perform the action. When the PIA action handler processes an action request, it verifies that the requestor has access to the action before performing the action. If the requestor does not have access, the action handler sends an error message to the dashboard system; this message appears on the user's alert list.

To prevent dashboard users from requesting actions that they are not authorized to perform, security for the action request forms in the dashboard system must be the same as the security that you set up in PIA. PeopleSoft dashboard applications are delivered with matching security settings. If you want to change the security settings, you must make your changes twice: once in the dashboard system and once in PIA.

Note. Because the dashboard system also enforces row-level security, users normally can't even submit action requests for transactions to which they do not have access (for example, if your organization secures data by business unit). However, if such a request were to be submitted, row-level security within PIA is still enforced and the action request would not be honored.

Setting Up Actions

This section lists a prerequisite and discusses how to:

Identify action application classes and parameters
Define action security.
Test an action.

Important! If you develop custom actions, you must register them and secure them in the Actions setup component. However, delivered actions are already registered in the Actions setup component. Setup for delivered actions is limited to optionally modifying the security for the action.

Prerequisites

If you are registering and securing custom actions, you must first create the application class that performs the action. To do this, extend the PT_CDB_ACTION:RUNTIME:ActionHandler application class and implement the runAction method.

If you are modifying the security settings for a delivered action or a custom action, set up the PeopleTools roles that you will use to secure the action.

Pages Used to Set Up Actions

Page Name	Object Name	Navigation	Usage
Action Setup	PT_CDB_ACTION	Set Up CRM, Product Related, Dashboard, Action, Action Setup	Identify the application class that performs the action and identify the parameters that the application class requires.
Action Security	PT_CDB_ACTION_SEC	Set Up CRM, Product Related, Dashboard, Action, Action Security	Grant access to the action based on PeopleTools roles.
Action Test	PT_CDB_ACTION_TEST	Set Up CRM, Product Related, Dashboard, Action, Action Test	Test your custom actions by initiating them from PIA. This page is a tool for developing new actions; it is not necessary to test delivered actions.

Identifying Action Application Classes and Parameters

Access the Action Setup page.

Actions

Action ID	Displays a system-generated unique identifier for the action.
Action Name and Description	Enter a meaningful name and description for the action. These do not appear anywhere else—they are used only to identify and describe actions in this component and in the search page for this component.
Application Class Path	Enter the full path for the application class that performs this action. The application class must be extended from the PT_CDB_ACTION:RUNTIME:ActionHandler class and implement the runAction method.

Parameter List

Enter a row of data for each parameter that the application class accepts.

Required and Parameter Name

Enter the name of each parameter, and select the Required check box if the parameter is required. If the Validate Action Parameter Type check box on the Installation Options page is selected, then the action handler verifies that all required parameters are present before invoking the runAction method in the application class that performs the action.

Parameter Data Type

Select from the following options: Date, DateTime, Number, String, and Time.

If the Validate Action Parameter Type check box on the Installation Options page is selected, the action handler will verify that all the parameters have the right data type.

Defining Action Security

Access the Action Security page.

Role Name

Select the PeopleTools role that grants access to the action.

Important! When you set up security for a custom action or when you change the delivered security settings for a delivered action, make the corresponding changes to security for the action forms in the dashboard system. Otherwise, dashboard users might have access to forms for actions that they are not permitted to perform. In this situation, the user can request the action from the dashboard system, but the action request is not honored in PIA.

Testing an Action

Access the Action Test page.

Test Asynchronously

Select to invoke the action handler for action testing. Using the action handler creates test conditions that are closer to true runtime conditions (though not identical because the action request is not coming from the dashboard system).

If you clear this check box, then testing the action calls the application class directly, bypassing the action handler when the focus of your testing is your application class code.

Parameter Name and Value

The page displays the parameter names that you set up on the Action Setup page. Enter the values to use for each parameter during the test.

Test Action

Click this button to invoke the action.

Test Result

Displays any messages that the application class generates as a result of the test.

Test Asynchronously	Select to invoke the action handler for action testing. Using the action handler creates test conditions that are closer to true runtime conditions (though not identical because the action request is not coming from the dashboard system). If you clear this check box, then testing the action calls the application class directly, bypassing the action handler when the focus of your testing is your application class code.
Parameter Name and Value	The page displays the parameter names that you set up on the Action Setup page. Enter the values to use for each parameter during the test.
Test Action	Click this button to invoke the action.
Test Result	Displays any messages that the application class generates as a result of the test.