Search Results hz_adapters




Overview
Explore in AI Chat

Overview

HZ_ADAPTERS is a Receivables (AR) module table that stores configuration metadata for adapters used to provide data integration services within the Oracle E-Business Suite. In practice, this table acts as a registry of integration endpoints: each row defines a named adapter, the source system or content provider it connects to, the transport properties required to invoke it (host address, credentials, invocation method, and message format), and the operational parameters that govern batch handling during synchronization. Because HZ_ADAPTERS is owned by the AR schema and carries the standard Oracle EBS audit and concurrency columns, it participates in the same Multi-Org and editioning framework as other EBS 12.1.1 and 12.2.2 tables, though its operational purpose is narrower — it supports the plumbing behind data exchange rather than transactional accounting.

From a Data Vault modeling perspective, the mined FK classification marks HZ_ADAPTERS as standalone. This heuristic suggests the table is best treated as a business hub or reference entity in its own right, rather than as a link or satellite, since no foreign keys originate from it and only one downstream table (HZ_ADAPTER_USERS) references it. Analysts building dimensional or Data Vault models should therefore consider HZ_ADAPTERS a candidate hub keyed on ADAPTER_ID, with its descriptive attributes (transport, batch, and content-source details) belonging to a companion satellite.

Key Information Stored

The table contains 20 documented columns. The most operationally significant are:

ADAPTER_ID is the pure surrogate key; ADAPTER_CONTENT_SOURCE combined with ZD_EDITION_NAME is the closest thing to a documented natural or business key, as reflected by unique index HZ_ADAPTERS_U2. HZ_ADAPTERS_U1 is essentially a unique index on the primary key plus the edition name.

Common Use Cases and Queries

Typical scenarios include verifying which adapters are enabled before a data load, auditing credentials and endpoint configuration, and tuning batch sizes for performance. A common query pattern lists active adapters with their transport details:

  • SELECT ADAPTER_ID, ADAPTER_CONTENT_SOURCE, ENABLED_FLAG, SYNCHRONOUS_FLAG, INVOKE_METHOD_CODE, HOST_ADDRESS FROM HZ_ADAPTERS WHERE ENABLED_FLAG = 'Y';
  • Locate a specific adapter by natural key: SELECT * FROM HZ_ADAPTERS WHERE ADAPTER_CONTENT_SOURCE = :source;
  • Join to assigned users: SELECT a.ADAPTER_ID, a.ADAPTER_CONTENT_SOURCE, u.* FROM HZ_ADAPTERS a JOIN HZ_ADAPTER_USERS u ON u.ADAPTER_ID = a.ADAPTER_ID;
  • Inspect batch configuration: SELECT ADAPTER_ID, DEFAULT_BATCH_SIZE, MAXIMUM_BATCH_SIZE, DEFAULT_REPLACE_STATUS_LEVEL FROM HZ_ADAPTERS;
  • Review recent changes for audit: SELECT ADAPTER_ID, LAST_UPDATE_DATE, LAST_UPDATED_BY FROM HZ_ADAPTERS WHERE LAST_UPDATE_DATE > :since;

Reporting use cases include integration inventory reports, periodic credential reviews, and troubleshooting failed synchronizations by verifying endpoint and format settings.

Related Objects

  • HZ_ADAPTER_USERS — the only downstream table in the mined relationship data, joining on HZ_ADAPTER_USERS.ADAPTER_ID → HZ_ADAPTERS.ADAPTER_ID; it links adapters to the users authorized to use them.
  • HZ_ADAPTERS_PK — the primary key constraint/index on ADAPTER_ID, used for direct lookups.
  • HZ_ADAPTERS_U1 — unique index on ADAPTER_ID and ZD_EDITION_NAME.
  • HZ_ADAPTERS_U2 — unique index on ADAPTER_CONTENT_SOURCE and ZD_EDITION_NAME, the business-key candidate.

Because the table is standalone with limited documented FKs, integration developers should also expect references from TCA/party integration packages and Oracle Trading Community Architecture APIs that consume adapter definitions, though only HZ_ADAPTER_USERS is explicitly documented as a referencing object in the available metadata. Practitioners should query the data dictionary (USER_CONSTRAINTS, USER_DEPENDENCIES) in their specific instance to confirm any additional dependencies introduced by customizations.