Search Results message_token_id

Overview

CSF_R_MESSAGE_TOKENS is a table in the CSF (Field Service) product schema of Oracle E-Business Suite, present in both the 12.1.1 and 12.2.2 releases. Its documented description is "Message tokens," indicating that it stores the individual token elements that make up a scheduler or message definition. In Oracle Field Service, the scheduling engine and its associated notification mechanisms assemble outbound and internal messages from reusable, parameterized components; each component, or token, is persisted as a row in this table. The table therefore acts as a child detail store for the message constructs managed by the CSF scheduling message framework, and it is not intended to be maintained directly by end users but rather by the application logic that resolves and formats messages at runtime.

The metadata's heuristic Data Vault classification for this table is satellite-leaning. This is a modeling suggestion rather than an EBS-enforced construct: the table attaches descriptive attribute rows (token identity and value) to a parent entity keyed through MESSAGE_ID, and it carries an OBJECT_VERSION_NUMBER for optimistic concurrency — characteristics consistent with a satellite grouping descriptive attributes around a hub or link (here, CSF_R_SCHED_REQUESTS). The presence of a SECURITY_GROUP_ID foreign key further indicates that rows are secured by a Multi-Org or data-security paradigm typical of a satellite surrounding a business key.

Key Information Stored

The table is documented with six columns. The most significant are described below; the surrogate primary key is distinguished from the business-key candidate where the metadata specifies it.

• MESSAGE_TOKEN_ID — the surrogate primary key, enforced by CSF_R_MESSAGE_TOKENS_PK and also covered by the unique index CSF_R_MESSAGE_TOKENS_U1. It provides the stable internal identity for each token row.
• MESSAGE_ID — the foreign key to CSF_R_SCHED_REQUESTS, linking each token to its parent scheduling request/message definition. This is the primary relationship column used in joins.
• NAME — the token's business name or key, identifying which substitution or placeholder the token represents when the message is resolved.
• VALUE — the token's associated value or payload, supplying the data substituted for the named token during message assembly.
• SECURITY_GROUP_ID — the foreign key to FND_SECURITY_GROUPS, governing which security group owns the row and controlling visibility under the EBS data-security model.
• OBJECT_VERSION_NUMBER — the standard EBS concurrency-control attribute used to detect concurrent updates and prevent lost changes.

Together, MESSAGE_TOKEN_ID as the surrogate key and the NAME/MESSAGE_ID pairing as the practical business identity give the table its logical structure. No additional columns beyond the six documented are asserted here.

Common Use Cases and Queries

Typical uses center on inspecting, auditing, or extracting the token definitions attached to a given scheduling message. A common reporting pattern resolves all tokens for a message:

• Retrieve tokens by parent: SELECT message_token_id, name, value FROM csf.csf_r_message_tokens WHERE message_id = :p_message_id ORDER BY message_token_id;
• Join the parent request to display message context: SELECT t.name, t.value FROM csf.csf_r_message_tokens t, csf.csf_r_sched_requests r WHERE t.message_id = r.message_id AND r.message_id = :p_message_id;
• Validate security scope: constrain results by SECURITY_GROUP_ID to respect data-security boundaries during extraction.
• Reconcile duplicates or missing tokens by grouping on NAME within a MESSAGE_ID to detect anomalies ahead of message resolution.

These patterns support diagnostics when a formatted message renders an unresolved token, as well as audits of message configuration and migration/verification scripts that check token completeness. Because the table is application-managed, direct DML is not recommended; such queries are best used read-only.

Related Objects

The following objects are most significant to this table, based on the documented foreign-key relationships and its role in the field service scheduling message framework.

• CSF_R_SCHED_REQUESTS — the parent table joined via CSF_R_MESSAGE_TOKENS.MESSAGE_ID, providing the message definition to which each token belongs.
• FND_SECURITY_GROUPS — referenced through SECURITY_GROUP_ID, controlling data-security visibility of token rows.
• CSF_R_MESSAGE_TOKENS_PK — the primary-key constraint on MESSAGE_TOKEN_ID.
• CSF_R_MESSAGE_TOKENS_U1 — the unique index on MESSAGE_TOKEN_ID, reinforcing the business-key candidate.
• CSF scheduling message/notification APIs and the Field Service concurrent programs that resolve and dispatch messages, which read these tokens at runtime.

Collectively, these relationships confirm that CSF_R_MESSAGE_TOKENS functions as a satellite-leaning detail table anchored to the scheduling-request entity within the CSF schema.