Search Results hr_dm_dt_deletes_s




Overview

APPS.HR_DM_LIBRARY is the core utility library within the Oracle E-Business Suite Data Migration (DM) framework for the Human Resources (HR) product family. In EBS 12.1.1 and 12.2.2, the HR Data Migration toolset (the HR_DM_* schema objects) provides a metadata-driven engine for extracting, transforming, uploading, and validating legacy HR data into Oracle HRMS tables. HR_DM_LIBRARY serves as the shared, low-level toolbox that all other Data Migration components call upon to perform reflection, dynamic SQL construction, primary key resolution, foreign key discovery, and duplicate-row detection against the dictionary and the DM repository tables.

The package is compiled and VALID in the APPS schema and is documented with an API classification of OTHER, indicating that it is not a published, supported end-user API but an internal implementation dependency. It references FND_GLOBAL, FND_INSTALLATION, and FND_ORACLE_USERID for runtime context and installation metadata, and it is referenced by fourteen other packages, which confirms its role as a foundational dependency rather than an entry point.

Key Procedures and Functions

The documented interface exposes roughly thirty procedures and functions whose responsibilities cluster into four areas. Reflection and metadata helpers include GET_TABLE_INFO, POPULATE_COLUMNS_LIST, POPULATE_PK_COLUMNS_LIST, POPULATE_HIERARCHY_COLS_LIST, GET_COLS_LIST_WO_PK_COLS, and CHECK_COL_FOR_FK_ON_AOL, which query the data dictionary views ALL_TAB_COLUMNS, ALL_CONSTRAINTS, and ALL_CONS_COLUMNS to build column inventories and identify which columns correspond to foreign keys on AOL (Application Object Library) reference tables. POPULATE_FK_TO_AOL_COLS_INFO complements this by recording FK-to-AOL column relationships.

Resolution and key mapping is handled by GET_RESOLVED_PK, INS_RESOLVE_PKS, and INS_DT_DELETE, which persist surrogate-to-target primary key mappings and delete-tracking records used during re-runnable migration loads. Duplicate detection is performed by CHK_ROW_IN_DT_DELETE, CHK_ROW_IN_DT_DELETE_1_PKCOL, and CHK_ROW_IN_DT_DELETE_2_PKCOL, which verify whether a staged row already exists in the deletion-tracking table, for one- and two-column primary key scenarios respectively.

Text and expression utilities include INDENT, CONV_LIST_TO_TEXT, GET_NVL_ARGUEMENT, GET_FUNC_ASG, and GET_FUNC_ASG_WITH_DEV_KEY, which assist in generating formatted SQL text, converting collections to delimited strings, producing NVL-wrapped argument expressions, and building assignment or function-call fragments either generically or bound to a developer key. Version control is provided by GET_GENERATOR_VERSION and GET_PACKAGE_VERSION, allowing generated code and the library itself to be tracked.

Tables Accessed

HR_DM_LIBRARY reads and writes the Data Migration repository tables that hold the migration definition: HR_DM_MIGRATIONS, HR_DM_HIERARCHIES (and its sequence HR_DM_HIERARCHIES_S), HR_DM_PHASES, HR_DM_PHASE_ITEMS, HR_DM_TABLES, HR_DM_RESOLVE_PKS (and HR_DM_RESOLVE_PKS_S), and HR_DM_DT_DELETES (and HR_DM_DT_DELETES_S). These store migration definitions, phase and item sequencing, hierarchy relationships, resolved primary keys, and delete scope respectively. Dictionary access views AD_DDL, ALL_CONSTRAINTS, and ALL_CONS_COLUMNS, together with USER_OBJECTS and USER_SOURCE, supply schema reflection data. DBMS_SQL and DUAL support dynamic cursor handling, while FND_ORACLE_USERID supplies database user identity information.

Usage Notes

Because HR_DM_LIBRARY has no direct form, report, or concurrent program entry point, it is normally invoked indirectly. The HR Data Migration concurrent programs and their driving packages—HR_DM_GEN_MAIN, HR_DM_UPLOAD, HR_DM_UTILITY, and HR_DM_IMP_BG_WHERE—call the library during migration definition, code generation, and upload execution. Developers extending or troubleshooting the HR Data Migration framework will encounter it through those callers rather than through direct calls. Any custom code that references HR_DM_LIBRARY should be treated as dependent on an internal, unsupported interface subject to change across point releases and patches.