Aadhib

Case study · Active

Integrating SAP Ariba using strict cXML validation

Enterprise B2B protocols do not forgive. Why validation moved before transmission, and what a push history is actually for.

Role
Architecture and delivery
Published
Reading time
1 min
cXML 1.2.033XML validationSAP Ariba
01

Context

Supplier visibility into a large procurement network means transmitting structured documents on a schedule, in a format the network defines. In this case that format is cXML — a mature, versioned, schema-driven XML protocol that predates the conventions most web developers work with daily.

02

Problem

Engineers arriving from REST expect a forgiving counterparty: descriptive error bodies, tolerant parsing, a sandbox to iterate against. cXML offers none of that. A document conforms or it is rejected, the rejection is terse, and you are not experimenting against a live procurement network to find out why.

03

Constraints

01
The schema is not negotiable
cXML 1.2.033 is a specific contract. There is no version of this where approximately correct XML is accepted.
02
Feedback is poor and slow
A remote rejection tells you far less than a local validation error, and arrives much later.
03
You cannot iterate in production
The counterparty is a live procurement system. Trial and error is not an available debugging strategy.
04
Failures are investigated late
Nobody notices missing supplier data immediately. By the time someone asks, the transmission was weeks ago.
04

Approach

I moved every check that can happen locally to before transmission, and made the document itself the visible unit of work. I generate the cXML, validate it against the expected structure locally, let a human see the exact payload before it is sent, and record every transmission with its response so that a question asked in three weeks is still answerable.

05

Architecture

Inventory and manufacturing dataSource data from internal systems.
cXML generationProductReplenishmentMessage documents built to the 1.2.033 contract.
Local schema validationConformance checked before anything is transmitted — the step that turns remote rejections into local errors.
Preview and transmissionExact payload visible to a human, then sent.
Push historyDurable record of every document and its response.
06

Solution

A connector that treats document validity as its primary responsibility. Validation before transmission, an XML preview so the payload is inspectable rather than inferred, a complete push history for after-the-fact diagnosis, and role-based access because sending documents into a procurement network is a consequential action.

Why REST habits mislead here

REST APIs are built to be developed against. They return helpful errors, they tolerate extra fields, they usually offer a sandbox. Those affordances teach a working style — send it and read the error — that is actively harmful against a strict protocol with a terse rejection and no test environment.

The adjustment I had to make was to front-load correctness rather than discover it.

The feature that earns its keep quietly

Push history. It does nothing for the happy path and it is the only reason a question like "did the December data actually go" has an answer.

07

Lessons

  1. 01Enterprise integration is a document problem, not an API problem. Once you think in documents, validation, preview and history become the obvious three features.
  2. 02Every check you can perform locally is worth several you perform remotely. The feedback loop is the whole difference between an afternoon and a fortnight.
  3. 03Build the audit trail before you need it. Integration failures are always investigated after the fact, and the data you did not keep is the data you needed.
  4. 04Protocol versions are load-bearing. Treating them as a detail is how integrations break silently a year later.

Stack

What it runs on

Protocol
cXML 1.2.033ProductReplenishmentMessage
Safeguards
Schema validationXML previewPush history

The project

01SAP Ariba cXML connector
All case studies