Search Results ending_process_sequence

Overview

HR_DM_MIGRATION_RANGES_V is an APPS-owned database view within the PER (Human Resources) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. It is documented in ETRM as a "View to support DM UI - hr_dm_migration_ranges." The "DM" designation refers to Data Migration, the framework used by Oracle HRMS to migrate and transform legacy or external HR data into EBS through defined phase items, batches, and processing ranges. This view exists primarily to serve the Data Migration user interface layer, presenting migration range records alongside their parent phase-item and batch context in a single flattened result set.

Because the view is defined in the APPS schema and joins two migration control tables, it functions as both a reporting convenience and an integration surface. Administrators, technical consultants, and custom monitoring utilities can query it to determine which migration ranges are pending, in progress, or complete, and to which table and batch each range belongs. The user search term "phase_item_id" reflects the view's central join key, which ties every migration range back to its governing phase item.

Underlying Base Objects

The documented metadata lists three referenced objects, all resolved through APPS synonyms or package references:

• HR_DM_MIGRATION_RANGES (SYNONYM) — the primary driving table, aliased H1, which stores the individual processing ranges, their sequence boundaries, status, timing, and audit columns.
• HR_DM_PHASE_ITEMS (SYNONYM) — aliased H2, which supplies the parent batch identifier and the target table name associated with each phase item.
• HR_GENERAL (PACKAGE) — a PL/SQL package invoked in the SELECT list through HR_GENERAL.DECODE_LOOKUP, used to translate the stored status code into a displayable meaning.

The view text joins H1 and H2 with an inner join on PHASE_ITEM_ID: WHERE H1.PHASE_ITEM_ID = H2.PHASE_ITEM_ID. Consequently, only migration ranges that have a valid matching phase item are returned; orphaned ranges are excluded.

Key Columns

The view exposes sixteen columns. The most significant are:

• RANGE_ID — unique identifier of the migration range record.
• PHASE_ITEM_ID — the join key linking a range to its phase item and, transitively, to its batch and target table. This is the column most frequently used in filtering and joins.
• STARTING_PROCESS_SEQUENCE / ENDING_PROCESS_SEQUENCE — the lower and upper bounds of the process sequence handled by this range, allowing a migration to be partitioned into parallel or restartable units.
• STATUS — internal lookup code for the range state; STATUS_MEANING is the decoded, human-readable equivalent produced via HR_GENERAL.DECODE_LOOKUP against the HR_DM_STATUS lookup type.
• BATCH_ID and TABLE_NAME — sourced from HR_DM_PHASE_ITEMS, identifying the batch and the destination table being migrated.
• START_TIME / END_TIME / ROW_COUNT — execution telemetry showing when processing began and ended and how many rows were handled, useful for throughput and performance analysis.
• Standard audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE.

Common Use Cases and Queries

Typical usage includes monitoring an in-flight data migration, identifying stalled or failed ranges, and reconciling processed row counts against source expectations. A common query lists all ranges for a given phase item with decoded status and elapsed timing:

• SELECT r.range_id, r.phase_item_id, r.starting_process_sequence, r.ending_process_sequence, r.status_meaning, r.table_name, r.row_count FROM apps.hr_dm_migration_ranges_v r WHERE r.phase_item_id = :p_phase_item_id ORDER BY r.starting_process_sequence;

A second pattern groups by batch and status to summarize migration progress:

• SELECT batch_id, table_name, status_meaning, COUNT(*) range_count, SUM(row_count) total_rows FROM apps.hr_dm_migration_ranges_v GROUP BY batch_id, table_name, status_meaning ORDER BY batch_id;

Because the view performs the lookup decode through the HR_GENERAL package, consumers should avoid unnecessary full scans and should filter on indexed keys such as PHASE_ITEM_ID or RANGE_ID where possible. As with all APPS views, read access and any tuning are governed by the appropriate EBS security and support policies.