Search Results wf_event




Overview
Explore in AI Chat

Overview

The APPS.WF_EVENT package body implements the core event subsystem of the Oracle Workflow Business Event System (BES) in Oracle E-Business Suite 12.1.1 and 12.2.2. Its principal business function is to provide the runtime engine through which business events are raised, enqueued, dequeued, and dispatched to registered subscriptions. Every significant transaction in EBS — order entry, invoice creation, employee updates, and similar activities — can generate a workflow event, and WF_EVENT is the programmatic layer that manages the lifecycle of those events from the moment they are raised until subscribers are executed.

The package mediates between the Oracle Advanced Queuing (AQ) infrastructure, the Workflow subscription repository, and the agent/system definitions that determine routing. Because it is the central dispatcher for the Business Event System, it is one of the most heavily depended-upon objects in the EBS schema, with the ETRM metadata recording that it is referenced by 664 other database objects. It is classified as OTHER in the API classification scheme, confirming that it is an internal infrastructure package rather than a public, supported end-user API.

Key Procedures and Functions

The documented 43 procedures and functions fall into several functional groupings:

  • Event generation and queuing: RAISE and ENQUEUE create an event and place it on the appropriate AQ queue; DEQUEUE removes an event from the queue for processing.
  • Dispatch: DISPATCH and DISPATCH_INTERNAL drive the subscription-matching and execution logic that identifies which subscriptions apply to a raised event and invokes their corresponding functions or workflows. SETDISPATCHMODE controls whether dispatch proceeds in deferred or synchronous mode.
  • Subscription and listener management: LISTEN, LISTEN_CONCURRENT, LISTEN_GRP, and LISTEN_GRP_CONCURRENT establish inbound listeners that consume events from local or remote queues, including concurrent-program-driven listener variants.
  • Agent handling: NEWAGENT supports the creation or resolution of workflow agents used in event routing.
  • Parameter list utilities: ADDPARAMETERTOLIST, ADDPARAMETERTOLISTPOS, GETVALUEFORPARAMETER, and GETVALUEFORPARAMETERPOS build and interrogate the parameter lists that carry event payload and metadata.
  • Recipients and error handling: SET_RECIPIENT_LIST defines the target recipients of an event; SEND transmits notification messages; SETERRORINFO records error context for failed operations.
  • Support utilities: INITPHASEMINTHRESHOLD and TEST provide initialization and diagnostic support.

Tables Accessed

The package reads and writes the core Business Event System tables through APPS synonyms. WF_EVENT_T and WF_EVENT_OBJ hold event definitions and runtime event data, while WF_EVENT_SUBSCRIPTIONS and WF_EVENT_SUBS_TAB hold subscription rules. Agent and routing definitions are resolved from WF_AGENTS and WF_AGENT_GROUPS. Event payload and metadata parameters are carried in WF_PARAMETER_LIST_T and WF_PARAMETER_T. System registration and queue lookup rely on WF_SYSTEMS and ALL_QUEUES, with messaging handled through DBMS_AQ/DBMS_AQADM. Error and logging data is written via FND_LOG and WF_LOG_PKG. Concurrent listener variants additionally reference FND_CONCURRENT_PROGRAMS, FND_CONCURRENT_REQUESTS, FND_RESPONSIBILITY, FND_USER, and FND_APPLICATION.

Usage Notes

WF_EVENT is not intended for direct invocation by end users or typical customizations. It is called internally by the Workflow Engine, by other Workflow packages, and by the standard Business Event System concurrent programs and listeners. Customization is normally performed declaratively through the Workflow Administrator responsibility by defining events, subscriptions, and agents rather than by calling this package. When a developer does need to raise an event programmatically from custom PL/SQL, the conventional approach is to use WF_EVENT.RAISE or the higher-level WF_EVENT_GROUP utilities, while allowing WF_EVENT to manage enqueue and dispatch internally. Because it depends on Oracle AQ and on numerous fellow Workflow packages, any modification is unsupported, and troubleshooting should focus on subscription definitions, agent configuration, and the queue state reported through WF_EVENT error logging.