Results for “mapping_name”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_DM_SECURITYMAPPINGS_VL is a translation-enabled (VL, or "view language") database view in the Oracle Application Object Library (product code FND). It exposes security mapping definitions used by the Oracle E-Business Suite data model and information-discovery security framework. In EBS 12.1.1 and 12.2.2 this view presents the header portion of the security-mapping configuration, combining the base language-independent definition of each mapping with the language-specific display text that is appropriate to the session language. It is the view most commonly referenced when a user or developer searches on the identifier mapping_name, because MAPPING_NAME is carried directly on this view alongside the translated DISPLAY_NAME and DESCRIPTION columns.

The view functions as a reporting and integration surface rather than as a transactional entry point. It allows concurrent programs, reports, Oracle Forms blocks, and external integrations to retrieve security mapping metadata in user-readable form without having to manually join the base table to its translation table and filter by the session language.

Underlying Base Objects

The view is defined over two documented base objects:

• FND_DM_SECURITYMAPPINGS — the base (language-independent) table holding each mapping's surrogate key, name, target entity, and template type, together with standard WHO audit columns.
• FND_DM_SECURITYMAPPINGS_TL — the translation table holding the language-specific DISPLAY_NAME and DESCRIPTION for each mapping.

The two tables are joined on MAPPING_ID (the primary/foreign key relationship), and the translation row is further restricted with TL.LANGUAGE = USERENV('LANG') so that only the text for the current session language is returned. The _VL suffix confirms this session-language filtering behavior. The view text also selects B.ROWID as ROW_ID, which supports updatable-view and row-identification use cases in Oracle Forms.

Key Columns

• ROW_ID — the ROWID of the underlying base-table row, exposed for row-level identification.
• MAPPING_ID — the internal surrogate key uniquely identifying each security mapping; the join key between the base and translation tables.
• MAPPING_NAME — the developer-facing, language-independent name of the mapping. This is the object of the "mapping_name" search and is the stable identifier to use in code and queries.
• ENTITY_NAME — identifies the entity (data object) to which the security mapping applies.
• TEMPLATE_TYPE — the template or category that classifies the mapping.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard EBS WHO audit columns recording creation and last modification.
• DISPLAY_NAME — the translated, user-facing label for the mapping, resolved from the _TL table for the session language.
• DESCRIPTION — the translated descriptive text for the mapping.

Common Use Cases and Queries

Typical scenarios include resolving a mapping key to its display name for reporting, listing all mappings for a given entity, and validating the set of security templates configured in the instance. The following query returns the core mapping metadata in session language form:

SELECT mapping_id, mapping_name, entity_name, template_type, display_name, description FROM fnd_dm_securitymappings_vl ORDER BY mapping_name;

To look up a specific mapping by its name:

SELECT mapping_id, mapping_name, entity_name, display_name, description FROM fnd_dm_securitymappings_vl WHERE mapping_name = :mapping_name;

To list the mappings associated with a particular entity:

SELECT mapping_name, template_type, display_name FROM fnd_dm_securitymappings_vl WHERE entity_name = :entity_name ORDER BY mapping_name;

Because the view already applies the USERENV('LANG') predicate, callers should not add their own language restriction; doing so can return no rows when the requested language differs from the session language. The ETRM record notes that this view is not implemented in every database and documents no referenced base objects beyond the two tables above, so presence and column availability should be confirmed against the target instance before reliance.