Search Results sys_il0000323547c00013

Overview

AR.HZ_ADAPTER_LOGS is a TCA (Trading Community Architecture) interface table owned by the AR schema. It records the requests and responses exchanged between Oracle E-Business Suite and external data integration service providers, such as those used by Dun & Bradstreet, DQM, or other third-party data quality vendors. Each row captures a single adapter transaction, identifying which functional module originated the request, the HTTP status returned by the remote service, and the full inbound and outbound XML payloads.

Because the table stores adapter transactions keyed to a surrogate identifier with no outgoing foreign keys to business entities other than the concurrent request, it is best characterized as satellite-leaning in a Data Vault model. It does not resolve many-to-many business relationships, nor does it serve as a reference hub. Instead, it provides descriptive and diagnostic context around integration events. The table resides in the APPS_TS_INTERFACE tablespace with PCT FREE 10, which is consistent with its role as a high-volume interface log.

Key Information Stored

The surrogate primary key is ADAPTER_LOG_ID, a NUMBER(15) that uniquely identifies each adapter log entry. The unique index HZ_ADAPTER_LOGS_U1 enforces uniqueness on ADAPTER_LOG_ID; it is the only documented business-key candidate, alongside two system LOB indexes (SYS_IL0000323547C00012$$ and SYS_IL0000323547C00013$$) that support the CLOB columns.

• ADAPTER_LOG_ID – Surrogate primary key and the column used by HZ_ADAPTER_LOGS_U1.
• CREATED_BY_MODULE – TCA who column identifying the module (for example, a TCA entity or service) that requested the integration service.
• CREATED_BY_MODULE_ID – The identifier of the specific record within CREATED_BY_MODULE for which service was requested.
• HTTP_STATUS_CODE – The HTTP status code returned by the remote provider, used for success/failure diagnostics.
• REQUEST_ID – Concurrent Program who column linking the row to the concurrent request that last updated it (references FND_CONCURRENT_REQUESTS).
• OBJECT_VERSION_NUMBER – Locking version number used for optimistic concurrency control.
• IN_DOC – CLOB containing the inbound XML document returned by the integration provider.
• OUT_DOC – CLOB containing the outbound XML document sent to the integration provider.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN – Standard Who columns recording audit and user context.

Common Use Cases and Queries

The most frequent scenario is troubleshooting failed data integration calls. A support analyst inspects HTTP_STATUS_CODE, then opens IN_DOC and OUT_DOC to compare the request payload against the provider response. Because the CLOBs are large, extraction should target specific log IDs.

A typical query to isolate failures for a given module follows:

• SELECT ADAPTER_LOG_ID, CREATED_BY_MODULE, CREATED_BY_MODULE_ID, HTTP_STATUS_CODE FROM AR.HZ_ADAPTER_LOGS WHERE HTTP_STATUS_CODE <> '200' ORDER BY CREATION_DATE DESC;
• SELECT REQUEST_ID, ADAPTER_LOG_ID, CREATION_DATE FROM AR.HZ_ADAPTER_LOGS WHERE REQUEST_ID = :request_id;
• SELECT CREATED_BY_MODULE, COUNT(*) FROM AR.HZ_ADAPTER_LOGS GROUP BY CREATED_BY_MODULE;

Reporting use cases include monitoring integration throughput by module, auditing provider response codes over time, and providing evidence of what data was transmitted to an external vendor for compliance purposes. Because the table can grow rapidly, purging strategies keyed on CREATION_DATE are common.

Related Objects

• FND_CONCURRENT_REQUESTS – Referenced via REQUEST_ID; joins AR.HZ_ADAPTER_LOGS.REQUEST_ID to the concurrent request identifier.
• AR.HZ_ADAPTER_LOGS# – The underlying object created for the editioning view pattern in 12.2.
• TCA integration/public API packages such as those in the HZ_% namespace consume the log to record adapter activity.
• Other HZ_* tables referenced by CREATED_BY_MODULE_ID – Depending on the requesting module, the ID resolves to specific TCA entities.
• FND_LOG and FND_LOG_MESSAGES – Complementary logging tables often consulted alongside adapter logs.

The most reliable direct dependency remains the REQUEST_ID relationship to FND_CONCURRENT_REQUESTS; other joins are semantic rather than enforced by foreign key constraints.