A thousand partners, one server: EDI done right with ANOM

Electronic Data Interchange, EDI, is an umbrella term for the standard formats companies use to exchange business documents: purchase orders, order confirmations, despatch advice, invoices, catalogues. It has carried a large share of B2B trade for decades, and it still sits between most large buyers and their suppliers. In Europe that usually means UN/EDIFACT, often in its GS1 subset, EANCOM; in North America, ANSI X12.

It also has a reputation. Every distributor that has connected a new trading partner knows the pattern: weeks of back-and-forth over a specification, test files that fail for reasons nobody can explain, then a first production order that lands in the wrong warehouse. Why is something so old still so hard?

Trade runs on documents

Companies buy from each other, and every purchase produces documents: an order, a confirmation, a delivery note, an invoice. Each company produces and reads those documents in its own business system, an ERP, a commerce platform or a purchasing suite, and each system has its own internal format. Even two companies on the same ERP rarely share a format, because each has configured and extended it in its own way.

The oldest way to bridge that gap is a person. The buyer emails a PDF, someone at the supplier retypes it, and the supplier’s system gets an order. It works, at the cost of time, errors, and a ceiling on volume.

The next step is to connect the systems directly. That works for one partner. For fifty, it means understanding fifty formats, and maintaining fifty connections that each change on their own schedule.

What a standard solves

EDI standards remove one part of that problem. Instead of every partner’s private format, everyone writes the same syntax: segments, separated by ', made of data elements, separated by + and :. The standard also fixes where things go. In an EDIFACT purchase order, the document number is always the second element of the BGM segment, and the type of document is always the first.

That alone is a big improvement. A supplier that reads EDIFACT can read an order from any buyer that writes EDIFACT, without learning each buyer’s ERP.

What a standard cannot solve

The standard fixes the structure of a document, not the business behind it. Take the product on an order line. EDIFACT says where the product identifier goes, but not which identifier it is. One buyer sends the GTIN printed on the box, another its own internal part number, a third the supplier’s reference it copied from a catalogue three years ago. The standard does not choose. It provides a code for each of them.

So a standard like EDIFACT is less a single format than a structured dictionary of everything companies might want to say. Each buyer publishes a message implementation guide that picks the segments, codes and rules it actually uses, and those guides differ, because the companies behind them work differently. One buyer gives a delivery address per order, another per line. One sends dates as CCYYMMDD, another adds the time. One expects an order response within the hour, another only cares about the despatch advice.

That is why every new trading partner needs its own setup, and why that setup needs a person who understands the business. Mapping a field is not a guess. Confuse the buyer’s identifier (NAD+BY) with the delivery point (NAD+DP) and the goods go to head office instead of the branch that ordered them. No statistical model should be making that call on its own.

Then everything moves

Even a correct setup does not stay correct. Partners open warehouses, and every new delivery point comes with a new GLN. Certificates used to sign messages expire. A buyer changes its ERP and its interpretation of the guide changes with it. A file arrives twice. A partner’s server is down for an afternoon.

None of that is exceptional. It is the normal state of EDI. A system that handles it has to treat change and errors as routine, and make each one easy to find, explain and resolve before it costs an order.

How messages travel

EDI also needs a way to move files. There are two families. A value-added network (VAN) works like a post office: each company drops its messages in a mailbox and the network delivers them. A point-to-point connection links the two companies directly, today most often over AS2, an internet protocol that signs and encrypts each message and returns a signed receipt, the MDN.

Point-to-point removes the intermediary and its fees, but it moves the responsibility for security and proof of delivery onto the two systems themselves.

EDI in ANOM

ANOM, our back-office for Intershop, handles EDI natively. There is no separate translator to buy, host and connect. Partners are declared on the customer account they belong to, next to that customer’s prices, addresses and users, and switched on one at a time.

• Standard. UN/EDIFACT D.96A, with an optional EANCOM subset.
• Received. Purchase orders (ORDERS), sales reports (SLSRPT) and syntax acknowledgements (CONTRL).
• Sent. A syntax acknowledgement for every file received (CONTRL), the order response with the reason for any refusal (ORDRSP), despatch advice per shipment (DESADV), and the catalogue at the customer’s own prices (PRICAT).
• Transport. AS2. Every incoming message is signed, checked against the partner’s certificate and acknowledged with an MDN. A message sent counts as delivered only when the partner’s signed MDN confirms it.
• Identifiers. GS1 GLN with check-digit verification. Each delivery address carries its own GLN, and items are matched by EAN or by product reference.
• Traceability. Every message is kept exactly as received or sent, fingerprinted and unalterable, with its status from receipt to delivery.

CONTRL appears on both sides because it works in both directions: each side confirms, file by file, that what it received is syntactically valid. ANOM sends one for every file a partner sends, and reads the ones the partner returns for ours.

Every partner’s setup lives in one place, on its access: the EDIFACT directory and subset, the character set, both parties’ identifiers, the AS2 certificate and address, test or production. Each setting is validated as it is entered. When a partner changes, its access switches to test mode, the change is checked end to end with the simulator, and the log, which keeps every message exactly as it arrived, shows precisely what the partner now sends.

