DDEX Standard

Skip to end of metadata
Go to start of metadata

The choreography enabled by this standard is depicted in the two diagrams below. The actions on both sides (represented by red boxes) are exemplary only and only represent a typical information exchange in accordance with this standard. It comprises of these steps:

  1. A Release Distributor contacts the Release Creator by accessing its web service end point using a secure HTTPS connection, asking for a list of Releases that are available for it;

  2. The Release Creator responds with an Atom feed page containing a series of Atom feed entries.
    Each of these entries provides a brief description of a Release plus a URL that can be used by the Release Distributor to obtain the Release.
    The Release Creator should only make available an Atom feed entry for a Release, once it can deliver the relevant NewReleaseMessage and its Resources.
    The Release Creator should also take care that at no time more than one NewReleaseMessage for the same Release appears in the Atom feed.
    As a consequence, a Release Creator should remove entries from its Atom feed as soon as it needs to update a NewReleaseMessage that is referenced in the Atom feed. The Release Creator should also make sure that the appropriate status code of 404 is returned upon a Release Distributor calling the now outdated GET ERN Message or GET ERN Resource call;

  3. The Release Distributor contacts the Release Creator again by accessing the web service end point using the URL provided in Step 2 using a secure HTTPS connection, to get a NewReleaseMessage using the URL provided in the Atom feed entry;

  4. The Release Creator responds with a NewReleaseMessage in accordance with the relevant standard as agreed between the Release Creator and the Release Distributor;

  5. The Release Distributor ingests the NewReleaseMessage and extracts the URIs for each of the Resources that are part of the Release;

  6. The Release Distributor downloads and ingests each of the Resources from the Release Creator in the case of network based URIs using the GET ERN Resource call. 

  7. Alternatively, if the URIs  specify either a local path managed by the Release Distributor to where the Resources have been pre-delivered or a location on an SFTP server, the Release Distributor obtains and ingests the Resources.

  8. The Release Distributor informs the Release Creator that it has ingested the entire Release (including its Resorces) by using the DELETE ERN Message method with the URL used to obtain the NewReleaseMessage in Step 3.

Figure 1 – Basic ERN Web Service Choreography

Wherever this Clause references the NewReleaseMessage this is to be understood to also include the PurgeReleaseMessage.

Figure 2 – Additional Commands in the ERN Web Service Choreography


Specifically not shown in the diagrams is the approach to exception handling.

It is for instance possible that a Release Distributor requests a NewReleaseMessage based on the information received on an earlier GET ERN Feed command – but that that NewReleaseMessage no longer exists at that URL. In that case the response from the Release Creator’s web service could be a “redirect” with a 301 status code which could trigger the Release Distributor to request the Release using the information received in the reply.

  • No labels