Message Endpoint

The connection point between business code and the EDI messaging system — the abstraction layer that makes AS2/AS4/SFTP interchangeable.

Problem

A business application (ERP, OMS, TMS) needs to exchange with a partner via an EDI protocol. How to avoid having the business code depend on protocol details (AS2 URL, X.509 certificates, AS4 SOAP options)?

Forces

• EDI protocols evolve: OFTP → AS2 → AS4; business code must not be rewritten at each migration.
• Several partners may demand different protocols — the same ORDERS message must go via AS2 to one and SFTP to another.
• Security skills (X.509, mTLS, OCSP) must not pollute business code.
• Retries, timeouts, idempotency must live in one place, not be scattered.

Solution

Introduce a Message Endpoint class (or dedicated service) that exposes to the business a simple API — sendOrder(order), receiveInvoice() — and that internally encapsulates the protocol: serialisation, encryption, retries, ACK handling. The business sees only business objects; the endpoint sees the wire.

EDI implementation

In EDI, the Message Endpoint is typically implemented as an Apache Camel service, Spring Integration, or MuleSoft connector. Classic rule: one endpoint per (partner, protocol) pair. Inbound, the endpoint receives the AS2 MDN, deserialises the payload, validates the signature, drops an event into Kafka. Outbound, it consumes an event, serialises into EDIFACT/X12/UBL, signs, encrypts, sends. Camel patterns: producer / consumer / route DSL.

Anti-patterns

• Omniscient endpoint mixing business and transport — separate concerns per layer.
• Endpoint without configured timeout/retry — a downed partner blocks the whole chain.
• Endpoint shared across partners — one problematic partner impacts all the others.
• Endpoint without observability (structured logs, traces, metrics) — debugging production becomes impossible.

Related patterns

• Message Channel — the channel the endpoint plugs into.
• Point-to-Point Channel — typical topology for an EDI endpoint.
• Polling Consumer — pulling endpoint variant.
• Event-Driven Consumer — pushing endpoint variant.

Sources

• Hohpe G., Woolf B. — EIP, Message Endpoint (p. 95). www.enterpriseintegrationpatterns.com/patterns/messaging/MessageEndpoint.html
• Apache Camel — Component Reference. camel.apache.org/components/4.4.x/