Let's talk

SAP

Hire SAP Integration Consultants

Consultants for the interfaces around SAP — Integration Suite, CPI, PI/PO, IDoc, and the reconciliation that proves they worked.

Interfaces are where an SAP programme loses money without anyone noticing. A broken interface that throws an error gets fixed the same morning. An interface that silently posts the same goods receipt twice, or drops a status update because a mapping expected a field that was optional, is found in a stock reconciliation six weeks later — and by then nobody can say which of the two thousand documents are wrong.

The design question is never only how the message gets across

So the design question is never only how the message gets across. It is what happens on the second delivery. Middleware retries. Operators reprocess failed batches. A timeout that was actually a successful post looks identical to a failure from the sending side. Every one of these replays the document, and an interface with no notion of having seen it before will duplicate it. Idempotency — a business key checked before posting, and a defined answer for what the caller is told the second time — is the difference between an interface and a liability.

Idempotency in this context means that processing the same document a second time leaves the system in the same state as processing it once, and tells the sender so. That is a design property, agreed before the iFlow is built. It cannot be added convincingly afterwards, because by then there is production data that may or may not already be doubled.

Who fixes it at eight in the morning

The second question is who fixes it at eight in the morning. A great deal of SAP integration error handling is designed for the team that built it: a monitor nobody outside basis can read, a message that says a mapping failed without saying which document failed it. If someone in operations cannot see what is stuck, what it was for, and what happens if they release it, the interface will be escalated every time rather than handled.

We staff people who have supported interfaces as well as delivered them, because the two jobs teach different things and only one of them teaches this.

Integration Suite, CPI or PI/PO matters less than the estate suggests

Most organisations we are asked about are somewhere in the middle of a migration: PI or PO still carrying the interfaces nobody wants to touch, Cloud Integration carrying the newer ones, and a handful of point-to-point IDoc connections that predate both and work perfectly.

The tooling choice is real but it is second-order. What determines whether the landscape is supportable is whether the interfaces share conventions — the same approach to keys, the same error semantics, the same monitoring, the same idea of what a retry means. A landscape with three tools and one convention is easier to run than one with a single tool and eleven styles, and the second is far more common.

How a silent gap is found before finance finds it

An interface that has stopped running does not usually announce itself. The sending system keeps sending, the queue keeps accepting, and the receiving system simply stops changing.

The countermeasure is dull and it works: a scheduled comparison of counts and control totals on both sides of every interface, over a window long enough to allow for timing, with an alert on the difference rather than on the error. That is a day of work per interface and it converts a six-week discovery into a next-morning one. Very few estates have it, which is why the reconciliation break is such a reliable feature of enterprise landscapes.

When you do not need this role

A single interface between two systems, with low volume and a clear owner on each side, does not need a dedicated integration consultant. It needs whoever owns the receiving system to build it and to be honest about redelivery.

Nor is this the right hire when the actual problem is that nobody has agreed what the data means. Two systems disagreeing about what counts as an active customer is not an integration defect, and building a mapping over it moves the disagreement rather than resolving it. That work belongs with a functional analyst first.

The role earns its place where the number of interfaces has passed the point at which any one person holds the landscape in their head, or where a reconciliation break has already happened and nobody can yet say which documents it affected.

Teams are built for companies in the United States and the Gulf — the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman. The engineers are in Pune, which matters mostly for the clock. Dubai is ninety minutes behind us and Riyadh two and a half hours, so a Gulf team shares almost the whole working day. New York is nine and a half hours behind, so American engagements run on a written handover and one fixed overlap window rather than on a standing call — a real constraint, and better stated than discovered.

What these engineers do

  • SAP Integration Suite and Cloud Integration iFlows, and PI/PO where it is still in place
  • IDoc, BAPI, RFC and OData interfaces, inbound and outbound
  • Idempotent inbound processing, so a replayed document does not post twice
  • Error handling an operations person can work through, not only a basis team
  • Reconciliation and monitoring that catches a silent gap before finance does

Delivered AI-first

Consultants use AI assistance to map an undocumented interface landscape, summarise mapping logic inherited from a previous supplier, and draft the test cases for each failure path. The failure analysis and the design decisions remain the consultant's.

Tell us what the SAP Integration work is.

Roughly what it involves, the seniority you need, and when it has to start. We will say what it takes to staff it, or say honestly that we are not the right people for it.

A person reads every enquiry and replies within one working day.