CEF eDelivery AS4 and SMP/SML — Architecture, Setup, and Integration Guide

Executive summary: This guide explains how to design, deploy, and operate a CEF eDelivery AS4 gateway with SMP/SML for dynamic discovery and secure B2B/B2G exchange. It covers a production‑ready blueprint for a cef edelivery as4 gateway, a step‑by‑step peppol smp sml setup, and hands‑on as4 ebms3 integration patterns with security, certificates, testing, and operations.

What eDelivery, AS4, SMP, and SML are — and how they fit

  • CEF eDelivery is the European Commission’s building block for interoperable, secure message exchange using the 4‑corner model.
  • AS4 (ebMS3 + AS4 profile) is the messaging protocol using SOAP with WS‑Security for signing, encryption, receipts, reliability, and large attachments.
  • SMP (Service Metadata Publisher) is a registry per participant that lists supported document types, processes, and endpoint capabilities.
  • SML (Service Metadata Locator) is the central DNS‑based index that maps a participant identifier to its SMP, enabling dynamic lookup.
  • Together they enable dynamic discovery — your gateway finds the receiver’s SMP via SML, reads endpoint metadata, and sends an AS4 message to the correct access point.

Four‑corner model — roles and flow

  1. C1 — Sender system: Your business application or integration backend.
  2. C2 — Sender access point: Your AS4 gateway that enforces policy and security.
  3. C3 — Receiver access point: Counterparty’s AS4 gateway discovered via SMP/SML.
  4. C4 — Receiver system: The counterparty’s business application.

Typical path: C1 hands the payload to C2, which discovers C3 via SMP/SML, then pushes the AS4 message. C3 validates, acknowledges with a signed receipt, and delivers to C4.

Components you will deploy — reference stack

  • AS4 Gateway — e.g., a CEF‑compatible gateway supporting ebMS3, AS4 One‑Way/Push and Pull, WS‑Security (sign/encrypt), compression, large payloads, receipts, and retry.
  • SMP Server — an SMP implementation to publish your participants’ service metadata.
  • SML Onboarding — an account with the target network’s SML to register participants and link them to your SMP DNS domain.
  • PKI & Key Management — trust stores for remote AP certificates, your signing/encryption keys, TLS certs, OCSP/CRL validation, and rotation processes.
  • Monitoring & Evidence Store — logs, metrics, message traces, and immutable storage for receipts and proofs.

cef edelivery as4 gateway — production setup checklist

Certificates and keystores

  • Generate separate keys for signing and encryption; store in HSM or a cloud KMS.
  • Maintain a dedicated TLS server certificate for the gateway’s HTTPS endpoint.
  • Import trusted CA roots for counterparties and the network governance chain.

Security policies

  • Sign and encrypt messages at the SOAP level; require signed non‑repudiation receipts.
  • Algorithms — RSA‑SHA256 for signatures, AES‑GCM for encryption, SHA‑256 digests.
  • Enable OCSP stapling or live OCSP checks and CRL fallbacks.

Reliability and receipts

  • Use Reception Awareness — retries with exponential backoff and idempotency keys.
  • Require signed receipts; persist MessageId, Receipt hash, and timestamps.

Payload handling

  • Support attachments via MIME/SwA; enable compression for large UBL/ASN/XML.
  • Enforce payload size limits and streaming to avoid memory spikes.

P‑Mode configuration

  • Define AgreementRef, Service, Action, PartyIds, MEP (One‑Way/Push or Pull).
  • Bind security, reliability, and transport properties per counterparty.

Networking and HA

  • Place the gateway behind a load balancer; terminate TLS either at LB or gateway.
  • Use a shared database/queue for clustering; ensure sticky routing if needed.
  • Open only required ports; enforce mTLS if dictated by the network.

peppol smp sml setup — step‑by‑step

Plan identifiers

  • Choose participant ID schemes you will support (e.g., VAT, GLN, custom). Normalize format and case consistently.

Provision SML access

  • Obtain SML credentials from your network governance. Configure your SMP’s base domain and SML zone settings.

Deploy SMP

  • Host an SMP server with HTTPS and a stable DNS name. Install a valid TLS certificate and enable HTTP caching for metadata endpoints.

Register participants in SML

  • For each participant ID, create an SML mapping to your SMP. This creates DNS records that allow BDXL lookups to resolve to your SMP.

Publish services in SMP

  • For each participant, create service metadata:
    • Document type identifiers and process IDs you support.
    • Endpoint URL of your AS4 access point.
    • Transport profile URNs that match the network’s AS4 profile.
    • Certificate used by your AP for message‑level security.

Verify discovery

  • Use DNS tools to confirm the BDXL record exists and points to your SMP.
  • Fetch SMP ServiceGroup and ServiceMetadata documents via HTTPS and verify contents.

End‑to‑end smoke test

  • Send a test business document to a known echo or test participant.
  • Validate that your gateway selects the correct endpoint and receives a signed receipt.

as4 ebms3 integration — message anatomy and patterns

  • Headers that matter
    • `eb:Messaging / UserMessage / MessageInfo / MessageId`
    • `eb:CollaborationInfo / Service`, `Action`, `ConversationId`, `AgreementRef`
    • `eb:PartyInfo / From / To` with `PartyId` values matching network rules
  • Security
    • WS‑Security header with BinarySecurityToken and signature references to SOAP body and MIME parts.
    • Encryption of payload parts as required by the profile.
    • Signed non‑repudiation receipts (AS4 Receipt signal with embedded digest values).
  • MEP choices
    • One‑Way/Push — sender initiates HTTP; most common for synchronous hand‑off with async receipts.
    • One‑Way/Pull — receiver polls; used when inbound connectivity is restricted.
  • Idempotency and retries
    • Persist `MessageId` and business keys; treat duplicates as safe replays.
    • Implement exponential backoff with jitter and maximum delivery window.

