Search Results module_package
Overview
The HR_DM_EXP_API_MODULES_V view is an Oracle E-Business Suite database object owned by the APPS schema and registered under the PER (Human Resources) product family. Its documented purpose is to export information sourced from the hr_api_modules data set. The view forms part of the HR Data Migration (DM) export framework, a set of database objects used to stage and extract Human Resources setup and transactional data between environments or during data migration and upgrade activities.
In Oracle EBS 12.1.1 and 12.2.2, this view presents a denormalized, flat projection of the HR_API_MODULES entity. Rather than exposing the underlying business columns directly, the view maps the generic PVAL001 through PVAL011 staging columns held in HR_DM_EXP_IMPS into named, business-meaningful columns. This transformation allows downstream extraction routines, external integrators, or migration scripts to consume HR API module definitions without needing to interpret the internal staging column naming convention. The view reports a status of VALID and is documented as a reporting and integration aid rather than a transactional object.
Underlying Base Objects
The view is defined over a single documented base object: HR_DM_EXP_IMPS, which is referenced as a synonym. All data returned by HR_DM_EXP_API_MODULES_V originates from this staging table. The view applies a restrictive filter, selecting only those rows where TABLE_NAME equals 'HR_API_MODULES'. This predicate isolates the HR API module records from the broader set of entities that HR_DM_EXP_IMPS may otherwise hold.
Because HR_DM_EXP_IMPS is a staging or export/import repository keyed by EXP_IMP_ID, the view effectively acts as an entity-specific slice of the shared staging infrastructure. The relationship is one of filtering and column aliasing: no join to an operational HR table is performed within the view itself. The semantic origin of the data is the HR_API_MODULES entity, but the physical storage vehicle is the generic staging table. This design means data currency depends entirely on the population state of HR_DM_EXP_IMPS; the view does not reach into live HR_API_MODULES records directly.
Key Columns
- EXP_IMP_ID — The export/import identifier linking the row to its parent staging batch in HR_DM_EXP_IMPS.
- TABLE_NAME — Always 'HR_API_MODULES' for rows returned by this view, confirming the entity filter.
- API_MODULE_ID — Maps to PVAL001; the identifier of the HR API module.
- API_MODULE_TYPE — Maps to PVAL002; the classification of the API module.
- MODULE_NAME — Maps to PVAL003; the descriptive name of the module.
- DATA_WITHIN_BUSINESS_GROUP — Maps to PVAL004; indicates the business group scoping of the module data.
- LEGISLATION_CODE — Maps to PVAL005; the legislation under which the module applies.
- MODULE_PACKAGE — Maps to PVAL006; the PL/SQL package associated with the module.
- LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Audit columns mapped from PVAL007 through PVAL009.
- CREATED_BY, CREATION_DATE — Audit columns mapped from PVAL010 and PVAL011.
Common Use Cases and Queries
Typical usage centers on data migration and environment comparison. A migration specialist may extract the roster of HR API modules from a source instance and compare it against a target. The following query lists all exported API modules for the current staging data:
SELECT api_module_id, api_module_type, module_name, legislation_code, module_package FROM apps.hr_dm_exp_api_modules_v ORDER BY module_name;
To inspect the business group scoping or legislation-specific modules, a filter can be applied:
SELECT module_name, legislation_code FROM apps.hr_dm_exp_api_modules_v WHERE data_within_business_group = 'Y';
A batch-oriented audit is equally common, joining back on EXP_IMP_ID to correlate modules with their staging run:
SELECT e.exp_imp_id, v.module_name, v.creation_date FROM apps.hr_dm_exp_api_modules_v v JOIN apps.hr_dm_exp_imps e ON v.exp_imp_id = e.exp_imp_id;
Because the view is read-only and derived from staging data, no DML should be issued against it; consumers treat it strictly as an extraction surface.
-
View: HR_DM_EXP_API_MODULES_V
12.2.2
owner:APPS, object_type:VIEW, fnd_design_data:PER.HR_DM_EXP_API_MODULES_V, object_name:HR_DM_EXP_API_MODULES_V, status:VALID, product: PER - Human Resources , description: View to export hr_api_modules information , implementation_dba_data: APPS.HR_DM_EXP_API_MODULES_V ,
-
View: HR_DM_EXP_API_MODULES_V
12.1.1
owner:APPS, object_type:VIEW, fnd_design_data:PER.HR_DM_EXP_API_MODULES_V, object_name:HR_DM_EXP_API_MODULES_V, status:VALID, product: PER - Human Resources , description: View to export hr_api_modules information , implementation_dba_data: APPS.HR_DM_EXP_API_MODULES_V ,
-
Table: HR_PUMP_MAPPING_PACKAGES
12.1.1
owner:HR, object_type:TABLE, fnd_design_data:PER.HR_PUMP_MAPPING_PACKAGES, object_name:HR_PUMP_MAPPING_PACKAGES, status:VALID, product: PER - Human Resources , description: Lists PL/SQL packages that contain the parameter mapping functions used by data pump generated code. If module_package and module_name are both null then the mapping functions may be used by all APIs. , implementation_dba_data: HR.HR_PUMP_MAPPING_PACKAGES ,
-
Table: HR_PUMP_MAPPING_PACKAGES
12.2.2
owner:HR, object_type:TABLE, fnd_design_data:PER.HR_PUMP_MAPPING_PACKAGES, object_name:HR_PUMP_MAPPING_PACKAGES, status:VALID, product: PER - Human Resources , description: Lists PL/SQL packages that contain the parameter mapping functions used by data pump generated code. If module_package and module_name are both null then the mapping functions may be used by all APIs. , implementation_dba_data: HR.HR_PUMP_MAPPING_PACKAGES ,