Search Results ego_user_v




Overview
Explore in AI Chat

Overview

EGO_USER_V is a documented view owned by the APPS schema in Oracle E-Business Suite, supplied by the EGO product family, Advanced Product Catalog. Its status is VALID in both the 12.1.1 and 12.2.2 releases, and its stated purpose in the ETRM documentation is to hold "the user and party information." In practical terms, the view presents a denormalized, ready-to-query join between an application user account and the corresponding Trading Community Architecture (TCA) person party record. Rather than requiring developers and analysts to resolve the linkage between FND_USER and HZ_PARTIES themselves, EGO_USER_V exposes a single row per user with the login name, the internal user identifier, the party identifier, and the party name already associated.

Because the object is a view rather than a table, it carries no independent storage and no maintenance obligations; it is a read-only projection maintained by Oracle as part of the EGO schema deployment. This makes it suitable for reporting, ad hoc queries, and lightweight integration lookups where a user must be correlated to a party for downstream TCA processing. It is not an interface table and should not be used for direct DML.

Underlying Base Objects

The ETRM metadata documents two referenced base objects, both accessed through synonyms: FND_USER and HZ_PARTIES. As recorded in the view text, the definition is:

The two are joined on the predicate P.PARTY_ID = U.PERSON_PARTY_ID, with the additional restriction that P.PARTY_TYPE must equal 'PERSON'. This filter is significant: the view intentionally excludes organization parties and returns only those user accounts that have been linked to an individual person party. Users whose PERSON_PARTY_ID is null, or whose party record is typed as an organization or group, do not appear in the result set.

Key Columns

  • USER_NAME — the FND_USER login name, the human-readable identifier used at sign-on and in audit trails.
  • USER_ID — the numeric primary key of the FND_USER record, used throughout EBS as the foreign key for created-by, last-updated-by, and assigned-user references.
  • PARTY_ID — the TCA party identifier from HZ_PARTIES, the anchor key for party-related data such as contacts, addresses, and relationships.
  • PARTY_NAME — the formatted name of the person party as maintained in TCA.

All four columns are exposed without qualification, so a query against EGO_USER_V returns them directly.

Common Use Cases and Queries

The principal use case is resolving a user to a party and vice versa. Typical scenarios include reporting on the person behind an application account, validating that a user is properly linked to TCA before invoking party-dependent APIs, and enriching catalog or item audit data with the party name.

A basic lookup by login name:

  • SELECT user_id, user_name, party_id, party_name FROM apps.ego_user_v WHERE user_name = :login;

Resolving a party identifier back to its user:

  • SELECT user_name FROM apps.ego_user_v WHERE party_id = :party_id;

Joining the view to other EBS objects through USER_ID for reporting:

  • SELECT v.user_name, v.party_name, t.creation_date FROM apps.ego_user_v v, apps.some_txn_tbl t WHERE t.created_by = v.user_id;

Because the view is a simple two-table join with an equality predicate on indexed keys, performance is generally acceptable for interactive queries; heavy batch use should still be validated against the access paths on FND_USER.PERSON_PARTY_ID and HZ_PARTIES.PARTY_ID.