Minimal SOAP envelope skeleton (illustrative)

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">
<soap:Header>
<eb:Messaging>
<eb:UserMessage>
<eb:MessageInfo>
<eb:MessageId>urn:uuid:2b3e...</eb:MessageId>
<eb:Timestamp>2025-09-28T12:34:56Z</eb:Timestamp>
</eb:MessageInfo>
<eb:PartyInfo>
<eb:From><eb:PartyId type="urn:example:id">SENDER-ID</eb:PartyId></eb:From>
<eb:To><eb:PartyId type="urn:example:id">RECEIVER-ID</eb:PartyId></eb:To>
</eb:PartyInfo>
<eb:CollaborationInfo>
<eb:Service type="urn:example:service">urn:docs:invoice:3</eb:Service>
<eb:Action>submit</eb:Action>
<eb:AgreementRef>default-as4-agreement</eb:AgreementRef>
<eb:ConversationId>CONV-123</eb:ConversationId>
</eb:CollaborationInfo>
<eb:PayloadInfo>
<eb:PartInfo href="cid:payload-1.xml"/>
</eb:PayloadInfo>
</eb:UserMessage>
</eb:Messaging>
<!-- wsse:Security goes here (signature, encryption, timestamps) -->
</soap:Header>
<soap:Body/>
</soap:Envelope>

Discovery flow — resolving endpoint via SMP/SML

  1. Normalize the participant ID (scheme + value).
  2. Query SML (BDXL) to locate the SMP host for the participant.
  3. Retrieve SMP `ServiceGroup` to list available document types.
  4. Fetch `ServiceMetadata` for the selected document/process.
  5. Extract the endpoint URL, transport profile, and certificate.
  6. Select the correct P‑Mode and dispatch via AS4 to the access point.

Certificates and trust — what to manage carefully

  • Message‑level keys
    • Maintain separate signing and encryption certificates; rotate on a calendar and on compromise.
    • Advertise your current public certificate in SMP to allow receivers to validate.
  • TLS
    • Use modern cipher suites; enforce TLS 1.2+; consider mTLS if mandated.
    • Pin to governance CA roots; monitor expiry and automate renewal.
  • Validation
    • Enable OCSP with soft‑fail thresholds and CRL fallbacks.
    • Record validation outcomes in message audit logs for evidence.

Testing and conformance — how to de‑risk go‑live

  • Unit & integration
    • Mock SMP responses and SML DNS; simulate endpoint changes and certificate rotations.
    • Validate SOAP headers, WS‑Security policies, and receipts against the profile.
  • Interoperability
    • Run official conformance tests for AS4 and network‑specific profiles.
    • Exchange test documents with multiple counterparties — focus on edge sizes and multi‑attachment cases.
  • Negative scenarios
    • Expired or revoked certs, signature mismatch, decryption failures, policy violations, oversized payloads.

Operations — monitoring, alerting, and evidence

  • Key KPIs
    • Delivery success rate, median end‑to‑end latency, receipt issuance time, retry counts, duplicate suppression rate.
  • Observability
    • Correlate by `MessageId` and `ConversationId`; expose metrics for P‑Modes, HTTP status, and WS‑Security faults.
  • Evidence handling
    • Store signed receipts, message digests, timestamps, and policy versions in WORM storage.
  • Runbooks
    • Replay safe messages by `MessageId`; escalate on repeated policy faults; rotate certs with canary participants first.

Common pitfalls — and how to avoid them

  • Publishing incomplete SMP metadata — always include correct transport profile, endpoint URL, and current certificate.
  • Forgetting idempotency — deduplicate by `MessageId` and business keys to avoid double processing.
  • Mixing test and production SML zones — separate DNS domains and credentials per environment.
  • Weak OCSP/CRL handling — implement robust status checks to prevent accepting revoked certificates.
  • Hard‑coding counterparties — rely on SMP/SML discovery so endpoint and certificate changes do not break flows.

Implementation blueprint — quick start

  1. Stand up the AS4 gateway with a baseline P‑Mode profile and working TLS.
  2. Deploy an SMP, obtain SML credentials, and register a test participant.
  3. Publish service metadata for one document type and process.
  4. Validate discovery via SML → SMP, then send a test AS4 message and verify receipt.
  5. Automate certificate renewal, OCSP checks, retries, and evidence archiving.
  6. Expand document coverage and onboard production participants progressively.

Glossary

  • AS4: An OASIS profile of ebMS3 for secure B2B messaging.
  • ebMS3: ebXML Messaging Services 3.0 — the core SOAP messaging standard.
  • SMP: Service Metadata Publisher — per‑participant service registry.
  • SML: Service Metadata Locator — DNS‑based index for discovering SMPs.
  • P‑Mode: Parameter set describing how two parties communicate in AS4.
  • BDXL: Business Document Metadata Service Location — DNS mapping spec for SMP discovery.

Summary

  • CEF eDelivery with AS4, SMP, and SML provides dynamic discovery and secure, reliable exchange in the 4‑corner model.
  • A robust cef edelivery as4 gateway hinges on strong WS‑Security, receipts, reliability, and careful P‑Mode design.
  • A correct peppol smp sml setup enables hands‑free endpoint discovery and certificate distribution.
  • For as4 ebms3 integration, focus on headers, signatures, encryption, receipts, idempotency, and observability to achieve production‑grade interoperability.