Document exchange explained

This article explains one of the biggest mysteries in PEPPOL: how does the document exchange work and what roles does the SML (Service Metadata Locator) play in it.

Prerequisites

To start a document exchange in PEPPOL, you need to have the following information before you can start submitting anything:

  • The PEPPOL Participant Identifier (PPID) of the recipient (currently this must be exchanged out-of-band but with the upcoming PEPPOL Directory there is help in sight)
  • On which SML is the PPID registered (production SML or test SMK)
  • The document type ID and the process ID to be used
  • The business document to be exchanged is of course needed

How it works

Lets start at the beginning. The first thing you need to do, is to find the SMP where the document receiver has registered its endpoints. Therefore the PPID and the SML information are required.

  • PPID with scheme iso6523-actorid-upis and value 9915:test
  • SML to use = DG DIGIT SMK (= the Test SML). The DNS zone for the SMK is acc.edelivery.tech.ec.europa.eu.

  1. First thing that happens, is that the dynamic URL is assembled. The algorithm that is used is the following:

    "http://B-" + hexstring(md5(lowercase(ID-VALUE))) + "." + ID-SCHEME + "." + SML-ZONE-NAME

    ID-SCHEME and ID-VALUE are taken from the PPID and the SML-ZONE-NAME is taken from the SMP. That implies that a different identifier (as good as MD5 can do it) will create a different DNS name.

    For the identifier iso6523-actorid-upis::9915:test and the SMK the created URL is http://B-85008b8279e07ab0392da75fa55856a2.iso6523-actorid-upis.acc.edelivery.tech.ec.europa.eu

  2. This URL is resolved via the Domain Name System (DNS) to the IP address 85.158.224.220 which is the IP of the server http://test-infra.peppol.at. This is exactly the server name that was used when registering the SMP to the SMK. See below for details on what happens on SMP to SML registration.

  3. So the B-8500.... URL is already the URL to the SMP and all that is left to do, is to append the participant identifier to the URL to get all supported document types. For the example the URL would be http://B-85008b8279e07ab0392da75fa55856a2.iso6523-actorid-upis.acc.edelivery.tech.ec.europa.eu/iso6523-actorid-upis::9915:test. The reason why the participant identifier needs to be appended again is solely than an SMP can host multiple participants on the same server.

    To see that this is just a DNS forward you can compare the results of http://B-85008b8279e07ab0392da75fa55856a2.iso6523-actorid-upis.acc.edelivery.tech.ec.europa.eu/iso6523-actorid-upis::9915:test and http://test-infra.peppol.at/iso6523-actorid-upis::9915:test and see that there is no difference in the responses.

  4. Now that the SMP URL is known, the SMP query with the document type (following the schema http://smp.url/participant/services/documenttype) can be performed). The resulting signed document must be parsed so that the endpoint matching the desired process ID and transport protocol can be retrieved. This is finally the URL to which the business document is to be send.

    All the above mentioned steps are usually handled by the SMP client software.

  5. The last step is the transmission of the business document to the endpoint URL determined in the previous step. Additionally components like special validation services etc. may be used depending on the effective setup but I wont cover them in this article.

    This is the task of the AccessPoint client.

And how was the SML involved in all of this? Not at all! Only the Domain Name System is queried upon a document exchange. And if the DNS fails, there are more severe issues than not being able to send documents via PEPPOL. And that is one of the intelligent parts of the PEPPOL network: no central single point of failure that can stop the document exchange for everybody.

Appendix - SMP/SML interaction

The SMP has the following interactions with the SML and is responsible for telling the SML what to do.

  1. When an SMP enters the PEPPOL network, it needs to be registered to the SML. This is where the SMP-ID comes into play. For the registration the SML creates a DNS entry with the name SMP-ID + ".publisher." + SML-ZONE-NAME which is a CNAME entry (alias) to the hostname provided for registration. This is the so called publisher entry.

    Example: an SMP with SMP-ID TEST-SMP and host name smp.example.org should be registered at the SMK (with DNS zone name acc.edelivery.tech.ec.europa.eu.). Therefore the DNS name TEST-SMP.publisher.acc.edelivery.tech.ec.europa.eu pointing to smp.example.org is created.

    Note: this publisher entry is the reason, why the SMP-ID can only used a limited character set.

  2. If the host name of an SMP entry changes, the SMP-ID and the new host name are send to the SML and the SML updates the publisher entry in the DNS. That means that all existing participant DNS entries (see below) don't need to be modified.

  3. When an SMP leaves the PEPPOL network, the publisher entry and all entries referencing this publisher entry will be removed.

  4. Each time a service group (participant) is added to an SMP that is registered to an SML, the SML creates a CNAME entry (according to the algorithm explained above - "B-...") that in turn points to the publisher entry.

    So upon name resolution, the service group DNS entry is resolved to the publisher entry which in turn is resolved to the SMP host name.

    Note: the latest version of the SML not only creates a CNAME record for each participant but also a DNS NAPTR record pointing to the publisher entry. For the NAPTR records, the e-SENS algorithm for creating DNS names is used instead: strip-trailing(base32(sha256(lowercase(ID-VALUE))), "=") + "." + ID-SCHEME + "." + SML-ZONE-NAME

You must be logged in to post a comment!