Search Results exception_sequence

Overview

HR_PUMP_BATCH_EXCEPTIONS is a standalone table in the PER (Human Resources) product schema of Oracle E-Business Suite, valid in both release 12.1.1 and 12.2.2. Its documented purpose is to hold data pump processing exception (error) information. The Data Pump architecture in Oracle HRMS is the batch mechanism that moves large volumes of person, assignment, and related records between business groups or legislative environments; when a pump batch encounters a row that cannot be processed, the exception details are written to this table rather than aborting the entire run. The table therefore functions as the diagnostic ledger for Data Pump execution, allowing administrators to reconcile rejected records, correct source data, and resubmit batches.

The supplied metadata classifies this object heuristically as standalone under a Data Vault style model. In that modeling convention it behaves as a satellite-like structure — a single-column surrogate primary key with no documented foreign key relationships to other entities, capturing descriptive exception attributes rather than acting as a hub or link between business keys.

Key Information Stored

The table is compact, with six documented columns in the 12.2.2 physical schema. The most significant are:

• EXCEPTION_SEQUENCE — the surrogate primary key, enforced by the unique index HR_PUMP_BATCH_EXCEPTIONS_PK. This is the only documented unique index and therefore the sole business-key candidate; it uniquely identifies each exception row within the table.
• SOURCE_ID and SOURCE_TYPE — together they identify the source record or entity that triggered the exception, allowing an administrator to locate the offending row in its originating table.
• EXCEPTION_TEXT — the human-readable error message describing what failed during the pump step, which is the primary diagnostic payload consumed by support and HR operations staff.
• EXCEPTION_LEVEL — indicates the severity or category of the exception, distinguishing warnings from hard failures so that only blocking errors are routed for remediation.
• FORMAT — describes the formatting context of the exception, typically the pump format or conversion routine under which the record was processed.

Common Use Cases and Queries

Typical usage centers on post-batch troubleshooting and audit reporting. A common query retrieves all exceptions generated by a recent pump run for review:

• SELECT exception_sequence, exception_level, source_type, source_id, exception_text FROM hr.hr_pump_batch_exceptions ORDER BY exception_sequence DESC;
• Filtering by severity: ... WHERE exception_level = :p_level to isolate blocking errors.
• Correlating back to source data: join source_id to the parent HR table indicated by source_type to retrieve the rejected person or assignment record.
• Trend reporting: grouping counts by format or exception_level to detect recurring conversion or mapping defects across pump runs.

Because the table is documented as standalone, no joins are implied by foreign keys; any correlation to other entities must be constructed manually using SOURCE_ID and SOURCE_TYPE.

Related Objects

No foreign key relationships are documented for HR_PUMP_BATCH_EXCEPTIONS, so related objects are identified functionally rather than through declared constraints:

• HR_PUMP_BATCH_HEADERS and HR_PUMP_BATCH_LINES, which define the pump run and stage its records — exceptions are raised against these staged rows.
• HR_PUMP_BATCH_EXCEPTIONS_PK, the primary key index on EXCEPTION_SEQUENCE.
• PER_ALL_PEOPLE_F and PER_ALL_ASSIGNMENTS_F, the principal targets of Data Pump loads and the most frequent SOURCE_ID referents.
• HR Data Pump concurrent programs and the HR_API error stack routines, which populate EXCEPTION_TEXT at runtime.