Search Results xdp_fmc_v




Overview
Explore in AI Chat

Overview

XDP_FMC_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite, registered as a VALID object within the XDP – Provisioning product family. It is documented in ETRM as a view "used to retrieve workflow notifications." The name and structure indicate that it serves as a simplified, denormalized access point onto the Oracle Workflow notification queue, exposing the notification records managed by the Workflow Notification System and enriching each row with the human-readable meaning of the notification status.

In Oracle EBS 12.1.1 and 12.2.2, workflow notifications are the mechanism by which concurrent programs, approval processes, and provisioning flows communicate pending actions to users and roles. Rather than forcing developers and reporting tools to join the low-level WF_NOTIFICATIONS table to the WF_LOOKUPS view directly, XDP_FMC_V presents the combined result as a single, stable object. This makes it suitable for reporting, custom forms, OAF pages, and integration extracts. Because the view is defined in the APPS schema, it inherits standard EBS security conventions; access is controlled through grants and synonyms rather than the view itself, and consumers generally reference APPS.XDP_FMC_V or a local synonym.

Underlying Base Objects

Per the documented ETRM metadata for 12.2.2, the view is defined over two referenced base objects:

  • WF_NOTIFICATIONS (SYNONYM) — the core Workflow table holding one row per notification, including routing, status, priority, and the access key. In the view text this object is aliased N.
  • WF_LOOKUPS (VIEW) — the Workflow lookup view supplying translatable lookup meanings. In the view text this object is aliased L.

The join is an equality condition restricting the lookup to the notification status lookup type and matching code to status: L.LOOKUP_TYPE = 'WF_NOTIFICATION_STATUS' AND L.LOOKUP_CODE = N.STATUS. The result is a single row per notification, with the raw status code retained alongside its decoded meaning. No aggregation or filtering of notifications by user, role, or date is applied inside the view, so all notifications visible to the querying session's privileges are returned. Because both base objects are owned by the Workflow schema and exposed through synonyms in APPS, the view remains consistent across the 12.1.1 and 12.2.2 releases, where the underlying Workflow tables are structurally unchanged.

Key Columns

The view exposes seventeen columns. The most operationally significant are:

  • ROW_ID — the ROWID of the underlying WF_NOTIFICATIONS row, useful for precise row identification in updates or debugging (the Workflow notification identifier is NOTIFICATION_ID).
  • NOTIFICATION_ID — unique primary identifier of the notification, used by most Workflow APIs.
  • GROUP_ID — grouping identifier for notifications belonging to the same batch or activity group.
  • MESSAGE_TYPE / MESSAGE_NAME — the workflow item type and message that generated the notification.
  • RECIPIENT_ROLE — the role or user to whom the notification was sent.
  • STATUS — the notification status code (for example OPEN, CLOSED, or CANCELED).
  • STATUS_NAME — the decoded MEANING from WF_LOOKUPS for the status code.
  • ACCESS_KEY — the unique access key that allows a recipient to respond to the notification without logging in via the standard Workflow interface; it is central to direct-response and email-based approval flows.
  • MAIL_STATUS — indicates whether and how the notification was delivered by e-mail.
  • PRIORITY, BEGIN_DATE, END_DATE, DUE_DATE — scheduling and urgency attributes controlling when the notification is active and when it is due.
  • USER_COMMENT, CALLBACK, CONTEXT — free-text response, callback procedure, and context payload associated with the notification.

Common Use Cases and Queries

The principal scenario is displaying or extracting pending and historical notifications with readable status text, and retrieving the access key for direct-response handling. A typical query lists open notifications for a role:

SELECT notification_id, recipient_role, message_name, status_name, access_key, due_date FROM apps.xdp_fmc_v WHERE status_name = 'Open' ORDER BY due_date;

Because the ETRM metadata is limited to structure rather than row-level semantics, developers should treat STATUS_NAME as the display value and STATUS as the code for programmatic comparisons. Access key retrieval supports workflows that embed a response link in e-mail notification bodies, enabling recipients to approve or reject without an EBS login. Note that the view returns all notifications visible to the session's privileges; in practice queries are constrained by RECIPIENT_ROLE, MESSAGE_NAME, or date ranges for performance and relevance.