Search Results hz_adapter_users

Overview

HZ_ADAPTER_USERS is a table owned by the AR (Receivables) schema in Oracle E-Business Suite, documented as VALID across ETRM 12.1.1 and 12.2.2. Its stated purpose is to store user information for adapters, meaning it maintains the association between registered adapter definitions (held in HZ_ADAPTERS) and the individual application or database users authorized to operate through those adapters. Adapters in the HZ schema family are integration components that broker data exchange between Oracle EBS and external or legacy systems; the user records here govern which identities are permitted to invoke an adapter rather than defining the adapter itself.

From a data-modeling perspective, the metadata's heuristic Data Vault classification for this object is standalone. It carries a single foreign key to HZ_ADAPTERS but is not itself a dependent extension of another hub, and it holds no parent references outside that one relationship. A reasonable modeling suggestion is therefore to treat HZ_ADAPTER_USERS as a link-style entity that connects the adapter hub to a user identity, while its descriptive and audit attributes behave satellite-like. Because it is not classified as a hub, it should not be used as an independent subject area anchor in an analytical model.

Key Information Stored

The table exposes eight documented columns. The most significant are:

• ADAPTER_USER_ID — the surrogate primary key. It is the sole documented unique index (HZ_ADAPTER_USERS_U1) and the business-key candidate for the row. There is no separate natural unique key, so this identifier is the authoritative row locator.
• ADAPTER_ID — the foreign key referencing HZ_ADAPTERS. This is the join column that links each authorized user back to the adapter definition it serves.
• USERNAME — the application or database user name authorized for the adapter. In the absence of additional natural-key columns, this attribute, combined with ADAPTER_ID, expresses the core business fact of the table.
• CREATION_DATE, CREATED_BY — standard audit columns recording the insert timestamp and the user or process that created the row.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard audit columns capturing the most recent modification timestamp, the responsible user, and the login session context.

The audit columns follow Oracle EBS conventions and support change tracking and troubleshooting, but they carry no business meaning beyond provenance.

Common Use Cases and Queries

Typical usage centers on validating whether a given user is authorized for a given adapter, and on auditing the population of adapter authorizations. A basic authorization check joins through the foreign key:

• SELECT au.ADAPTER_USER_ID, au.USERNAME, a.* FROM AR.HZ_ADAPTER_USERS au, AR.HZ_ADAPTERS a WHERE au.ADAPTER_ID = a.ADAPTER_ID AND au.USERNAME = :user_name;
• Enumerating all users bound to one adapter: SELECT USERNAME, CREATION_DATE, CREATED_BY FROM AR.HZ_ADAPTER_USERS WHERE ADAPTER_ID = :adapter_id ORDER BY USERNAME;
• Auditing recent changes: filter on LAST_UPDATE_DATE between a reporting window to identify rows whose authorization was modified.
• Reconciliation reporting: count distinct USERNAME values per ADAPTER_ID to detect adapters with no authorized users or with unexpectedly broad access.

Because the table is small and keyed by a single surrogate column, queries are inexpensive and generally safe for read-only operational reporting.

Related Objects

The dominant relationship is the documented foreign key from this table to HZ_ADAPTERS via ADAPTER_ID; that parent table supplies the adapter definition and metadata that gives each user authorization its context. Other significant objects in the same functional family include the HZ adapter and party-related tables and views that share the HZ_ prefix, as well as standard AR audit and concurrent-program objects used to trace how rows were created. The ADAPTER_USER_ID column serves as the primary key, so any child table referencing this parent would do so on that column, though no downstream foreign keys are documented in the provided metadata. Integration and interface logic consuming adapters typically resolves user eligibility through this table, making it a dependency of adapter execution paths rather than a standalone reporting subject.