Search Results primary_region_name

Overview

AK_FLOW_PAGES_VL is a multi-language (VL suffix) view owned by the APPS schema in Oracle E-Business Suite. It belongs to the AK — Common Modules (Oracle Application Object Library / application framework) product family, which underpins both the 10SC and, in the context of ETRM, the Oracle E-Business Suite 12.1.1 and 12.2.2 environments. The view presents translated flow page definitions, joining base flow page data with the corresponding translation rows filtered by the session language. A "flow page" represents a configurable page within a workflow-style navigation flow, and the view exposes both the page metadata and the primary region associated with that page.

Because it is a view, AK_FLOW_PAGES_VL does not store data itself; it is a read-only projection intended for reporting, integration, and lookup purposes. Its role is to resolve the surrogate identifiers (application ID and code pairs) held in the underlying tables into human-readable names and descriptions, while simultaneously restricting content to the language of the current user session. This makes it particularly useful for multilingual implementations where flow page labels must be presented in the end user's native language.

Underlying Base Objects

The documented base objects referenced by the view are:

• AK_FLOW_PAGES (accessed via synonym) — the primary transactional table holding flow page definitions.
• AK_FLOW_PAGES_TL (accessed via synonym) — the translation table that stores the language-specific NAME and DESCRIPTION for each flow page.
• AK_REGIONS (accessed via synonym) — the regions table containing the database object name for the primary region.
• AK_REGIONS_TL (accessed via synonym) — the translation table for regions, providing translated region names and descriptions.

The join logic links AK_FLOW_PAGES to AK_FLOW_PAGES_TL on the composite key of FLOW_APPLICATION_ID, FLOW_CODE, PAGE_APPLICATION_ID, and PAGE_CODE, constrained by AFPT.LANGUAGE = USERENV('LANG'). The primary region columns are then resolved through outer joins to AK_REGIONS and AK_REGIONS_TL (also language-filtered), meaning a flow page will still be returned even when no primary region is defined or when the region has no translation in the current language.

Key Columns

• FLOW_APPLICATION_ID / FLOW_CODE — identify the owning flow definition.
• PAGE_APPLICATION_ID / PAGE_CODE — identify the specific page within the flow; together with the flow keys these form the unique page identifier.
• PRIMARY_REGION_APPL_ID / PRIMARY_REGION_CODE — the region configured as the page's primary region.
• PRIMARY_REGION_NAME / PRIMARY_REGION_DESCRIPTION — translated values pulled from AK_REGIONS_TL.
• DATABASE_OBJECT_NAME — the underlying database object (from AK_REGIONS) that backs the region.
• NAME / DESCRIPTION — language-specific page name and description from AK_FLOW_PAGES_TL.
• ATTRIBUTE_CATEGORY through ATTRIBUTE15 — the standard EBS descriptive flexfield (DFF) columns.
• ROW_ID — the ROWID of the underlying AK_FLOW_PAGES row, used for identity.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard who-columns for auditing.

Common Use Cases and Queries

Typical scenarios include building custom reports or LOVs that present flow pages with their translated names, and diagnosing which page maps to which primary region. A ubiquitous pattern is to filter a specific flow:

SELECT name, page_code, primary_region_name
FROM ak_flow_pages_vl
WHERE flow_code = :p_flow_code
ORDER BY name;

To list pages lacking a primary region translation, use the nullable region columns:

SELECT page_code, name
FROM ak_flow_pages_vl
WHERE primary_region_name IS NULL;

Because the view enforces the USERENV('LANG') filter, results always respect the session language, so no additional language predicate is required by the caller.