Search Results ak_criteria




Overview
Explore in AI Chat

Overview

AK_CRITERIA is a table in the AK (Common Modules-AK) product schema of Oracle E-Business Suite, documented as VALID in release 12.1.1 and 12.2.2. Its stated purpose is to store criteria for customization. In practical terms, AK_CRITERIA functions as the configuration persistence layer for the Oracle Application Framework-style customization and personalization engine: it records the conditional logic that determines when a particular customization, region treatment, or attribute-level rule should take effect at runtime. Each row associates an attribute within a region with a customization definition and a sequence position, producing an ordered set of predicate clauses that the customization engine evaluates.

Based on the documented foreign-key and primary-key structure, the table is classified heuristically as a standalone object within a Data Vault model. This classification is a modeling suggestion rather than a documented property: no parent hub or link relationships are asserted in the ETRM metadata, so AK_CRITERIA is best treated as a self-contained table whose composite key alone establishes row uniqueness. It carries both descriptive configuration attributes and standard audit columns.

Key Information Stored

The composite primary key, AK_CRITERIA_PK, spans seven columns: ATTRIBUTE_APPLICATION_ID, CUSTOMIZATION_APPLICATION_ID, REGION_APPLICATION_ID, SEQUENCE_NUMBER, REGION_CODE, CUSTOMIZATION_CODE, and ATTRIBUTE_CODE. This is a business-key primary key rather than a single surrogate identifier. A second unique index, AK_CRITERIA_U1, covers the same columns with the addition of ZD_EDITION_NAME, which is the editioning column introduced by the 12.2 online patching architecture. Collectively, these identifiers establish the identity of a criterion: which region, which customization, which attribute, and the ordering position within that grouping.

  • CUSTOMIZATION_CODE / CUSTOMIZATION_APPLICATION_ID — identify the customization definition to which the criterion belongs.
  • REGION_CODE / REGION_APPLICATION_ID — identify the owning region where the criterion is evaluated.
  • ATTRIBUTE_CODE / ATTRIBUTE_APPLICATION_ID — identify the specific attribute the criterion targets.
  • SEQUENCE_NUMBER — orders criteria within a customization/region/attribute group, controlling evaluation precedence.
  • OPERATION — the comparison or logical operator applied by the criterion.
  • VALUE_VARCHAR2, VALUE_NUMBER, VALUE_DATE — the typed operand values compared against the attribute, one of which is populated according to the operation's data type.
  • START_DATE_ACTIVE / END_DATE_ACTIVE — effective-dating bounds that govern when the criterion is active.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS audit trail.

Common Use Cases and Queries

Typical scenarios include auditing the conditions that drive a customization, diagnosing why a personalization is not firing, and reporting on the effective-dated lifecycle of customization logic. A baseline query joins criteria to their customization identity as follows:

SELECT region_code, customization_code, attribute_code,
       sequence_number, operation,
       value_varchar2, value_number, value_date
FROM   ak.ak_criteria
WHERE  customization_code = :p_customization
ORDER  BY region_code, attribute_code, sequence_number;

To restrict results to criteria active on a given date, filter on START_DATE_ACTIVE and END_DATE_ACTIVE. For 12.2 environments, all queries must be aware of ZD_EDITION_NAME, since the editioning column participates in the unique index and edition-scoped visibility. Reporting use cases include generating a matrix of regions against active customizations and identifying overlapping or conflicting criteria defined for the same attribute.

Related Objects

AK_CRITERIA is documented as standalone, meaning no foreign-key relationships are asserted in the metadata. The following objects are the most significant practical dependencies and join partners:

  • AK_REGIONS — joins on REGION_CODE and REGION_APPLICATION_ID to resolve the region definition.
  • AK_ATTRIBUTES — joins on ATTRIBUTE_CODE and ATTRIBUTE_APPLICATION_ID to resolve the target attribute.
  • AK_CUSTOMIZATIONS (AK_CUSTOMIZATION_DEFINITIONS) — joins on CUSTOMIZATION_CODE and CUSTOMIZATION_APPLICATION_ID for the customization header.

In addition, the AK customization engine's public programmatic interfaces and the runtime personalization evaluator read this table directly; direct DML is not recommended, and updates should be performed through supported customization administration. Because all assertions beyond the documented columns and index structure are inferred, DBAs should verify relationships against the AK schema in the target instance before relying on cross-table joins.