Search Results hrdpp_create_in_location




Overview
Explore in AI Chat

Overview

HRDPP_CREATE_IN_LOCATION is an Oracle EBS Application Object Library package body owned by the APPS schema, classified under the HR Data Pump framework. Its business purpose is to load (create) "IN Location" records — internal locations within the HR location hierarchy — into the Oracle HRMS data model by way of the Data Pump batch-processing infrastructure rather than through direct DML. The package acts as a specialized loader that consumes staged rows from Data Pump batch tables, invokes the canonical HR location business API (HR_IN_LOCATION_API) to perform validation and insertion, and captures any resulting errors or warnings back into the pump tables for downstream reconciliation and reporting.

The object is reported as VALID in the ETRM repository for the 12.1.1 / 12.2.2 releases. It is not referenced by any other database object, indicating that it functions as a top-level entry point — most likely invoked by a Data Pump concurrent program or by the generic Data Pump driver — rather than being called from other PL/SQL units. Its dependency list confirms tight integration with the broader HR Data Pump and HR API stacks: HR_API, HR_DATA_PUMP, HR_IN_LOCATION_API, HR_MULTI_MESSAGE, HR_PUMP_GET, HR_PUMP_UTILS, HR_UTILITY, and PER_IN_DATA_PUMP, in addition to the SYS STANDARD package.

Key Procedures and Functions

The documented package exposes seven procedures/functions. Because the ETRM metadata supplies only their names, the descriptions below reflect their evident role within the Data Pump loader pattern and should not be read as authoritative signatures.

  • CALL — The primary public entry point. It is expected to orchestrate the load of a single location row or a batch by delegating to the internal driver and the HR_IN_LOCATION_API.
  • DC — A terse internal procedure, conventionally denoting "Data Check" or a default/create handler used within the loader's dispatch logic.
  • D — An internal handler, likely the "Delete" or "default" action branch of the multi-action loader.
  • N — An internal handler, likely the "New"/insert action branch.
  • DD — An internal handler, likely a "Duplicate/Data Default" variant used when processing repeat or derived rows.
  • ND — An internal handler, combining the New and Default semantics for rows requiring both insertion and defaulting.
  • INSERT_BATCH_LINES — Writes processed rows and their outcomes into the HR_PUMP_BATCH_LINES staging table, ensuring that the Data Pump batch reflects the result of each attempted creation.

The concise naming (D, N, DC, DD, ND) is characteristic of the Data Pump loader convention, where single-letter codes represent the CRUD-style action to be applied to each incoming row.

Tables Accessed

The package reads and writes the following HR Data Pump staging tables, which are referenced through APPS synonyms:

  • HR_PUMP_BATCH_LINES and HR_PUMP_BATCH_LINES_S — the primary staging tables holding the inbound location rows and their sequence/status data. The loader reads pending lines and updates them with processing results.
  • HR_PUMP_BATCH_EXCEPTIONS — stores validation and API errors raised during row processing, enabling error reporting and correction.
  • HR_PUMP_BATCH_LINE_USER_KEYS and HR_PUMP_BATCH_LINE_USER_KEYS_S — hold the user-defined key values that identify each location uniquely, supporting duplicate detection and key-based lookups.

Writes to the actual HR location tables occur indirectly through HR_IN_LOCATION_API, not through direct DML from this package, which preserves the integrity of HRMS business rules and row-level security.

Usage Notes

HRDPP_CREATE_IN_LOCATION is typically invoked as part of the Oracle HRMS Data Pump load process — for example, when migrating or mass-loading location data. It is not called by any other database object, so invocation occurs through the Data Pump concurrent program or the generic Data Pump driver, which passes a batch identifier and processes the staged rows. Custom code should not call the internal single-letter procedures directly; the supported integration point is the Data Pump framework itself. Because the package depends on HR_IN_LOCATION_API, all HRMS validation, security, and business rules applicable to location creation remain in force.