In enterprise Order-to-Cash integrations, order cancellation often appears simple on the surface—but in reality, it is one of the most misunderstood flows in Oracle Fusion Order Management.
One status in particular creates confusion across integration teams: “Cancellation Requested”
Most of the time we expect to see this status in events, logs, and downstream systems,but often, it never shows up.
So what’s really happening? A Real-World Scenario.we recently worked on a common enterprise pattern:
Users create and manage Sales Orders in Custom Web based UI
Cancellation is initiated from Custom Web based UI
UI Invoke OIC integration over REST call
OIC invokes Fusion REST API to cancel order lines
OIC subscribes to Fusion Order Events to sync status back
Everything worked perfectly—except one thing: We never received an event for “Cancellation Requested” . Though this is intermediate cancel events but it was a MUST for business requirements to report it back to custom application.
What is “Cancellation Requested” Status?
“Cancellation Requested” is not a final status.It represents:
✔ A cancellation request has been accepted
✔ Orchestration has started
❗ But fulfillment tasks are still in progress
Behind the scenes, Fusion triggers multiple activities:
Cancel inventory reservation
Cancel pick/ship tasks
Reverse supply orchestration
Only after these complete does the system move to: Canceled
The Key Insight Most Teams Miss
Here’s the critical architectural reality: Fusion does NOT guarantee event publication for “Cancellation Requested”
What Events Are Actually Published?
Here’s what you can reliably expect:
If your architecture looks like:
Custom Web based UI→ OIC → Fusion REST → Event → Custom Web based UI
Then this assumption is risky: ❌ “We will get an event for Cancellation Requested”
Recommended Enterprise Design Pattern
Step 1: Handle initiation yourself
When user clicks Cancel in Custom Web based:
Update Custom Web based status:
Cancel Initiated (or similar)
👉 Do NOT wait for Fusion to tell you this
Step 2: Call Fusion via OIC (This is Important Step)
Invoke REST API to cancel lines
Capture response (success/failure) in these response you will see Status Code like DOO_CANCELLATION_REQUESTED. Send these code back to web application and set the status of Order line to Cancellation requested
Step 3: Use events only for final state
Subscribe to events for:
Cancel Pending / Canceled
Shipped
Closed
Step 4: Update final state from event
When Fusion publishes: Status = Cancel pending /Canceled. Update Custom Web application accordingly
Architecture Pattern (We Recommended)
Step 1: User (Custom Web based application )
Cancel Action
UI invoke OIC Integration
OIC integration invoke Fusion REST API (to Cancel Line)
Custom Web based → Set Status = "Cancel Initiated"
Step 2: Fusion Processing (internal)
Is Cancel Requested status is a Must to be reported in Custom Application
Yes
Read response from Fusion cancel line REST API ,
if Status Code in response is =DOO_CANCELLATION_REQUESTED then SET status in Web application Cancellation Requested.
Is Cancel requested Status is Must to be reported in Custom Application
NO
Do nothing Wait for the Line events related to cancellation ( Fusion Processing )
OIC has Event Subscription On
As soon as events related to line cancellation triggered ( Cancel Pending /Canceled) , Update Status in Custom Web Application Cancel Pending and then "Canceled".
Architecture Pattern that we have leverage .
1. Initiation and Immediate Feedback
The process begins when a user initiates a Cancel Action from a Custom Web-based application.
Step: The UI should immediately update its own status to "Cancel Initiated".
Rationale: Do not wait for Fusion to confirm this initial step; controlling the initiation state within your own system ensures the user gets immediate feedback.
2. Synchronous Integration via OIC
The Custom UI invokes an Oracle Integration Cloud (OIC) integration via a REST call, which then invokes the Fusion REST API to cancel the order lines.
Capturing the Intermediate Status: Instead of waiting for an asynchronous event (which may never arrive), the integration should read the synchronous response from the Fusion REST API.
The "Must-Have" Decision:
If reporting "Cancellation Requested" is a requirement: The integration checks the response for the status code DOO_CANCELLATION_REQUESTED. If present, it updates the Web application status to "Cancellation Requested" immediately.
If it is NOT a requirement: The system simply waits for the final line events.
3. Asynchronous Event Subscription for Final State
Fusion then performs internal processing, such as canceling inventory reservations and pick/ship tasks.
Step: OIC remains subscribed to Fusion Order Events, but only for final or major milestones like Cancel Pending or Canceled.
Final Update: Once these final events are triggered, OIC updates the Custom Web application to its final status, such as "Canceled".
4. Critical Reconciliation
The architecture emphasizes that events can be missed due to edge cases or failures.
Requirement: Always implement a scheduled sync job to reconcile statuses between the Custom Web application and Fusion to ensure data integrity.
The core of this pattern is to treat "Cancellation Requested" as an internal/transient processing state rather than a guaranteed integration event. By using the REST API response for intermediate status and events only for the final state, the architecture avoids the pitfall of waiting for a "Cancellation Requested" event that may never be published.
