Search Results icx_failures_pk




Overview

ICX_FAILURES is a table owned by the ICX schema within Oracle E-Business Suite, positioned under the Oracle iProcurement product family. As described in the ETRM metadata, it functions as the "Web Store failures table," meaning it records authentication or access failures experienced by users attempting to reach the iProcurement web storefront and related self-service purchasing functionality. The table serves as an audit and diagnostic repository: each row captures a user identifier, an attempted password value, a failure classification code, and the timestamp of the failed attempt, together with standard Oracle EBS audit columns.

The documented physical schema at release 12.2.2 lists nine columns, and the primary key is ICX_FAILURES_PK, which the metadata attributes to USER_NAME. Based on the foreign key relationship ICX_FAILURES.USER_NAME → FND_USER.USER_NAME, the table is a dependent child of the EBS application user registry, not an independent entity. The heuristic Data Vault classification mined from the FK structure is satellite-leaning. In modeling terms, this suggests ICX_FAILURES is best treated as a satellite attached to the FND_USER hub (or a link-adjacent descriptive structure), carrying failure-event attributes rather than establishing new business entities of its own.

Key Information Stored

The table's most significant columns, drawn from the documented nine-column structure, are:

  • USER_NAME — The business identifier of the user whose access attempt failed. It is the column involved in the ICX_FAILURES_PK primary key and the foreign key to FND_USER.USER_NAME, making it the principal join and lookup key.
  • PASSWORD — The password value associated with the failed attempt. Its presence in this table explains the sensitive, security-oriented nature of the object and drives retention and purging policies.
  • FAILURE_CODE — A coded classification of the failure reason, used to distinguish types of unsuccessful storefront access.
  • FAILURE_DATE — The date and time the failure occurred, enabling trend, threshold, and lockout analysis.
  • CREATED_BY, CREATION_DATE — Standard EBS who/when audit columns recorded at row insertion.
  • LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — Standard EBS audit columns capturing the most recent modification and the login context of that modification.

Because the documented primary key is ICX_FAILURES_PK defined on USER_NAME, USER_NAME behaves as the business-key candidate rather than a system-generated surrogate. The audit columns are inherited from the standard EBS WHO column convention and are not unique identifiers.

Common Use Cases and Queries

Typical use cases center on security monitoring, user lockout investigation, and troubleshooting iProcurement access problems. A common pattern counts failures per user over a time window to identify lockout candidates or brute-force attempts:

  • SELECT user_name, COUNT(*) FROM icx.icx_failures WHERE failure_date > SYSDATE - 1 GROUP BY user_name;
  • SELECT user_name, failure_code, failure_date FROM icx.icx_failures WHERE user_name = :user ORDER BY failure_date DESC;
  • SELECT failure_code, COUNT(*) FROM icx.icx_failures GROUP BY failure_code;

These queries support security administrators investigating repeated access denials, DBAs diagnosing storefront availability issues, and auditors reviewing authentication activity. Because the table may retain password fragments, access should be restricted and extracts sanitized.

Related Objects

The most significant related objects, grounded in the documented relationships, include:

  • FND_USER — Joined via ICX_FAILURES.USER_NAME = FND_USER.USER_NAME; the parent reference for every failure row.
  • ICX_FAILURES_PK — The primary key constraint enforcing uniqueness on USER_NAME.
  • ICX schema objects (iProcurement web store) — Sibling tables and views within the ICX module that support storefront session and access management.
  • FND_LOGIN / FND_SIGNON audit objects — Complementary sign-on and authentication audit tables frequently queried alongside ICX_FAILURES for a complete access picture.

These relationships confirm that ICX_FAILURES is a dependent, satellite-style table anchored to the EBS user registry, valuable primarily for security and diagnostic reporting rather than transactional processing.