/
Building an eB2B endpoint

Building an eB2B endpoint

The steps on how to build an eB2B endpoint are going to heavily depend on the software used for the Access Point (AP) and Service Metadata Publisher (SMP), as well as the integration into the overall infrastructure in your business, be that a message processing platform, invoicing application, ERP or Accounting system or anything in between.

The applicable specifications are the core of the “Enhanced B2B Solution Architecture” (see eB2B Starting Environment Documents) which references additional Supporting specifications.

General Approach: Start small, grow in steps

The first functional milestone of the build will be to simply connect to another eB2B access point. This other AP can be either a partner or the OpenPeppol Testbed eDelivery suite (a dedicated “EB2B test suite” is planned).

Then, the next step is to gradually extend the functionality of the AP and SMP used to cover more of the eB2B specific implementation rules.

First Milestone: Establish eB2B connectivity

Identify an Access Point (Test/SMK) to use as EB2B endpoint

Configure SMP (Test/SMK) for use with eB2B

  • Software base: “regular” SMP (again, see https://peppol.org/tools-support/links-to-software/ )

    • eB2B uses the plain “Peppol SMP” certificate, so it’s possible to use an existing SMP or setup a dedicated instance

  • Needs to pick a relevant subset of, and then configure (as required):

    • Document / Process types per section 4.4 and 4.5 of the Solution Architecture (also part of the eDEC codelists)

    • Particularly make sure to include “Message Level Status” (section 4.5.4)

    • End User Identifiers and Service Provider Identifiers per section 4.3 and 4.2 respectively

Run first Test scenarios (sending / receiving a test file)

  • Configure message flows for your EB2B endpoint using eB2B Document Types according to your test scenario

  • Configure corresponding End Users in your eB2B SMP in SMK, using eB2B Process Type(s)/Document Types and the Access Point selected for eB2B

  • Setup the corresponding (minimal?) receiving process

  • Send a test document (manually?)

  • Send an MLS response in the “opposite” direction (manually)

Milestone 2: Add mandatory functionality

Extend eB2B processing logic: Generate MLS

Automate the process of generating an MLS from an inbound document, depending on the overall design of your infrastructure:

  • Either, connect the AP to an internal processing platform capable of performing validation (schematron) and any other required checks, including validating connectivity to the C4 End User

  • Or, add these functions into the AP implementation

Depending on the outcome, the processing logic needs to generate a corresponding MLS message and send it to the original sender as indicated in the inbound SBD headers.

Note: MLS generation and processing are in the process of standardization across the Peppol Network, so it may makes sense to add this capability generically to your endpoint(s).

AP sender validation: Accept eB2B flows only from eB2B senders

Note: having removed the requirement to use a dedicated EB2B certificate, no strict implementation of sender validation is defined. Since all (production) transactions are reported, correct usage of EB2B process types between EB2B participants only (as identified by the subtotals for PerSP-DT-PR; see 3.3.2. Subtotal per Service Provider, Dataset Type and Process ID) is monitored by the EB2B Peppol Authority (OpenPeppol)

Add shared document type (EN16931-eB2B Extension)

As a best practice, the EN16931-eB2B Extension should be supported.

Note: as many of the features of EN16931-eB2B seem to be included in the upcoming (H2/2025) revision of the EN16931-1, this requirement may be analyzed and replaced at that point in time.

Milestone 3 ff.: Add application-level components

Having completed the required functionality, the actual business processes need to be implemented in Message Flows. The choice and level of detail is heavily dependent on the target business scenario, including

  • Sending hybrid files using an End User address, a network address or point-to-point/SPIS address

  • Sending EDIFACT files using an End User address, a network address or point-to-point/SPIS address

  • Implement sender validation checks on network endpoints (to ensure controlled onboarding)

  • … and much more …