Technology Services · System Integration
System integration: APIs, middleware and syncs that hold up.
APIs, middleware and scheduled synchronization between the systems your business runs on: ERP, eCommerce, sales tools, warehouse applications and third-party services.
- Interfaces
- Whatever the far system actually supports: REST, SOAP, files, database views, message queues
- Never
- Two systems wired directly to each other. There is always a layer, so one change stays one change
- Handed over
- A field mapping, the retry rules, monitoring and a runbook, so your team can operate it
One message, five checkpoints
Where an integration actually dies
Each stage has a characteristic failure, a symptom the business recognises long before anybody looks at a log, and a guarantee that prevents it.
01
Accepted
The source system hands us a message and we take responsibility for it.
Where it goes wrong
We accept it and lose it, because it lived only in memory while something restarted.
What the business sees. An order that exists in the webshop and has never existed in SAP Business One. Found by a customer, usually.
The guarantee we build. Durable before acknowledged. Nothing is confirmed to the sender until it is written somewhere that survives a restart.
02
Validated
The message is checked against what the destination will actually accept.
Where it goes wrong
It is passed through unchecked and rejected downstream, where the error message is about a field code nobody recognises.
What the business sees. A queue of failures with messages like 'Invalid BP code' and no indication of which order they belong to.
The guarantee we build. Validation happens at the edge, in the sender's vocabulary, and a rejection names the record, the field and the reason.
03
Transformed
Fields, units, currencies and identifiers are mapped from one system's model to the other's.
Where it goes wrong
The mapping is right for the data that existed on the day it was written. Then a new item category appears.
What the business sees. Most records fine, a handful wrong, discovered weeks later during a stock reconciliation.
The guarantee we build. Unmapped values stop the record rather than guessing a default, and the mapping lives in one place that can be read without a developer.
04
Delivered
The destination accepts the message and commits it.
Where it goes wrong
The network drops after the write but before the acknowledgement, the sender retries, and the order exists twice.
What the business sees. Duplicate orders, duplicate invoices, and a credit note conversation.
The guarantee we build. Every message carries an identity the destination remembers, so a retry of the same message is recognised rather than repeated.
05
Confirmed
The result travels back to the source and the message is closed out.
Where it goes wrong
Nothing travels back. The integration is 'working' because nobody has proved otherwise.
What the business sees. The worst one. There is no symptom until a number is wrong and there is no way to tell when it started.
The guarantee we build. A reconciliation that counts both sides on a schedule, and an alert when the counts disagree, not when a process crashes.
Delivered with the code
The manifest
An integration is not finished when data moves. It is finished when your team can operate it without calling us, and these five artifacts are what makes that true.
If you would rather we operated it- 01
Field mapping document
Every field, both directions, with the transformation and the unmapped cases. Readable by somebody who is not a developer, because the person who settles a mapping argument usually is not one.
- 02
Error handling and retry rules
Which failures retry, how many times, how far apart, and which stop immediately and raise. Written down so nobody has to infer it from behaviour.
- 03
Monitoring and alerting
What moved, what failed, what is queued, and who gets told. An integration nobody can see is an integration nobody trusts.
- 04
A runbook for your team
The five things that go wrong, what each looks like, and what to do. Written for whoever is on shift, not for whoever built it.
- 05
A reconciliation
A scheduled count of both sides that proves the two systems still agree. The only real evidence an integration is working.
Decided per interface
Event-driven or scheduled?
Not a philosophy. A property of each individual flow, and the same integration usually contains both.
Event-driven
- When it is right
- The other side needs to react, and a delay has a cost. An order placed in the portal, a shipment confirmed, a payment captured.
- What it costs
- More moving parts. Needs a queue, needs retries, and needs somebody watching it.
Scheduled batch
- When it is right
- Volume is high, the data is a set rather than an event, and an hour old is fine. Catalog, price lists, cost updates, nightly extracts.
- What it costs
- Simpler and far easier to reason about. The trap is running it hourly when the business needed it immediately.
The question that settles it is not technical. It is what the business does differently if the number is an hour old.
Scope
What we integrate, and how
- 01
API integration
REST and web API connections between systems, with authentication, rate limits and versioning handled properly.
- 02
Custom middleware
A service that sits between systems, transforms data, logs every transaction and retries failures.
- 03
Scheduled synchronization
Timed jobs for catalog, pricing and document data where batch is the sensible choice.
- 04
Database integration
Controlled read access for reporting and feeds; writes only through supported application interfaces.
- 05
File-based exchange
CSV, XML and flat-file exchanges with partners who cannot integrate any other way.
- 06
Monitoring and alerting
Dashboards and alerts so a failed sync is known within minutes, not at month-end.
What sits on the ends
The systems we connect
- CoreSAP Business OneThe system of record everything else reads from and writes to.Overview
- Layer 01B2B eCommerceCustomers who order themselvesA portal with their pricing, live stock and account history. Orders arrive as SAP Business One sales documents.See it
- Layer 02Sales Rep AppCustomers who need a visitReps carry pricing and stock on the route, work with no signal, and sync orders when they reconnect.See it
- Layer 03Inventory CountingMaking the stock figure trueBarcode counts and cycle counts, with variances reviewed before anything posts to the ledger.See it
- Layer 04Price Label PrintingThe shelf edgeLabels generated from the same item and price data, so what is on the shelf matches the invoice.See it
Questions
About integration work
Next step
Describe the problem. We will tell you what it takes to solve it.
Send a few lines about the process or system you are dealing with. We come back with questions, options and a realistic sense of effort.