Results for “parameter_name_1”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

ICX_AUDIT is a transactional audit table owned by the ICX schema within Oracle E-Business Suite, serving as the web transaction audit repository for Oracle iProcurement. The table captures the details of web requests processed by the iProcurement application tier, recording both the request metadata (server, port, script, path) and the user-supplied parameters passed in the HTTP call. Its role is diagnostic and forensic: it allows administrators and support engineers to reconstruct exactly what a user submitted to iProcurement at a given point in time, tying the request back to a specific session and a specific application user.

In Data Vault modeling terms, the metadata heuristic classifies ICX_AUDIT as a link entity. This is a modeling suggestion derived from its foreign key structure: the table does not stand alone as a hub of business identity, but rather associates two existing hubs — a session (via SESSION_ID referencing ICX_SESSIONS) and a user (via WEB_USER_ID referencing FND_USER) — and records the measurable event of a web transaction occurring between them. Practitioners designing a Data Vault representation would thus place ICX_AUDIT as a link table hanging off the ICX_SESSIONS and FND_USER hubs, with the request attributes carried as link effectivity or as a satellite.

Key Information Stored

The table contains 31 documented columns. The most significant are:

• AUDIT_ID — the surrogate primary key, enforced by the ICX_AUDIT_PK constraint. It is also the sole business-key candidate, enforced by the unique index ICX_AUDIT_U1. Each row holds one distinct audited web transaction.
• SESSION_ID — foreign key to ICX_SESSIONS, identifying the iProcurement web session in which the transaction occurred.
• WEB_USER_ID — foreign key to FND_USER, identifying the application user who initiated the request.
• SERVER_NAME, SERVER_PORT — the application-tier host and port that serviced the request, useful for load-balancing and multi-node diagnostics.
• SCRIPT_NAME, PATH_INFO — the invoked script or servlet and any additional path metadata, which together identify the specific application entry point.
• PARAMETER_NAME_1 … PARAMETER_NAME_9 and PARAMETER_1 … PARAMETER_9 — nine name/value pairs capturing the request parameters submitted by the user. This is the core forensic payload of the table.
• CONNECT_DATE — the connection timestamp associated with the audited request.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — the standard EBS WHO columns recording row creation and last modification.

The distinction between the surrogate key (AUDIT_ID) and the business-key candidate is nominal here: AUDIT_ID is documented as both the primary key and the unique index column, so no composite natural key is exposed in the metadata.

Common Use Cases and Queries

The primary use case is troubleshooting and audit reconstruction. A support analyst investigating a user complaint about a failed or unexpected iProcurement action can join ICX_AUDIT to ICX_SESSIONS and FND_USER to reconstruct the request timeline and the parameter values submitted. A representative query retrieves the most recent audited transactions for a given user:

• Identify a user's recent transactions: select AUDIT_ID, SESSION_ID, SCRIPT_NAME, CONNECT_DATE from ICX_AUDIT where WEB_USER_ID = :user_id order by CONNECT_DATE desc.
• Correlate a transaction to its session and user: join ICX_AUDIT.SESSION_ID to ICX_SESSIONS and ICX_AUDIT.WEB_USER_ID to FND_USER.
• Search by request parameter: filter on PARAMETER_NAME_1 through PARAMETER_NAME_9 and the matching PARAMETER_1 through PARAMETER_9 columns to locate a specific document, requisition, or item reference.
• Server/node analysis: group by SERVER_NAME and SERVER_PORT to determine which application tier handled a period of traffic.
• Volume and trend reporting: aggregate count of AUDIT_ID by CREATION_DATE for capacity and usage trending.
• Data retention and purge: identify rows older than the retention window by CREATION_DATE for archival or cleanup.

Related Objects

The FK metadata documents two outbound relationships, and these are the most significant related objects:

• ICX_SESSIONS — joined on ICX_AUDIT.SESSION_ID = ICX_SESSIONS.SESSION_ID; supplies session-level context for each audited transaction.
• FND_USER — joined on ICX_AUDIT.WEB_USER_ID = FND_USER.USER_ID; resolves the numeric user identifier to a named application user for reporting.

Beyond these two documented foreign keys, administrators commonly correlate ICX_AUDIT with FND_LOG_MESSAGES and related iProcurement diagnostic views when performing end-to-end troubleshooting, and with the FND_APPLICATION and FND_LOGIN audit tables for broader application-usage reporting. The table is not typically referenced by other tables through inbound foreign keys; it is a leaf audit entity whose value is realized through these outbound joins rather than through dependent children.