Search Results az_apis_u1

Overview

AZ.AZ_APIS is a seed data table in the Oracle E-Business Suite AZ (Application Framework / iSetup) schema. It stores API definitions used by the iSetup infrastructure to describe the extractable and loadable API objects available to the iSetup generator and loader utilities. Each row represents a single API, characterized by its internal code, display name, method name, path, and a set of capability flags that determine how the iSetup loader interacts with that API.

The table resides in the APPS_TS_SEED tablespace with PCTFREE 10, consistent with its role as a shipped, seeded configuration table. Records are populated during installation and patching, though the presence of standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) indicates that customer-specific or custom API rows can also be defined.

From a modeling perspective, the metadata provides no foreign key relationships, and the heuristic Data Vault classification is standalone. This suggests the object be treated as a reference or lookup hub rather than a transactional entity — a natural candidate for a hub keyed on API_CODE, with descriptive attributes potentially modeled as a satellite, since the descriptive columns change independently across patch cycles.

Key Information Stored

The primary key is AZ_APIS_PK, defined on API_CODE, the internal short code identifying each API. A second unique index, AZ_APIS_U1, is documented on the combination of API_CODE and ZD_EDITION_NAME, which reflects the Editioning feature introduced in EBS 12.2. The ZD_EDITION_NAME column supports edition-based redefinition by isolating rows per edition, meaning the true business key in a 12.2.2 environment is API_CODE plus edition.

The most significant descriptive columns include:

• API_NAME — internal name of the API.
• APPLICATION_SHORT_NAME — the owning application for the API.
• DISPLAY_NAME and API_DESC — user-facing labels and long descriptions.
• METHOD_NAME and PATH — the invocation entry points the loader uses.
• DATA_SOURCE_NAME and REPORT_LAYOUT — sourcing and presentation configuration.
• API_TYPE, TYPE_CODE, and SEQ_NUM — classification and loader ordering.
• ACTIVE and API_STANDALONE_FLAG — enablement and standalone execution status.
• UPDATABLE_FLAG, CHANGE_UPDATABLE_FLAG, ALLOW_SET_TARGETVAL_FLAG, and ALLOW_FILTER_FLAG — capability flags controlling update, transformation, and filter support.
• COMMIT_IF_WARNING_FLAG — controls whether the loader commits when warnings are raised.
• FILTERING_PARAMETERS — a CLOB holding filter definitions, indexed via the SYS_IL LOB index.

Common Use Cases and Queries

Typical reporting focuses on enumerating available APIs and their capabilities for a given application, or auditing which APIs are active against a migration or iSetup run.

Listing active APIs for an application:

• SELECT api_code, api_name, display_name, method_name FROM az.az_apis WHERE application_short_name = :app AND active = 'Y' ORDER BY seq_num;

Identifying update-capable APIs in a specific edition:

• SELECT api_code, display_name, api_type FROM az.az_apis WHERE updatable_flag = 'Y' AND zd_edition_name = :edition;

Reviewing standalone APIs with filter support for diagnostics:

• SELECT api_code, data_source_name, report_layout FROM az.az_apis WHERE api_standalone_flag = 'Y' AND allow_filter_flag = 'Y';

Related Objects

The documented metadata records no formal foreign keys, so related objects are inferred from the iSetup functional model and the naming conventions present in the table. The AZ schema contains companion iSetup tables that consume these API definitions, including the API parameter, mapping, and setup template tables that reference API_CODE as their linking column. The AZ_APIS_U1 index and the SYS_IL LOB index on FILTERING_PARAMETERS are the two documented dependent index structures. Custom APIs registered by customers are also stored here, and downstream loader processes join back to AZ_APIS on API_CODE to resolve method names, paths, and capability flags. Because the classification is standalone, joins to other AZ tables should be validated against the actual FK definitions available in the deployment rather than assumed from the base metadata.