Search Results pqh_process_log_api




Overview
Explore in AI Chat

Overview

The APPS.PQH_PROCESS_LOG_API package is the public application programming interface for the process log infrastructure within the Oracle E-Business Suite HRMS product family. The PQH prefix identifies it as part of the Public Sector and HRMS shared components, and the process log entity serves as a central audit and traceability repository for long-running or batch-oriented processing performed against HRMS data. Its principal purpose is to record, amend, and remove entries that describe the state, timing, and diagnostic messages associated with a transactional process. In Oracle EBS 12.1.1 and 12.2.2, this package is classified as an API in the ETRM repository, meaning it is intended for programmatic invocation by other application modules and by extensions rather than being a user-facing form.

The package presents a conventional EBS API contract: a validation flag that controls whether changes are committed or rolled back, an effective date for date-tracked operations, and a substantial set of descriptive attributes. Its header indicates an origin dated 2005, consistent with the shared HRMS foundation layer that has remained stable across both release levels.

Key Procedures and Functions

The ETRM metadata documents three procedures, forming a complete create, update, and delete lifecycle over the process log record.

  • CREATE_PROCESS_LOG — Inserts a new process log entry. It accepts a validation flag, a module code, a transaction identifier, an optional master process log identifier (allowing parent and child log entries to be linked), message text and message type, an optional batch status with associated batch start and end dates, a transaction table route identifier, a log context value, and thirty information columns. The effective date parameter governs date-tracked validation. On a successful validation the row is inserted; when validation mode is requested, the work is rolled back.
  • UPDATE_PROCESS_LOG — Modifies an existing process log record, permitting the same descriptive attributes to be revised as a transaction progresses, for example to advance a batch status or append diagnostic information.
  • DELETE_PROCESS_LOG — Removes a process log record, supporting cleanup of transient or obsolete log entries.

Each procedure follows the standard HRMS API convention of exposing both a row-handler and an entity-level entry point, with the row handler performing the underlying DML and user-hook style validation.

Tables Accessed

The package operates against the PQH_PROCESS_LOG table, accessed through an APPS synonym. This table is the persistent store for the process log entity. The information columns supplied by the API are mapped to the corresponding descriptive flexfield segments and attribute columns of that table, while the batch status and batch date parameters populate the batch tracking columns used to report progress of bulk operations. Because the package is an API rather than a view or report, its access is uniformly read-write: create inserts, update modifies, and delete removes rows in PQH_PROCESS_LOG.

Usage Notes

PQH_PROCESS_LOG_API is normally invoked from PL/SQL rather than from an Oracle Forms interface. It is referenced by five other application packages in the ETRM inventory, which is characteristic of a foundational service that other HRMS modules call to record their own processing activity. Custom code and concurrent programs that need to surface progress, errors, or completion status to the end user should call the API rather than performing direct DML on PQH_PROCESS_LOG, thereby preserving validation, effective dating, and information-column handling.

Two practical cautions apply. First, callers should honor the validation parameter so that partial writes do not persist during trial execution. Second, because the entity is date-tracked, the effective date must be supplied with an appropriate value to avoid unexpected validation failures. The package should be treated as a controlled interface: changes to its behavior arrive only through Oracle patches, and direct table modification is unsupported.