Search Results hz_adapter_logs_pk
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.
-
Table: HZ_ADAPTER_LOGS
12.1.1
owner:AR, object_type:TABLE, fnd_design_data:AR.HZ_ADAPTER_LOGS, object_name:HZ_ADAPTER_LOGS, status:VALID, product: AR - Receivables , description: The HZ_ADAPTER_LOGS table tracks requests for service from data integration services providers , implementation_dba_data: AR.HZ_ADAPTER_LOGS ,
-
Table: HZ_ADAPTER_LOGS
12.2.2
owner:AR, object_type:TABLE, fnd_design_data:AR.HZ_ADAPTER_LOGS, object_name:HZ_ADAPTER_LOGS, status:VALID, product: AR - Receivables , description: The HZ_ADAPTER_LOGS table tracks requests for service from data integration services providers , implementation_dba_data: AR.HZ_ADAPTER_LOGS ,
-
PACKAGE BODY: APPS.HZ_ADAPTER_LOGS_PKG
12.1.1
-
PACKAGE BODY: APPS.HZ_ADAPTER_LOGS_PKG
12.2.2
-
APPS.HZ_ADAPTER_LOGS_PKG dependencies on FND_MESSAGE
12.2.2
-
APPS.HZ_ADAPTER_LOGS_PKG dependencies on HZ_ADAPTER_LOGS
12.1.1
-
APPS.HZ_ADAPTER_LOGS_PKG dependencies on HZ_ADAPTER_LOGS
12.2.2
-
APPS.HZ_ADAPTER_LOGS_PKG dependencies on FND_MESSAGE
12.1.1
-
eTRM - AR Tables and Views
12.2.2
description: Territory information ,
-
eTRM - AR Tables and Views
12.1.1
description: Territory information ,
-
eTRM - AR Tables and Views
12.2.2
description: Territory information ,
-
eTRM - AR Tables and Views
12.1.1
description: Territory information ,