Search Results api_code




Overview

AZ_APIS is a table in the AZ (Application Implementation) product module of Oracle E-Business Suite, owned by the AZ schema and documented as VALID. Its description is "API definitions," indicating that it stores the metadata registry that describes the programmable interfaces exposed through Oracle Application Implementation and its associated reporting and integration framework. In practice, each row defines an API that the framework can invoke, along with the routing, behavioral flags, layout information, and data-source bindings required to execute it. This makes AZ_APIS a control/metadata table rather than a transactional fact table: it drives runtime behavior for downstream services that read API definitions before dispatching calls, rendering reports, or applying filters.

The documented heuristic Data Vault classification, mined from the foreign-key structure, is standalone. This suggests a modeling approach in which AZ_APIS is treated as its own hub-like entity keyed by API_CODE, with no mined FK dependencies anchoring it to other hubs or links. Analysts building a vault model should therefore treat it as a self-contained reference or configuration hub rather than a satellite attached to another business key.

Key Information Stored

AZ_APIS is documented with 31 columns in the ETRM 12.2.2 physical schema. The most significant include:

Note the distinction between the surrogate AZ_APIS_PK (API_CODE alone) and the business-key candidate AZ_APIS_U1 (API_CODE, ZD_EDITION_NAME), which reflects EBS editioning semantics.

Common Use Cases and Queries

Typical scenarios include enumerating active APIs for an application, validating that a requested API_CODE exists before invocation, and joining API metadata to report layouts and filtering definitions. Sample patterns:

  • Lookup by key: SELECT API_NAME, API_TYPE, METHOD_NAME, ACTIVE FROM AZ.AZ_APIS WHERE API_CODE = :p_api_code;
  • Listing active APIs per application: SELECT API_CODE, API_NAME FROM AZ.AZ_APIS WHERE APPLICATION_SHORT_NAME = :app AND ACTIVE = 'Y' ORDER BY SEQ_NUM;
  • Edition-aware lookup honoring the unique index: SELECT * FROM AZ.AZ_APIS WHERE API_CODE = :p AND ZD_EDITION_NAME = :ed;
  • Change auditing via the standard columns: SELECT API_CODE, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM AZ.AZ_APIS WHERE LAST_UPDATE_DATE >= :since;

Reporting use cases center on configuration inventories, governance of exposed interfaces, and reconciliation of API definitions against deployed integrations.

Related Objects

The documented relationship data classifies AZ_APIS as standalone, with no mined foreign keys pointing outward. Consequently, related objects are best identified by shared business columns rather than enforced constraints:

  • AZ_APIS_PK — the primary-key constraint on API_CODE.
  • AZ_APIS_U1 — the unique index on (API_CODE, ZD_EDITION_NAME), the edition-aware business key.
  • SYS_IL0000192692C00021$$ — an index associated with the most recent documented column, tracked in the ETRM inventory.
  • Application Implementation report-layout and filtering definitions referenced through REPORT_LAYOUT, FILTERING_PARAMETERS, and DATA_SOURCE_NAME, which link this registry to its runtime consumers.
  • EBS application identity tables joined via APPLICATION_SHORT_NAME for cross-module reporting.