Search Results msc_scn_activity_wf




Overview
Explore in AI Chat

Overview

MSC_SCN_ACTIVITY_WF is an Oracle Applications (APPS) PL/SQL package body that supports the workflow-driven notification and monitoring features of the Advanced Supply Chain Planning (ASCP) scenario management framework. Its central role is to detect changes made to planning scenarios and their associated scenario activities, and to dispatch workflow notifications to the appropriate users. In Oracle EBS 12.1.1 and 12.2.2, scenario definition, copying, and modification are administered through the MSC_SCENARIOS and MSC_SCENARIO_ACTIVITIES tables; MSC_SCN_ACTIVITY_WF provides the programmatic bridge between those planning metadata records and the Oracle Workflow engine (WF_ENGINE). As a result, planners and supply chain administrators are notified when scenarios or their contained activities change, supporting collaboration and control over the planning cycle. The package is classified as an "OTHER" API rather than a public, supported interface, indicating that it is intended primarily for internal use by the ASCP application components.

Key Procedures and Functions

The ETRM metadata documents two procedures within this package body:

  • SENDFYINOTIFICATION — Constructs and sends a "For Your Information" (FYI) workflow notification. This procedure assembles the notification content relating to scenario activity changes and routes it to the target user through the Oracle Workflow notification infrastructure. It draws on user information to resolve the recipient and relies on the workflow engine to deliver the message.
  • MONITOR_SCN_CHANGES — Evaluates changes to planning scenarios and their activities and determines whether notification is warranted. It serves as the monitoring entry point that identifies modifications worth communicating, then invokes the notification path to alert the responsible parties.

No parameter signatures are documented in the available metadata; the descriptions above reflect the functional intent implied by the procedure names and the package's dependency profile. The package exposes no other documented procedures or functions.

Tables Accessed

The package references the following tables (through APPS synonyms) as documented in the ETRM metadata:

  • MSC_SCENARIOS — Stores the planning scenario definitions; monitored by MONITOR_SCN_CHANGES to detect scenario-level changes.
  • MSC_SCENARIO_ACTIVITIES — Holds the activities associated with each scenario; changes here drive the notification logic.
  • MSC_SCENARIO_SETS — Defines scenario set groupings, used to contextualize which scenarios and activities are relevant to a notification.
  • FND_USER — Provides user account information to resolve notification recipients for SENDFYINOTIFICATION.
  • MSC_FORM_QUERY_S — A sequence used in the ASCP forms infrastructure, supporting key or query generation within the package's operations.
  • DUAL — The standard Oracle single-row utility table, referenced for trivial evaluations.

Additional dependencies noted in the metadata include FND_GLOBAL (for session context such as the current user), MFG_LOOKUPS (for lookup values), and internal ASCP packages MSC_UTIL and MSC_WS_COMMON, together with the WF_ENGINE workflow API that performs actual notification delivery.

Usage Notes

MSC_SCN_ACTIVITY_WF is not referenced by any other database object according to the documented dependency analysis, and it is classified as an internal "OTHER" API. It is therefore not intended as a general-purpose, supported extension point for custom development. In practice, it is invoked within the ASCP scenario management flow — for example, when a user creates, copies, or modifies a scenario or its activities — to trigger monitoring and notification logic. Because it integrates directly with Oracle Workflow (WF_ENGINE) and relies on FND_GLOBAL session context, it is expected to execute inside an initialized EBS application session, such as through the ASCP HTML or forms-based planning UI or a related concurrent process. Customers and integrators should treat the package as internal; any custom invocation should be undertaken with caution and validated against the specific EBS release, since the procedures are undocumented at the parameter level.