An integration is not finished when the record arrives. It is finished when somebody can tell you, without opening either system, that the two sides still agree, and what happened to the eleven records that did not make it last Tuesday.
Interfaces are judged on their failure behaviour, not on the happy path.
Batch, event or request, decided per interface before anyone picks middleware.
EBS, Fusion and the database layer supported by the same firm, with in-house Oracle expertise.
Every interface has a failure path, a retry policy and a named owner.
A scheduled check that the two systems still agree, reported whether or not it passed.
The design work is mostly deciding which pattern each interface is. Get that wrong and no amount of middleware rescues it.
Each interface classified before it is built: batch, near-real-time event, or synchronous request. Volume, latency tolerance and failure consequence decide which.
Most integration pain comes from a synchronous call doing a job that should have been a queued event, usually because it was quicker to write.
A pattern chosen on purpose.
Quote to cash, customer master, product and pricing, invoice and payment status, into Oracle E-Business Suite, Fusion, or whatever the finance system happens to be.
We support the Oracle side of these interfaces in-house, which removes the usual argument about which end the fault is on.
One firm accountable for both ends.
MuleSoft where it is already in the estate or genuinely warranted, platform events and the Salesforce APIs where it is not, and a plain answer about which this is.
Middleware licensed for one interface is a cost that outlives the reason for it.
The lightest thing that does the job.
Dead-letter handling, retry with backoff, idempotent writes so a replay does not duplicate, and alerting that names the interface and the owner.
An interface with no failure path has one anyway. It is called silence, and you find it at month end.
Failures that announce themselves.
A scheduled comparison of the record sets either side, reported on a cadence whether or not it found a discrepancy.
This is the part that gets cut for time and the part that would have caught the problem three weeks earlier.
Evidence that the two sides agree.
API consumption watched against the org limits, with headroom reported before it becomes an outage rather than after.
Governor and API limits are the failure mode that arrives suddenly, usually on the busiest day.
Headroom you know about in advance.
How an interface gets built
Chosen per interface at design time. Most estates end up with a mixture, and that is correct.
| Pattern | Use it when | Typical mechanism | Failure behaviour |
|---|---|---|---|
| Scheduled batch | Volume is high and same-day is good enough | Bulk API, scheduled job | Whole run retried, exceptions reported |
| Event driven | The other system should react promptly but not block | Platform events, change data capture | Queued and replayed, order preserved |
| Synchronous request | The user is waiting and cannot proceed without an answer | REST callout | Fails fast with a message the user understands |
| Outbound notification | A simple trigger is enough and payload is small | Outbound message, Flow | Retried by the platform, then dead-lettered |
| File transfer | The far end is legacy and offers nothing better | Secure file drop, scheduled load | Checksum and row count checked before load |
The usual integration argument is which side the fault is on, conducted between two suppliers who each have a reason to say it is the other one.
We support Oracle E-Business Suite, Fusion and the database layer in-house with in-house Oracle expertise, so for most finance and ERP interfaces there is one firm accountable for both ends and no argument to have.
Talk to an expertScope and targets are set after discovery, against the org as it stands.
Often not. If it is already in the estate and paid for, we will use it. If it would be bought for this project, we will tell you plainly whether the interface count justifies it, because middleware licensed for two interfaces is a cost that outlives the reason for it.
Yes, and we support the Oracle side as well, with in-house Oracle expertise. That is the practical difference on finance interfaces: no argument about which end the fault is on, because it is the same firm on both.
They are a design input, not something to discover later. Consumption is estimated during design, monitored in production, and reported against the limit with headroom stated. A batch pattern often exists specifically to stay inside them.
It goes to a dead-letter position, raises an alert naming the interface and the owner, and appears on the reconciliation. It does not sit in a log nobody reads, which is the usual arrangement and the reason month end is a surprise.
Or the fact that there isn't one. Either way the first piece of work is agreeing which system wins on conflict, and that conversation is cheaper now than at month end.