Because the EDI engine lives in the same back-office as the catalogue and the price lists, an incoming order is checked against the real data: the customer account, its delivery points and the catalogue. A problem comes back to the partner as a precise refusal in the ORDRSP, not as a silent rejection three days later.

A simulator in the back-office

The slowest part of any EDI project is testing with the partner. Their team has its own priorities, test windows are short, and every round trip takes days.

So ANOM ships with its own simulator. It plays the partner’s side: from the back-office, you enter a purchase order by product reference, and the simulator sends it over AS2 exactly as the partner’s system would. The acknowledgement and the order response go back to the simulated partner, and every exchange lands in the log. When the order ships, the despatch advice is sent from the log.

Each partner access also has a test mode. Messages go through the same checks as in production and carry the test flag in their envelope, and no order is created, so nothing reaches the warehouse or the invoice until the partner goes live.

In practice, that changes the order of the work. Identifiers, delivery points, product references and acknowledgements are validated against the simulator before the first call with the partner’s EDI team. When a partner announces a change, its access goes back to test mode and orders are sent again before production. And the business team can see what an EDI order will look like in ANOM before any real one arrives.

Built to scale

A purchase order from a buying group can carry a thousand lines, and a busy Monday morning brings orders from many partners at once. We measured how much the EDI engine can take, on synthetic data: UN/EDIFACT D.96A orders in the EANCOM subset, from invented partners, with GS1 identifiers that have valid check digits but belong to no real company.

Two measurements cover the EDI engine itself. Read: the message is parsed, checked against the D.96A grammar and turned into a structured order. AS2 exchange: the full inbound path of the AS2 endpoint, from receipt to receipt. The partner is identified, the message is decrypted, its signature verified against the partner’s certificate, the order read, and a signed MDN returned.

A thousand-line order is read in under 5 milliseconds, and fully absorbed over AS2, signature and receipt included, in about 7. Small orders are faster still: a one-line order is read in 0.05 milliseconds. Up to a hundred lines, the AS2 layer (decryption, signature check, signed receipt) adds about 1.3 milliseconds, and about 2 for a thousand-line order.

Larger orders carry more lines per second: the cost of opening a message is paid once, then every line is cheap. A single partner sending thousand-line orders over AS2 gets 137,000 lines per second through.

What matters more is what happens when partners send at the same time. Each message is handled on its own, so partners do not wait behind each other in a single queue, and throughput grows with the number of cores.

With twelve partners sending at once, a single instance reads 14,300 orders per second, about 1.4 million order lines per second, and absorbs about 3,800 AS2 exchanges per second: 7.7 and 7.0 times the single-partner figures. The step from 8 to 12 partners is smaller because the last four cores of the test machine are efficiency cores. Processing adds less than 300 MB of memory in every Read and AS2 scenario with orders of up to 100 lines.

From receipt to order

A third measurement, Complete order, follows an inbound order through everything ANOM does with it in production. A separate load generator sends signed, encrypted AS2 messages to the real HTTP endpoint of the server. Each message is decrypted and its signature verified. It is recorded in the message journal, read and checked: syntax, sender, every line matched to a product by EAN, the delivery place by GLN. The order is created. A signed MDN is returned, and a CONTRL acknowledgement and an ORDRSP order response are built, signed, encrypted and really sent over HTTPS to a simulated partner, which verifies them and returns its own signed MDN. Everything is written to the database, configured exactly as in production. Each measurement is then checked in the database: one order per message, every response sent, no errors.

A single partner gets about 270 complete orders per second through, and twelve partners sending at once about 520. Order size matters little: a ten-line order costs about 15% more than a one-line order, and a hundred-line order, with a hundred times the lines, less than three times as much. Orders that arrive together are written to the database together, in a single write, while an order that arrives on its own never waits for others.

These figures are conservative. The partner is simulated on the same machine and takes about a third of its CPU, decrypting and checking our two responses and signing its receipts. In production, that work runs on the partner’s systems.

How it was measured. One instance on an Apple M4 Pro (12 cores: 8 performance, 4 efficiency). Messages are written, signed and encrypted before the clock starts, as the partner would do on its side. In Read and AS2 exchange, each message is timed individually. Read and AS2 exchange cover the engine itself, from receipt to the structured order or the signed receipt. Complete order runs through the real HTTP endpoint with an external load generator, and adds the message journal, the order checks, order creation, and the acknowledgement and order response sent over HTTPS, on a database configured as in production. All of it runs on one machine, so transit over a real network sits outside these measurements. Steady-state figures only. The first message after start-up, a one-off warm-up of 7 to 16 ms, is left out.

What it means for your business

Peak season, a new buying group, a hundred stores opening at once: EDI volume never grows gently, and every new trading partner adds to it. So we turned the measurements into the two numbers that matter when you plan: how many trading partners one server can take, and how many orders a day.

A thousand trading partners, or ten thousand: with ANOM, connecting them is a question of setup, not of capacity. If EDI with your customers is on your roadmap, we would be glad to show you ANOM on a demo tenant.

Further reading

This article owes its structure to two pieces we recommend reading in full:

• What makes EDI so hard?, Stedi, 2022.
• Mastering Electronic Data Interchange, Unimedia Technology, 2024.

For the standards themselves:

• UN/EDIFACT directories, UNECE.
• EANCOM, GS1.