Results for “hz_party”

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

Overview

WF_HZ_PARTY_ROLES is a database view registered under the FND — Application Object Library product family in Oracle E-Business Suite 12.1.1 and 12.2.2. Its documented purpose is to serve as the Bulk Sync Directory Service Role View for Orig System HZ_PARTY. In practical terms, the view exposes TCA (Trading Community Architecture) party records — persons, organizations, and party relationships — in the flattened column layout expected by the Oracle Workflow / Directory Service synchronization infrastructure, which publishes role data to external directory services such as LDAP or OID.

The view normalizes the heterogeneous HZ_PARTIES model into a single, role-oriented result set: each row represents an addressable "role" entity identified by the synthetic key 'HZ_PARTY:'||TO_CHAR(PER_ID). It carries display names, e-mail addresses, preferred language and territory, status, and a role classification of 'HZ_PARTY'. Because it is a bulk-sync view rather than an operational table, it is read-only and is queried only during directory synchronization runs.

Underlying Base Objects

The ETRM metadata records no separately documented base objects, and the view is marked "Not implemented in this database," meaning it is delivered as a definition compiled conditionally by the TCA installation scripts. The view text shows the actual dependencies. The inline subquery joins four TCA tables: HZ_PARTIES (aliased P for the subject party, and SUBJ for the related subject), HZ_PARTY_RELATIONSHIPS (PR, outer-joined on PARTY_ID with a filter of STATUS = 'A'), and HZ_ORG_CONTACTS (OC, outer-joined on PARTY_RELATIONSHIP_ID). The outer query joins HZ_PERSON_LANGUAGE (PL, outer-joined on PARTY_ID with PRIMARY_LANGUAGE_INDICATOR = 'Y') and FND_LANGUAGES (L1, outer-joined on LANGUAGE_CODE).

The driving predicate restricts rows to parties of type PERSON or PARTY_RELATIONSHIP with status A or I, and applies the OR condition that the party is a PERSON or that a valid organization-contact relationship exists. Internal hints (ORDERED USE_HASH, NO_MERGE, INDEX_FFS(HZ_ORG_CONTACTS_N3)) indicate the view is tuned for full-table scans during bulk extraction rather than for selective OLTP access.

Key Columns

• NAME — the synthetic role identifier, constructed as 'HZ_PARTY:' concatenated with the party ID; used as the directory-service unique key.
• DISPLAY_NAME — NVL(SUBJ_NAME, PER_NAME); the subject party name takes precedence over the party's own name.
• DESCRIPTION — the underlying party name (PER_NAME).
• EMAIL_ADDRESS — the party's e-mail address from HZ_PARTIES, the primary routing attribute for directory notifications.
• LANGUAGE / TERRITORY — the preferred language's NLS_LANGUAGE and NLS_TERRITORY, derived through FND_LANGUAGES.
• ORIG_SYSTEM / ORIG_SYSTEM_ID — populated with 'HZ_PARTY' and the party ID respectively, identifying the source system of the role.
• STATUS — decoded from the party status: 'A' becomes ACTIVE, anything else becomes INACTIVE.
• USER_FLAG — literal 'Y', marking the row as a user-addressable directory entry.
• NOTIFICATION_PREFERENCE / FAX / START_DATE / EXPIRATION_DATE / SECURITY_GROUP_ID — defined in the column list but returned as literals or NULL in the view text.

Common Use Cases and Queries

Typical consumers are Workflow directory synchronization concurrent programs and diagnostic queries that validate which TCA parties will be published to the directory. A representative query retrieves active, e-mail-bearing parties with their language:

• SELECT name, display_name, email_address, language, territory, status FROM wf_hz_party_roles WHERE status = 'ACTIVE';
• SELECT orig_system_id, display_name FROM wf_hz_party_roles WHERE email_address IS NOT NULL ORDER BY display_name;
• SELECT COUNT(*) FROM wf_hz_party_roles WHERE user_flag = 'Y'; — verifies the volume of directory-eligible roles before a sync run.

Because the view is not implemented in every environment, administrators should confirm its existence via ALL_VIEWS before referencing it, and treat results as read-only snapshots of TCA state at query time.