Search Results set_report_approver




Overview
Explore in AI Chat

Overview

PA_REPORT_WORKFLOW_CLIENT is a public PL/SQL client-extension package in the Oracle Projects (PA) product. It provides the integration layer between Oracle Projects project status reports and the Oracle Workflow engine, enabling organizations to customize the workflow processes that submit, approve, and publish a project status report. The package is declared AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the invoking user rather than the definer, and it is classified as an "OTHER" API within the ETRM registry.

In Oracle EBS 12.1.1 and 12.2.2, project status reporting follows a configurable lifecycle: a report is drafted, routed to approvers, and finally published to its audience. PA_REPORT_WORKFLOW_CLIENT exposes the extension points that control the approver resolution and notification party logic within that lifecycle. Customers and partners implement the corresponding client-extension stubs so that approval routing and notification lists reflect their own business rules — for example, deriving approvers from project team assignments or from a site-specific approval hierarchy. The package is documented in the Oracle Projects API's, Client Extensions, and Open Interfaces Reference (120pjapi.pdf) and carries a compatibility rating of "S" (supported).

Key Procedures and Functions

  • START_WORKFLOW — Initiates the workflow process associated with a status report action. It accepts the workflow item type, process name, item key, and version identifier of the report, and returns message count, message data, and a return status so the caller can evaluate the outcome of the launch. This procedure is the entry point that hands control of a report submission or approval cycle to the Workflow engine.
  • SET_REPORT_APPROVER — Resolves and assigns the approver for a status report within a running workflow process, using the process name, item key, action identifier, and workflow function mode as inputs, and returning a process result. This is the extension point named in the user's search. Implementations typically override the default approver derivation to select the appropriate responsible party for the report.
  • SET_REPORT_NOTIFICATION_PARTY — Determines the party or parties who should receive status report notifications based on the workflow item type, item key, and current report status, together with the action identifier and function mode, returning a process result. It governs the distribution list for report-related notifications produced during the workflow.

Tables Accessed

  • PA_PROGRESS_REPORT_VERS — Stores the report version records whose workflow state and version identifier drive the extension procedures.
  • PA_PROJECT_PARTIES and PER_ALL_PEOPLE_F — Provide the project team members and person records used to derive approvers and notification recipients.
  • FND_USER and WF_LOCAL_ROLES — Supply application user and workflow role/recipient information required to route notifications correctly.
  • FND_ATTACHED_DOCUMENTS — Holds attachments linked to report objects, which may influence notification content and routing.
  • PA_OBJECT_PAGE_LAYOUTS — Defines page layout configuration for project objects referenced during report processing.
  • PLITBLM — The PL/SQL message table used to accumulate and return error and informational messages to the caller.

Usage Notes

PA_REPORT_WORKFLOW_CLIENT is invoked in the background by the Oracle Projects status report workflow itself rather than by interactive users directly. It is not a standalone concurrent program.

Typical invocation scenarios include: the status report submission and approval workflow selecting approvers through SET_REPORT_APPROVER; notification activities choosing recipients through SET_REPORT_NOTIFICATION_PARTY; and the workflow launch itself through START_WORKFLOW. Custom code and Oracle Projects forms that trigger or monitor the status-report workflow may reference these procedures indirectly through the workflow definitions. Customizations are implemented as client-extension bodies containing customer logic, registered against the documented interface, so that the base workflow definition remains intact. Because the package runs AUTHID CURRENT_USER, any custom implementation must be granted appropriate access to the referenced tables and the caller must hold the necessary privileges.

Only one other package in the EBS instance references this package, indicating a relatively narrow integration surface. When upgrading from 12.1.1 to 12.2.2, custom implementations should be re-validated against the documented procedure signatures, as the header history shows the package was last revised at version 120.5.