Search Results hz_adapter_logs




Overview

The HZ_ADAPTER_LOGS table, owned by the AR (Receivables) schema, is a technical logging table within the Oracle E-Business Suite Trading Community Architecture (TCA) and Receivables data model. Its documented purpose is to track requests for service made to data integration services providers — that is, outbound and inbound interactions between Oracle EBS and external or third-party data quality, validation, tax, address cleansing, or partner integration services. Each row captures a discrete adapter invocation, recording what was sent to the external provider, what was returned, and the resulting HTTP status.

From a Data Vault modeling perspective, the metadata classifies HZ_ADAPTER_LOGS as satellite-leaning. This is a heuristic suggestion: the table is not a core business entity (hub) nor primarily a junction between two business keys (link). Instead, it stores descriptive, contextual, and transactional attributes that would naturally attach as a satellite to a parent process or entity. The only documented foreign key — HZ_ADAPTER_LOGS.REQUEST_ID referencing FND_CONCURRENT_REQUESTS — reinforces this role, tying each log record back to the concurrent program or request that triggered the integration call.

Key Information Stored

The table contains thirteen documented columns, with ADAPTER_LOG_ID serving as the surrogate primary key (constraint HZ_ADAPTER_LOGS_PK) and also appearing as a business-key candidate through the unique index HZ_ADAPTER_LOGS_U1. The most significant columns are:

  • ADAPTER_LOG_ID — Surrogate primary key uniquely identifying each adapter log entry.
  • REQUEST_ID — Foreign key to FND_CONCURRENT_REQUESTS, linking the log to the concurrent request that initiated the integration call.
  • CREATED_BY_MODULE and CREATED_BY_MODULE_ID — Identify the originating application module and its identifier, indicating which integration service or product component made the request.
  • HTTP_STATUS_CODE — The HTTP response code returned by the external service provider, essential for diagnosing success, failure, or timeout conditions.
  • IN_DOC and OUT_DOC — The inbound and outbound payload documents exchanged with the service provider, typically stored as LOB columns. These are the raw request and response content.
  • OBJECT_VERSION_NUMBER — Optimistic locking column used for concurrent update control.
  • CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard EBS audit (WHO) columns tracking record creation and modification.

Two system-managed LOB indexes (SYS_IL0000323547C00012$$ and SYS_IL0000323547C00013$$) correspond to the IN_DOC and OUT_DOC large object columns.

Common Use Cases and Queries

The primary use case is troubleshooting and auditing integration calls to external data services. Support and technical teams query HZ_ADAPTER_LOGS to determine why an address validation or tax service call failed, examining HTTP_STATUS_CODE and the OUT_DOC payload.

SELECT l.adapter_log_id,
       l.request_id,
       l.http_status_code,
       l.creation_date
FROM   hz_adapter_logs l
WHERE  l.http_status_code <> 200
ORDER  BY l.creation_date DESC;

Correlating with the concurrent request provides the program name, responsible user, and phase:

SELECT l.adapter_log_id, r.concurrent_program_id, r.phase_code, r.status_code
FROM   hz_adapter_logs l,
       fnd_concurrent_requests r
WHERE  l.request_id = r.request_id
AND    l.http_status_code IS NOT NULL;

Reporting scenarios include monitoring service provider reliability over time, measuring failure rates by CREATED_BY_MODULE, and auditing payloads for compliance. Because IN_DOC and OUT_DOC are large objects, queries should avoid selecting them unless needed.

Related Objects

  • FND_CONCURRENT_REQUESTS — Joined via REQUEST_ID; supplies the concurrent program, user, and execution status that triggered the adapter call.
  • HZ_ADAPTER_LOGS_PK — Primary key constraint on ADAPTER_LOG_ID.
  • HZ_ADAPTER_LOGS_U1 — Unique index supporting business-key lookup on ADAPTER_LOG_ID.
  • TCA integration service APIs — External data-quality and validation service interfaces that populate IN_DOC and OUT_DOC.
  • HZ_ tables (Trading Community Architecture) — Parties, locations, and addresses processed through these adapter services.

Because the documented relationship data is limited to the FND_CONCURRENT_REQUESTS foreign key, other linkages are inferred from the integration context rather than explicit constraints.