IDEMPOTENCY

The property of a process to produce the same result — with no side effect — regardless of how many times it is executed with a given request.

Definition

Idempotency is defined by RFC 9110 (HTTP Semantics, June 2022) as: "a request method is considered idempotent if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request".

In EDI, idempotency is not natively guaranteed: if an AS2 sender does not receive its signed MDN within timeout, it retransmits the message. If the receiver did handle the first copy but its return MDN was lost, the application receives the same order twice — and risks duplicating it. Three common techniques to make an EDI chain idempotent:

1. Identifier-based deduplication: a unique identifier carried by the message (BGM in EDIFACT, BEG03 in X12, ID in UBL, Message-ID in MIME). The receiver maintains a {`identifier, first processing`} table and rejects or ignores duplicates.
2. Content hash: compute a SHA-256 hash of the canonicalised content. Two identical messages yield the same hash, so the receiver knows it has already processed.
3. Transition state: the business operation only commits once locked by identifier + expected state. A second transition attempted for the same identifier is rejected.

Origin

The term "idempotent" comes from mathematics (Benjamin Peirce, 1870): an operation f is idempotent if f(f(x)) = f(x). The concept was picked up in computer science by the first distributed protocols (CCITT X.25 in the 1970s, Sun ONC RPC in the 1980s), then by HTTP/1.1 (RFC 2616, 1999) which formally distinguishes idempotent methods (GET, PUT, DELETE) from non-idempotent ones (POST, PATCH). In EDI, idempotency became an industrialisation requirement as volumes grew and automatic retransmissions became standard — typically AS2 retry and OFTP2 restart-at-offset.

Example in context

A supplier sends an INVOIC to a customer. The customer receives, processes, but its AS2 MDN does not come back (network timeout). The AS2 sender automatically retransmits after 60 minutes. The customer receives the same file a second time. If the system is idempotent — deduplication by BGM/1004 (invoice number) coupled with supplier DUNS — INVOIC F-2026-0512 is recognised as already received, a new signed MDN is emitted, but no accounting entry is duplicated.

Related terms

• Acknowledgement — the element that triggers retries.
• MDN — the AS2 acknowledgment whose loss causes retransmits.
• Audit trail — the log that makes deduplication auditable.
• BGM — carries the natural identifier of an EDIFACT message.