Search Results icx_regions




Overview
Explore in AI Chat

Overview

ICX_REGIONS is a configuration table in the ICX schema (Oracle iProcurement / Self-Service Web Applications) that defines the region-level layout information for Self-Service Web Application pages in Oracle E-Business Suite 12.1.1 and 12.2.2. A "region" in this context is a browser-rendered container within a page that holds portlets, navigation widgets, or nested sub-regions. Each row describes the geometry and rendering behavior of one such region, including how it splits, how portlets flow inside it, and how it is aligned. The table thus functions as the persistence layer for the page layout metadata consumed by the ICX page-rendering engine, rather than as a transactional or business-entity table.

The ETRM metadata records the object as VALID with Owner/Schema ICX and 15 documented columns in the 12.2.2 physical schema. Its primary key is ICX_REGIONS_PK1 on REGION_ID. The mined Data Vault classification is standalone; from a modeling perspective this suggests treating ICX_REGIONS as neither a hub nor a link in a Data Vault build, but rather as a reference/configuration table that can be replicated directly or attached as a descriptive lookup, since no foreign-key relationships were identified in the mined structure.

Key Information Stored

The most significant columns, as documented in the ETRM extract, are:

  • REGION_ID — surrogate primary key (ICX_REGIONS_PK1); uniquely identifies each region row.
  • PARENT_REGION_ID — self-referencing pointer establishing the region hierarchy (a region may contain child regions).
  • SPLIT_MODE — controls how the region is divided for layout purposes.
  • PORTLET_ALIGNMENT — alignment setting for portlets rendered inside the region.
  • PORTLET_FLOW — directional flow governing how portlets are arranged.
  • WIDTH and HEIGHT — dimensional attributes for the region.
  • WIDTH_RESTRICT — flag or value restricting region width behavior.
  • BORDER — border rendering attribute.
  • NAVWIDGET_ID — identifier linking the region to a navigation widget.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns (WHO columns) recording creation and modification metadata.

The only documented unique identifier is the primary key index ICX_REGIONS_PK1 on REGION_ID; no separate business-key unique index is recorded in the supplied metadata.

Common Use Cases and Queries

Typical scenarios involve diagnosing or customizing Self-Service page layout, auditing portlet placement, and tracing navigation widget assignment. Common query patterns include retrieving entire region trees and inspecting layout attributes for problematic pages:

  • List all regions with parent context: SELECT REGION_ID, PARENT_REGION_ID, SPLIT_MODE, PORTLET_FLOW FROM ICX_REGIONS ORDER BY PARENT_REGION_ID, REGION_ID;
  • Find top-level regions: SELECT REGION_ID FROM ICX_REGIONS WHERE PARENT_REGION_ID IS NULL;
  • Locate regions tied to navigation widgets: SELECT REGION_ID, NAVWIDGET_ID FROM ICX_REGIONS WHERE NAVWIDGET_ID IS NOT NULL;
  • Audit recent changes: SELECT REGION_ID, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM ICX_REGIONS WHERE LAST_UPDATE_DATE > SYSDATE-30;

Reporting use cases include documenting page composition, validating that layout changes were captured with correct audit stamps, and supporting upgrade or clone comparisons between 12.1.1 and 12.2.2 environments.

Related Objects

The ETRM relationship data classifies ICX_REGIONS as standalone, with the only documented key relationship being its own primary key (ICX_REGIONS_PK1). Based on its role in defining page regions, the significant related objects are:

  • ICX_REGIONS (self-join) — via PARENT_REGION_ID = REGION_ID to traverse the region hierarchy.
  • Portlet-region association tables in the ICX schema — typically joined on REGION_ID, mapping portlets into regions.
  • ICX_PAGES / page definition tables — associate regions to their owning Self-Service page.
  • Navigation widget definitions — referenced through NAVWIDGET_ID.
  • FND audit/user views — resolved through LAST_UPDATED_BY and CREATED_BY.

Because the mined metadata records no FK dependencies, these associations should be validated against the actual 12.1.1 or 12.2.2 dictionary before being relied upon in production queries.