Search Results raise_update_event

Overview

The APPS.CLN_NOTIFY_SHIPCONF_PKG package body is a shipping-confirmation notification utility that belongs to the Oracle E-Business Suite supply chain execution layer, specifically the Logistics / Shipping Execution (WSH) domain. Its name and dependency footprint indicate that it is responsible for raising workflow business events when outbound delivery shipments are confirmed. Rather than implementing its own shipping logic, the package acts as an orchestration and notification wrapper: it detects a shipment-confirmation condition, assembles the relevant context, and publishes a business event through the Workflow Event (WF_EVENT) infrastructure so that subscribing processes — order management, inventory, or customer-facing notifications — can react.

The package is owned by the APPS schema, is in VALID status, and is classified as an OTHER API type in the ETRM metadata. It is a top-level package body that depends on standard Oracle foundation and shipping packages, including FND_API, FND_MESSAGE, FND_PROFILE, WF_EVENT, and the Workflow parameter-list type WF_PARAMETER_LIST_T, alongside the internal debug helper CLN_DEBUG_PUB and the sequence CLN_GENERIC_S. It is not referenced by any other database object, which means it is invoked directly by application forms, concurrent programs, or shipped event-handling code rather than being a shared dependency of other PL/SQL units.

Key Procedures and Functions

Three documented program units are exposed by this package:

• RAISE_UPDATE_EVENT — Constructs and raises the workflow business event that signals a shipment-confirmation update. This is the central notification routine; it builds the event payload (using the WF_PARAMETER_LIST_T structure) and dispatches it via WF_EVENT so that registered subscribers are notified.
• REQ_ORDER_INF — Resolves or retrieves the required order information associated with the shipment or delivery being confirmed, providing the order-level context needed to populate the event payload and downstream processing.
• UPDATE_NEW_DEL_INTERFACE — Writes to or updates the new delivery interface staging records, aligning the delivery interface data with the confirmed shipment before or as part of the notification flow.

No parameter signatures are documented in the ETRM metadata; the above describes purpose only.

Tables Accessed

The package interacts with the following documented tables and objects (accessed through APPS synonyms):

• CLN_GENERIC_S — A sequence object used to generate unique identifiers. This is the exact object matched by the user's search term "cln_generic_s" and accounts for the package appearing in that result set; it supplies keys for staging or event records.
• WSH_NEW_DEL_INTERFACE — The delivery interface staging table that receives new delivery records; the UPDATE_NEW_DEL_INTERFACE routine maintains these rows so that confirmed shipments flow correctly into the delivery interface.
• WSH_TRANSACTIONS_HISTORY — The shipping transactions history table, read to obtain shipment and transaction context used to determine what event to raise and what data to include.
• WF_PARAMETER_LIST_T — The Workflow parameter-list type used to build the event payload passed to WF_EVENT.
• DUAL — Used for simple single-row value retrieval (for example, obtaining the next sequence value).

Usage Notes

This package is typically invoked during outbound shipping confirmation processing. In a standard EBS 12.1.1 or 12.2.2 environment it would be called from shipping execution forms or shipment-confirmation concurrent programs, or from event-handling custom code that needs to broadcast a shipping-confirmation business event. Because it relies on WF_EVENT, the target business event must be properly defined and have active subscriptions for notification to occur. Its use of FND_PROFILE and the CLN_DEBUG_PUB debug utility suggests profile-controlled behavior and diagnostic logging. As it is not referenced by any other database object, integrators should treat it as an entry-point utility to be called directly, and should confirm the event name and payload contract before relying on it in custom extensions.