Search Results ghr_process_log




Overview
Explore in AI Chat

Overview

GHR_PROCESS_LOG is a table owned by the HR schema in Oracle E-Business Suite, delivered as part of the GHR - US Federal Human Resources product family. Its documented purpose is to store log information generated by various batch processes executed within the Federal HR modules. As a diagnostic and audit artifact, the table records the textual output, program identity, and timing details associated with process executions, allowing administrators and support analysts to trace what a batch job did, when it ran, and what messages it produced.

From a data modeling perspective, the ETRM metadata classifies GHR_PROCESS_LOG heuristically as a standalone object within a Data Vault style model. In practical terms, this suggests the table behaves as an independent satellite-like record — it stores descriptive log content keyed by its own surrogate identifier rather than participating in a hub-and-link network of foreign key relationships. No foreign key dependencies are documented, reinforcing that GHR_PROCESS_LOG is a self-contained logging repository rather than a transactional entity integrated into the Federal HR relational fabric.

Key Information Stored

The table documents ten columns in the ETRM 12.2.2 physical schema. The most significant are listed below.

  • PROCESS_LOG_ID — the surrogate primary key, uniquely identifying each log entry. It is enforced by the unique index GHR_PROCESS_LOG_PK, which is the sole documented unique index and therefore the only business-key candidate.
  • PROGRAM_NAME — identifies the concurrent program or batch routine that generated the log entry, enabling filtering by process.
  • LOG_TEXT — the free-form textual payload of the log, containing messages, diagnostics, and status detail emitted during execution.
  • MESSAGE_NAME — the identifier of the message associated with the log entry, typically referencing an Oracle Applications message definition used for internationalization or standardized reporting.
  • LOG_DATE — the business date/time at which the log record was produced.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard Oracle EBS audit columns capturing the most recent modification context.
  • CREATION_DATE, CREATED_BY — the standard audit columns capturing the original insert context.

The surrogate key PROCESS_LOG_ID is purely technical; no natural business key is documented beyond the primary key itself, which is consistent with the standalone classification.

Common Use Cases and Queries

Typical usage centers on troubleshooting and operational reporting for Federal HR batch processing. Analysts query the table to reconstruct the sequence of events for a given run, to identify which programs produced errors, and to correlate log entries with execution windows.

  • Retrieving all log lines for a named program within a date range: SELECT PROCESS_LOG_ID, PROGRAM_NAME, LOG_DATE, LOG_TEXT FROM HR.GHR_PROCESS_LOG WHERE PROGRAM_NAME = :program AND LOG_DATE BETWEEN :start_date AND :end_date ORDER BY LOG_DATE;
  • Searching for error or warning text: SELECT * FROM HR.GHR_PROCESS_LOG WHERE UPPER(LOG_TEXT) LIKE '%ERROR%' AND LOG_DATE > SYSDATE - 7;
  • Grouping activity by program to assess volume and frequency: SELECT PROGRAM_NAME, COUNT(*), MIN(LOG_DATE), MAX(LOG_DATE) FROM HR.GHR_PROCESS_LOG GROUP BY PROGRAM_NAME;
  • Auditing recent changes using the standard audit columns: SELECT * FROM HR.GHR_PROCESS_LOG WHERE LAST_UPDATE_DATE > SYSDATE - 1;

Because the table is standalone, these queries do not require joins to resolve the log content, simplifying report development and ad hoc diagnostics.

Related Objects

The ETRM metadata documents no foreign key relationships for GHR_PROCESS_LOG, and its Data Vault classification is standalone. Consequently, the table is not formally linked to parent or child objects through database constraints. In practice, related objects are those that reference or are referenced by convention rather than by enforced keys:

  • GHR_PROCESS_LOG_PK — the unique index backing the primary key on PROCESS_LOG_ID.
  • FND_CONCURRENT_REQUESTS — the standard concurrent processing table, commonly correlated with GHR_PROCESS_LOG by request identifier or program name during troubleshooting.
  • FND_CONCURRENT_PROGRAMS — provides the definition for the program named in PROGRAM_NAME.
  • FND_MESSAGES — supplies the message definition referenced by MESSAGE_NAME.
  • FND_LOG_MESSAGES — the Oracle Applications logging table, which may complement GHR_PROCESS_LOG for diagnostic tracing.
  • HR.GHR_* batch-related tables — other Federal HR process tables that write to or consume process output indirectly.

Administrators should rely on PROGRAM_NAME, LOG_DATE, and the standard audit columns as the primary access paths when correlating GHR_PROCESS_LOG with concurrent processing and message definitions.