Oracle Fusion Technical: Reports, Data, Integrations and Extensions · Module 10 · REST and SOAP: calling Fusion, and being called
Fusion calling out: business events
Lesson 105 of 177 · 2 min
A business event lets Fusion tell another system that something happened, rather than that system polling to find out. The argument for events is not elegance, it is load and latency. A poller asking "anything new?" every five minutes makes hundreds of calls a day, almost all of which return nothing, and still finds out up to five minutes late. An event fires once, when it matters. WHAT IS PUBLISHED AND WHAT IS NOT is the constraint to check first. Fusion publishes events for many objects and not all of them, and the coverage differs by module. Check for the specific event before designing around it — the same discipline as Lesson 1, and the same failure if skipped. An event tells you something happened; it does not carry the whole record. The usual pattern is event plus callback: the event names the object and its id, and the receiver…
The full lesson is part of the course
The video, the complete written lesson and the module quiz are included in Oracle Fusion Technical: Reports, Data, Integrations and Extensions, with a certificate on completion and a fourteen-day refund window.
In this module: Module 10 · REST and SOAP: calling Fusion, and being called
- 1What Fusion exposes, and what it does not
- 2REST vs SOAP: choosing without arguingFree preview
- 3Authentication and the service account
- 4Reading the REST API catalogue
- 5Your first call, and its error
- 6Payloads, child resources and partial updates
- 7Bulk operations and rate limits
- 8Fusion calling out: business events
- 9Idempotency and retries
- 10Versioning and surviving a quarterly update
- 11What breaks: five integration failures
- 12Lab briefing · Read, write and break an integration