Results for “ghr_interface”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

GHR_INTERFACE is a general-purpose interface staging table residing in the HR schema and owned by the GHR (US Federal Human Resources) product module. It serves as a landing and holding area for inbound or outbound data exchanged between Oracle E-Business Suite and the various external systems, agencies, and third-party applications that interact with Federal HR processing. The table is present and VALID in both Oracle EBS 12.1.1 and 12.2.2. In the 12.2.2 physical schema documented in ETRM, the table is defined with 185 columns.

The object is characterized in ETRM as a standalone table based on a heuristic Data Vault classification mined from its foreign key structure. In Data Vault modeling terms, this suggests the table behaves as an isolated hub-like or staging construct rather than participating in a tightly normalized link/satellite network — a reasonable pattern for a generic interface staging table that does not enforce referential dependencies on other business entities.

Key Information Stored

The table's design is deliberately generic, relying on a single controlling identifier and a large bank of position-agnostic data slots. The most important columns are:

• INTERFACE_ID — The primary key (GHR_INTERFACE_PK) and sole unique business-key candidate. Every row is uniquely identified by this surrogate identifier.
• PROCESS_DATE — The date the interface record is processed or intended for processing.
• SOURCE_NAME — Identifies the originating system or interface source.
• DATE_FROM / DATE_TO — Effective date boundaries for the interface payload.
• INFORMATION1 through INFORMATION175 — A wide span of generic, untyped attribute slots for staging interface data. Because the schema is general purpose, the semantic meaning of each INFORMATION column is determined by the specific interface using the table rather than by a fixed column definition.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, standard WHO columns typical of Oracle EBS tables.

The reliance on numbered INFORMATION columns rather than named business attributes is the defining characteristic of this table and reflects its role as a flexible interface buffer.

Common Use Cases and Queries

Typical usage centers on staging, reconciliation, and audit reporting for Federal HR interfaces. Common scenarios include retrieving records for a specific source within a date range, and confirming which interface rows have been processed on a given date.

Sample query:

SELECT INTERFACE_ID, SOURCE_NAME, PROCESS_DATE, DATE_FROM, DATE_TO
FROM HR.GHR_INTERFACE
WHERE SOURCE_NAME = :source
AND PROCESS_DATE BETWEEN :from_date AND :to_date;

Because the INFORMATION columns are generic, reporting queries must map each slot to its interface-specific meaning, often by joining to interface configuration or lookup metadata maintained for the relevant Federal HR process. Reconciliation queries typically compare row counts and PROCESS_DATE values against the downstream target tables to detect records that were staged but never applied.

Related Objects

ETRM documents no foreign key relationships for GHR_INTERFACE; the heuristic classification is standalone. Consequently, related objects are not FK-linked but are associated through shared module (GHR) and by the interfaces that populate and consume its rows. The most significant associations are:

• GHR_INTERFACE_PK — the unique index enforcing the INTERFACE_ID primary key.
• HR schema Federal HR base tables — the employee, position, and payroll entities that interface payloads are staged against before loading.
• Interface-specific staging and target tables within the GHR module that map INFORMATION slots to named attributes.
• Oracle EBS concurrent programs for Federal HR interfaces that insert into and read from the table, keyed by SOURCE_NAME and PROCESS_DATE.

Searches for "ghr_interface" typically return this object in the context of Federal HR interface troubleshooting, where DBAs and developers inspect staged rows to validate inbound/outbound data integrity.