PL/SQLadvanced
Workflow Business Events and Event Subscriptions
Explain how Business Events decouple custom logic from core Oracle transaction processing
A business event is EBS announcing that something happened. Custom code subscribes to it, without Oracle's code knowing anything about you.
Business Events are like a public announcement system in an airport: the airport (Oracle core code) doesn't know or care who's listening, it just broadcasts 'Flight 202 now boarding' (raises the event), and any subscribed party — a specific passenger's phone app, a gate agent's screen, a shuttle dispatcher — reacts independently without the announcement system needing to know about them individually.
Key Concepts
1
This is the supported alternative to putting a trigger on a seeded table.
2
Oracle raises hundreds of them.
oracle.apps.po.event.approve a purchase order was approved
oracle.apps.ap.event.invoice... an invoice was validated
oracle.apps.per.api.employee... an employee record changed3
A subscription registers what to do.
event: oracle.apps.po.event.approve
action: run PL/SQL procedure XX_PO_NOTIFY.on_approval
phase: 1-99 synchronous, 100+ deferred4
The procedure takes a standard signature:
5
FUNCTION on_approval(p_subscription_guid IN RAW,
p_event IN OUT WF_EVENT_T) RETURN VARCHAR2 IS
l_po_id NUMBER := p_event.GetValueForParameter('PO_HEADER_ID');
BEGIN
...
RETURN 'SUCCESS';
END;6
Phase decides synchronous or deferred, and the choice matters.
phase < 100 runs in-line with the transaction. Your code can
fail the transaction -- which is what you want for
validation, and a risk for anything else.
phase >= 100 queued through Advanced Queuing and processed by
the event manager afterwards. The transaction is
not affected by your failure.7
So custom validation that must block an approval is synchronous. Sending a notification or calling an
external system is deferred — because a slow or failing integration should not roll back a purchase order.
8
Why this beats a trigger. The event is a published extension point. Oracle raises it deliberately, at a
defined moment, with defined parameters, and commits to it across patches.
9
A trigger fires at an undefined point relative to Oracle's own logic, can hit mutating table errors, and is
revalidated by hand at every upgrade.
10
Zero or many subscribers. Oracle raises the event whether or not anything listens, and several
subscriptions can act on the same event independently. Adding a second one later requires no change to the
first.
11
Debugging. WF_DEFERRED holds queued events awaiting processing; the Workflow Administrator screens
show the event, its subscriptions and any errors. An event that fired with nothing happening is usually a
subscription that is disabled, or a deferred one whose agent listener is not running.
WF_DEFERRED
12
What the interviewer is probing.1. "Why are business events the preferred extension point?" Probing: the argument. Stalls:
"They are newer." Moves up: they are a published, supported hook — your subscription survives
patching where a trigger on a seeded table does not.
13
2. "What is the difference between a local and deferred subscription?" Probing: the detail.
Stalls: "Timing." Moves up: local runs in the raising session and delays it; deferred queues the
event for the agent listener, which protects the transaction.
14
3. "What would you use deferred for?" Probing: the judgement. Stalls: "Everything." *Moves
up:* anything slow or external — calling a web service inline makes the user wait and can fail the
transaction.
15
4. "How do you troubleshoot an event that did not fire?" Probing: the method. Stalls: "Check
the code." Moves up: whether the event and subscription are enabled, the agent listeners are
running, and WF_ERROR for failed deferred events.