Results for “cz_constraint_messages_tl”

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

Overview

CZ_CONSTRAINT_MESSAGES_TL is the translated (MLS) child table of the Oracle EBS Configurator constraint message repository, belonging to the BOM — Bills of Material product family. Configurator is the rules engine that governs how a configured item is assembled: it validates user selections against constraint definitions and, on failure, returns a message to the configurator runtime UI or to an order capture session. CZ_CONSTRAINT_MESSAGES_TL stores the language-specific text of those messages — the warning, error, and informational strings displayed when a constraint is satisfied, violated, or otherwise evaluated.

The "_TL" suffix identifies a Translation table in the Oracle EBS MLS (Multi-Lingual Support) architecture. Unlike a base table that holds a single row per entity, a translation table carries one row per (entity, language) pair, allowing the same constraint to present localized text in any installed language. Records are maintained through the Configurator message administration forms and are seeded or propagated from the corresponding base message table.

Under the heuristic Data Vault classification mined from the FK structure, this object is modeled as standalone — it participates in no documented foreign key relationships. In Data Vault terms, a standalone translated table is most naturally represented as a satellite on a parent message hub, keyed by the parent message identifier plus the language code, rather than as an independent hub or link. This classification is a modeling suggestion only; the ETRM metadata documents no FK edges for this object.

Key Information Stored

The documented structure is deliberately narrow: it is a text-holding satellite, not a transactional entity.

• CONSTRAINT_ID — the identifier of the parent constraint message to which the translated text belongs. This is a business-key component and the join back to the base (non-translated) constraint message definition.
• LANGUAGE — the NLS language code for the row's text, such as US for American English. This is the second business-key component and determines which locale the message serves.
• Translated message text columns — the descriptive attributes holding the actual localized strings (message text and any related display text) surfaced to the user at configuration time. These are the payload columns of the satellite and vary by language row.

The primary key is CZ_CONSTRAINT_MESSAGES_TL_PK, defined on the composite of CONSTRAINT_ID and LANGUAGE. This composite is both the surrogate primary key of the table and the natural business key of the translation — the pairing of a constraint with a language is what makes each row unique. Because the metadata documents no secondary unique indexes, CONSTRAINT_ID and LANGUAGE together remain the only documented uniqueness constraint. There is no surrogate sequence column distinct from the entity identifier.

The ETRM documentation records this object as "Not implemented in this database," meaning it is present in the data model but was not instantiated in the sampled environment — typically because Configurator was not installed or no constraints were defined in that instance.

Common Use Cases and Queries

Typical usage is multilingual retrieval of constraint messages for a runtime prompt, a configuration report, or an upgrade/language-installation check.

• Retrieve a message in a specific language — join the translation row to its base message using CONSTRAINT_ID and filter on LANGUAGE, with a fallback to the base-language row when no translation exists.
• Find untranslated messages — compare the distinct set of CONSTRAINT_ID values in the base message table against those in the translation table for a target LANGUAGE to expose coverage gaps prior to a localization rollout.
• Detect duplicate or conflicting text — group by CONSTRAINT_ID and LANGUAGE (the PK columns) to verify uniqueness, and compare text across languages to spot copy-forwarded English strings left untranslated.
• Reporting and auditing — extract all message text by language for documentation of the configuration rules delivered with a solution.

A representative pattern is: SELECT t.constraint_id, t.language, t.message_text FROM cz_constraint_messages_tl t WHERE t.language = :lang AND t.constraint_id = :constraint_id; — a single-row lookup exploiting the primary key. Bulk extraction filters on LANGUAGE alone. Because no FKs are documented, joins to the base message table must be written explicitly on CONSTRAINT_ID rather than inferred from the model.

Related Objects

Although the FK structure is empty, the following objects are functionally significant to this table. Join columns are noted where the metadata supports them.

• CZ_CONSTRAINT_MESSAGES (or the equivalent base constraint message table) — the non-translated parent; joined on CONSTRAINT_ID. This is the primary dependency.
• CZ_CONSTRAINTS — the constraint definitions that reference messages; related through CONSTRAINT_ID.
• CZ_CONFIG_ATTRIBUTES and the Configurator attribute tables — the selection model whose validation triggers these messages.
• CZ_CONFIGS / configured item structures — runtime results that record constraint outcomes.
• FND_LANGUAGES — supplies the valid values and descriptions for the LANGUAGE column.
• Configurator constraint validation APIs in the CZ schema — programmatic callers that read message text for a given constraint and session language.

Because the metadata records no foreign keys, all of these relationships are logical rather than enforced, and ETRM classifies the object as standalone for Data Vault purposes.