SAP Integration Suite on BTP
Cloud integration, API management, event mesh and the design patterns that keep a BTP landscape maintainable.
Integration
Interfaces that hold up on the worst day of the month.
Integration is judged on period close, not on a demo. We work across SAP Integration Suite on BTP and existing PI and PO landscapes, including the migration between them, and we build error handling as a first-class part of the design rather than an afterthought.
Integration Suite and PI/PO
We work in both, including the migration path from one to the other.
Tested under real volume
Interfaces proved at peak load, not at demo load.
Errors surface, not vanish
Monitoring and reprocessing designed in, so a failed message is visible.
The problem
Interfaces fail quietly, and then all at once.
Most integration problems are not connectivity problems. They are design decisions that hold at low volume and stop holding at the exact moment the business needs them.
Point-to-point sprawl
Every direct connection is fine on its own. Fifty of them mean no one can change a system without breaking something they have never seen.
Volume was never tested
An interface proved on a hundred records behaves differently on a hundred thousand, and period close is where you find out.
Failures are invisible
Without monitoring and a reprocessing path, a failed message is discovered by a user asking why a number is wrong.
PI and PO with no forward path
Existing middleware still works, but sitting on it indefinitely without a plan turns a technical decision into a deadline.
An interface is not finished when the message arrives. It is finished when a failed message tells someone.
Our test for every integration
What we do
What we integrate, and with what.
Both toolsets, because most real landscapes are mid-transition rather than cleanly on one or the other.
PI and PO landscapes
Support, enhancement and optimisation of existing Process Integration and Process Orchestration, including the assessment for moving off it.
PI/PO to Integration Suite migration
Interfaces assessed, prioritised and moved in waves, with both running in parallel until each one is proved.
API design and management
Well-shaped, documented and versioned APIs, so the next system to connect does not require a new project.
Third-party and legacy connectivity
Manufacturing systems, warehouse systems, banks, portals, e-invoicing platforms and whatever else the business genuinely runs on.
Monitoring and error handling
Alerting, dashboards and a reprocessing path, so a failed message becomes a task rather than a mystery.
How it runs
Five stages, and load testing is not optional.
The stage most often skipped is the one that decides whether the interface survives period close.
- 1
Map
Every existing interface catalogued: what it moves, how often, who depends on it and what happens when it stops.
- 2
Design
Patterns chosen deliberately, with error handling, retry and reprocessing designed in from the start.
- 3
Build
Developed on Integration Suite or the existing platform, with documentation written as part of the work.
- 4
Prove
Tested at realistic peak volume, including failure scenarios, before anything goes near production.
- 5
Monitor
Alerting and dashboards handed over, so support sees a problem before a user reports one.
Who this is for
This is the right page if any of these are true.
- Period close is when your interfaces cause the most trouble.
- You are on PI or PO and have no decision yet about what comes next.
- Nobody has a current list of what is connected to what.
- A failed message is usually found by a user rather than by a monitor.
- You are adding a system and every previous addition took longer than planned.
What this does not do
Integration will not fix a broken process. If two systems disagree because the process is ambiguous, an interface simply moves the disagreement faster.
We will also push back on connecting a system that should be retired instead. Building an interface to a system you are about to switch off is work nobody should pay for.
Often bought with
These usually come up in the same conversation.
Start with the interface map.
Most teams cannot produce a current list of what is connected to what. Building that list is short, cheap, and usually the most useful thing we do in the first month.