Results for “az_api_preference_sources_b”

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

Overview

AZ_API_PREFERENCE_SOURCES_VL is a read-only bilingual (VL, or "view language") database view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the FND — Application Object Library product family and, in ETRM terms, exposes the translatable master data that defines the "preference sources" consumed by the AZ (Application Object Library) preference and personalization framework. In practical terms, the view answers a single, recurring question for administrators, implementers, and integrators: which data sources may be declared as preferences for a given preference code, and what is the user-facing display name for each source in the current session language?

Because it is a VL view, it performs runtime language resolution rather than storing a language column for the consumer to filter. The view joins a base (_B) table that holds language-independent attributes to a translation (_TL) table that holds the localized display name, and restricts the translation row to the language returned by USERENV('LANG'). The result is a single row per preference/source combination, rendered in the language of the connected session. This makes the view suitable for Forms LOVs, concurrent reporting, OAF pages, and custom integrations that must respect the NLS language setting without embedding language logic themselves.

Underlying Base Objects

The view is defined over two documented base objects, both reached through APPS synonyms:

• AZ_API_PREFERENCE_SOURCES_B — the base table holding the language-independent definition of each preference source: the preference code, the data source, the referenced data source, and the standard WHO audit columns.
• AZ_API_PREFERENCE_SOURCES_TL — the translation table holding the localized display name, keyed by preference code, data source, and language.

The join condition is a composite equijoin on both PREFERENCE_CODE and DATA_SOURCE, with the additional predicate T.LANGUAGE = USERENV('LANG'). The composite key is significant: a preference code may legitimately have more than one valid data source, so PREFERENCE_CODE alone is not sufficient to identify a row. Referential integrity is therefore enforced at the pair level, and any custom query or extract must join on both columns to avoid row multiplication.

Key Columns

• PREFERENCE_CODE — identifies the preference to which the source belongs; the functional grouping key for the source list.
• DATA_SOURCE — the source value itself; combined with PREFERENCE_CODE it uniquely identifies a source definition.
• REF_DATA_SOURCE — a reference or related data source, typically used to indicate a dependent, alternate, or lookup source associated with the primary source.
• DISPLAY_NAME — the translatable label shown to users; sourced from the TL table and resolved to the session language.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE — the standard audit columns inherited from the _B table, used for change tracking and data lineage.

Common Use Cases and Queries

Typical uses include validating that a data source is registered for a preference before building configuration or personalization data, driving selection lists in custom forms and OAF regions, and extracting preference source metadata for migration between environments or for documentation. The following query lists all sources for a single preference code in the session language:

SELECT preference_code, data_source, ref_data_source, display_name
FROM apps.az_api_preference_sources_vl
WHERE preference_code = :p_preference_code
ORDER BY display_name;

A second pattern enumerates every defined preference and its sources, useful for auditing configuration carry-over across instances:

SELECT preference_code, data_source, ref_data_source, display_name
FROM apps.az_api_preference_sources_vl
ORDER BY preference_code, data_source;

To verify that a specific source is properly registered and translated before deploying a dependent object, filter on the composite key:

SELECT display_name
FROM apps.az_api_preference_sources_vl
WHERE preference_code = :p_code AND data_source = :p_source;

Because translation rows are keyed by language, a missing row in the target language yields no result rather than an untranslated fallback. Validation logic should therefore treat an empty result set as "not registered or not translated," and administrators should confirm that TL rows exist for every deployed language. The view carries no DML privileges; preference sources are maintained through the supported application setup path against the underlying tables.