Series: Oracle APEX in Fusion Implementations — Part 2 of 4 Published under: Oracle APEX | Oracle Fusion | OIC | Solution Architecture
In Part 1 of this series, we laid out the case for Oracle APEX as a deliberate architectural layer in Oracle Fusion implementations — handling the user experience that standard Fusion UI can't deliver cleanly. In this post, we go deeper on one specific build: a custom Sales Order creation UI that we deployed for a distribution company running Oracle Fusion Order Management.
This post is about the decisions. Why we structured it the way we did, what we got right, and what we'd approach differently today.
Watch short video at our you tube channel : https://tinyurl.com/mr2ma8vn
The Starting Point: What Was Actually Broken
The client was a mid-size distribution company, around 800 employees, with a sales team of 40+ people entering orders daily into Oracle Fusion Order Management. The Fusion implementation was solid — modules configured correctly, data clean, integrations running.
The problem was the screen.
Fusion's standard order entry UI is genuinely comprehensive. It's built to support every order management scenario for every type of company Oracle sells to. For this client, that meant a screen with tabs their team never opened, fields they didn't use, and a workflow designed around maximum flexibility rather than their specific process.
Onboarding a new salesperson took two full days of training just for order entry. Error rates on submitted orders were high enough that the operations team had a standing process for catching and correcting them before fulfillment. Senior salespeople had workarounds — personal checklists, order templates maintained in spreadsheets — because the system alone wasn't enough.
The ask was straightforward: make order entry simpler, faster, and more accurate. The solution we chose was APEX.
The Architecture: Three Layers, Three Responsibilities
Before writing a single line of code, we spent time on one question:
This sounds obvious but it's where custom UI projects go wrong. Teams build an APEX screen and, wanting to be efficient, write directly to Fusion tables, or skip the integration layer to "simplify" things, or put business logic in the UI that should live elsewhere. The result is a system that works today and is a maintenance problem tomorrow.
We drew a hard line:
[ APEX ] → [ OIC ] → [ Oracle Fusion Order Management ]
UX layer Integration System of Record
Each layer has one job:
APEX owns the user experience — data capture, presentation, validation against business rules, user feedback, audit logging at the application layer.
OIC owns the integration — receiving a clean payload from APEX, transforming it to the Fusion Order Management API contract, handling retries, and returning a structured response.
Fusion owns the data — every order lands in Fusion through its published REST API, exactly as if it had been entered natively. No direct table writes. No bypassing of Fusion's own logic.
This separation isn't just architectural principle. It has practical consequences:
If the Fusion Order Management API changes in a future release, only the OIC integration needs updating — not the APEX UI.
If the business wants to trigger order creation from a different system later (a portal, a mobile app, an EDI feed), the OIC integration is already reusable. It doesn't know or care that it was called from APEX.
If something goes wrong, each layer has its own observable log. Troubleshooting is systematic, not a hunt through a monolithic application.
The APEX Layer: What We Built and Why
Role-Specific Screen Design
The first decision was what to show. We worked with the sales team to map every field on the standard Fusion order entry screen to one of three categories: always needed, sometimes needed, and never needed for their business.
"Never needed" fields were removed entirely. "Sometimes needed" fields were hidden behind a clear "Additional Options" section that defaulted collapsed. The main screen showed only what the user needed to complete a typical order — customer, order type, requested date, line items, and delivery details.
This sounds simple. It cut training time in half before we'd written a single validation.
Validation Before Submission — The Core Value
The real leverage in the APEX layer was validation. In the standard Fusion flow, certain errors only surfaced after submission — a credit hold, a pricing discrepancy, an item that had been discontinued. The user submitted, the order hit a processing exception, and operations had to intervene.
We moved those checks to the APEX layer:
Credit limit check: On customer selection, APEX queries a view that surfaces the customer's current credit exposure from Fusion. If an order would push them over their limit, the user sees a warning immediately — with the option to flag it for approval rather than abandoning the order.
Item availability: On line item entry, APEX checks current on-hand inventory against a scheduled job that refreshes every 15 minutes from Fusion. Not real-time, but current enough to catch the most common errors before submission.
Pricing validation: The client had complex pricing rules — customer-specific agreements, volume breaks, promotional overrides. We exposed a lightweight pricing check via OIC that returned the expected unit price for a given customer/item/quantity combination. If the entered price deviated beyond a configured threshold, the user was flagged before submission.
None of these validations replaced Fusion's own processing. If something slipped through — a pricing change that happened in the 15-minute window, for example — Fusion would still catch it. But in practice, the APEX validations eliminated the overwhelming majority of submission errors.
The Submission Flow
When the user submits the order, APEX does the following in sequence:
Performs a final validation pass across all required fields and business rules.
Assembles a JSON payload matching the OIC integration's expected input structure.
Calls the OIC REST endpoint via APEX_WEB_SERVICE, passing a Bearer token retrieved from a token management package (more on this in a future post on integration security).
Receives the OIC response — either a Fusion order number on success, or a structured error message on failure.
Writes the full submission record to an APEX audit log table: user, timestamp, payload sent, response received, status.
Presents the outcome to the user — either confirmation with the Fusion order number, or a clear error message with enough detail to understand what happened.
Step 5 — the audit log — was a design decision we made early and have never regretted. The operations team now has a searchable, complete history of every order submission attempt from the APEX UI, independent of Fusion's own order history. It's been used for troubleshooting, for compliance questions, and once for a billing dispute where a customer claimed an order was never submitted. It was. We had the timestamp and payload to prove it.
The OIC Layer: Keeping It Clean and Reusable
The OIC integration for this use case is deliberately narrow. It receives a JSON payload from APEX, maps it to the Oracle Order Management REST API contract, submits the order, and returns a response.
A few design choices worth noting:
No business logic in OIC. All validation and business rule enforcement happens in APEX before the OIC call is made. OIC's job is transformation and delivery, not decision-making. This keeps the integration testable and maintainable.
Structured error responses. Rather than passing raw Fusion API errors back to APEX, the OIC integration catches error responses and returns a normalized structure: an error code, a human-readable message, and the original Fusion error detail for logging. APEX uses the human-readable message for the user and logs the full detail.
Token management handled upstream. The APEX layer retrieves a valid Bearer token before calling OIC. The integration itself doesn't manage authentication state — it receives a valid token and uses it. This keeps authentication logic centralized and auditable.
What We'd Do Differently
Three things we'd approach differently on the next build:
1. Involve the operations team earlier in defining the audit log. We designed the audit log for the sales team's use case. Halfway through UAT, operations had additional requirements — they wanted the log queryable by fulfillment status, not just submission status. The structure needed modification. Not a crisis, but an avoidable rework.
2. Build the pricing check as a synchronous call from day one. We initially estimated the pricing check would be too slow for inline validation and built it as a pre-submission step instead. In testing, the OIC call averaged under 400ms — fast enough for inline feedback. We rebuilt it. The user experience was noticeably better. We should have tested the latency earlier.
3. Design the "Additional Options" section with future requirements in mind. Within three months of go-live, the business had five new fields they wanted added. Two of them naturally fit in the main form. Three were genuinely edge-case. We had to restructure the "Additional Options" section because it wasn't built with extensibility in mind. A more modular approach upfront would have made that change trivial.
The Outcome
Six months post go-live:
Order entry time down approximately 60% compared to the standard Fusion UI
New salesperson onboarding for order entry: two days to two hours
Submission errors requiring operations intervention: reduced by over 80%
Audit log entries: over 14,000 orders captured with full payload history
Fusion didn't change. The data model didn't change. The integration didn't change. What changed was the front door — and that turned out to matter more than anyone expected at the start of the project.
What's Next
Part 3 of this series covers the OIC Integration Monitoring Dashboard — building an APEX-based control center that gave business users full visibility into integration status, one-click manual triggers, and failure alerting, without ever opening the OIC console.
That project introduced some interesting architecture questions around token management, API pagination, and how to surface technical integration state in a way non-technical users can act on. We'll walk through all of it.
Have a Fusion implementation with a growing "not possible" list? Reach out — we're happy to look at your specific situation.
Also in this series:
Part 1: Why Oracle APEX Belongs in Your Oracle Fusion Implementation
Part 3 (coming): OIC Monitoring Dashboard — Integration Visibility Without the Console
Part 4 (coming): When NOT to Use APEX — and What to Use Instead
Tags: Oracle APEX | Oracle Fusion Order Management | Oracle Integration Cloud | OIC | REST API | Solution Architecture | Low-Code | ERP | Digital Transformation
