Search Results per_ri_workbench_items_tl




Overview
Explore in AI Chat

Overview

PER_RI_WORKBENCH_ITEMS_TL is a translation (TL) table in the HR schema of Oracle E-Business Suite, owned under the PER – Human Resources product family. It stores the language-specific, translatable attributes of records defined in its base table, PER_RI_WORKBENCH_ITEMS. The "RI" prefix denotes the Recruitment/Recruiting Intelligence workbench area, and the table supplies localized names and descriptions for the items that appear on the recruiting workbench interface. In Oracle EBS 12.1.1 and 12.2.2, TL tables follow the standard multilingual ("Multi-Language Support", MLS) architecture: the base table holds language-independent columns and a LANGUAGE-independent surrogate key, while the _TL table holds the translated display text keyed by language.

From a Data Vault modeling perspective, the mined metadata classifies this object heuristically as standalone. Because the table carries descriptive, language-dependent attributes tied to a business key rather than acting as a join between two hubs, it is most naturally modeled as a satellite attached to the base PER_RI_WORKBENCH_ITEMS entity, with LANGUAGE forming part of the satellite key. No foreign-key dependency paths were mined, reinforcing the standalone classification.

Key Information Stored

The table contains eleven documented columns. The composite primary key is (WORKBENCH_ITEM_CODE, LANGUAGE), where WORKBENCH_ITEM_CODE identifies the workbench item and LANGUAGE identifies the MLS language row.

  • WORKBENCH_ITEM_CODE – Business identifier of the workbench item; part of the primary key and the join to the base table.
  • LANGUAGE – The MLS language code; part of the primary key.
  • SOURCE_LANG – The source language from which the translation originates.
  • WORKBENCH_ITEM_NAME – The translated, language-specific display name of the item.
  • WORKBENCH_ITEM_DESCRIPTION – The translated descriptive text for the item.
  • ZD_EDITION_NAME – The edition identifier used by EBS 12.2.x Edition-Based Redefinition (EBR); documented in the unique index.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN – Standard WHO audit columns recording the most recent change.
  • CREATED_BY, CREATION_DATE – Standard WHO columns recording initial row creation.

The documented unique index is (WORKBENCH_ITEM_CODE, LANGUAGE, ZD_EDITION_NAME). This business-key candidate extends the primary key with ZD_EDITION_NAME, reflecting the 12.2.x edition-aware uniqueness model. The primary key should be distinguished from this unique index: the PK enforces language-level uniqueness, whereas the unique index additionally scopes uniqueness to the online edition.

Common Use Cases and Queries

Typical usage centers on retrieving localized workbench item text for a specific runtime language, joined back to the base table. A representative query filters on the session language and the current edition:

  • Localized display: join PER_RI_WORKBENCH_ITEMS to PER_RI_WORKBENCH_ITEMS_TL on WORKBENCH_ITEM_CODE, filtering LANGUAGE = USERENV('LANG').
  • Missing-translation reporting: compare base item counts against _TL rows per LANGUAGE to identify untranslated items.
  • Audit and change tracking: query LAST_UPDATE_DATE and LAST_UPDATED_BY to report on translation maintenance activity.
  • Edition-aware extraction in 12.2.2: constrain on ZD_EDITION_NAME to isolate the correct edition's translations.

A concise pattern is: SELECT b.workbench_item_code, t.workbench_item_name, t.workbench_item_description FROM per_ri_workbench_items b, per_ri_workbench_items_tl t WHERE b.workbench_item_code = t.workbench_item_code AND t.language = USERENV('LANG');

Related Objects

The most significant related object is the base table PER_RI_WORKBENCH_ITEMS, joined on WORKBENCH_ITEM_CODE and supplying the language-independent data this translate table enriches. In 12.2.x, the edition metadata associated with ZD_EDITION_NAME links the row to the EBR edition set. Broader PER recruiting objects—such as other recruitment workbench configuration tables and the multilingual reference tables that share the same WHO and MLS column conventions—round out the dependency landscape. No foreign-key relationships were mined, so all associations with this table should be treated as logical joins keyed on WORKBENCH_ITEM_CODE rather than enforced constraints.