5.2 Choreography

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

1. A DSP contacts a record company or distributor by accessing the latter’s web service end point using a secure HTTPS connection, to ask for a list of releases for which a NewReleaseMessage is available;

2. The record company or distributor responds with an Atom feed page containing a series of Atom feed entries. 

   1. Each of the Atom feed entries provides a brief description of each release that is available for the DSP and a URL where a NewReleaseMessage about each such release is located. The record company or distributor should only provide Atom feed entries for those releases for which it can deliver a NewReleaseMessage.

   2. The record company or distributor shall ensure that at no time is there more than one NewReleaseMessage for the same release accessible through the Atom feed. 

   To ensure this is the case, the record company or distributor shall remove past entries from its Atom feed about a release before it makes available a new Atom feed entry with the URL for the location of an update NewReleaseMessage about the same release. 
   The record company or distributor shall also ensure that the status code of 404 is returned to a DSP if the DSP makes a call of GET ERN Message or GET ERN Resource in respect of the past entry in the Atom feed entry relating to that release;

3. The DSP contacts the record company or distributor to request the relevant NewReleaseMessage by accessing the record company or distributor’s web service end point using a secure HTTPS connection and the URL provided in the Atom feed entry discussed in (1) above;

4. The record company or distributor responds by making available to the DSP the relevant NewReleaseMessages created in accordance with Parts 1 and 2 of the ERN standard and as determined by the bilateral agreement between the record company or distributor and the DSP;

5. The DSP ingests the NewReleaseMessage and identifies in the message the URIs for the location of each of the resource files that make up the release;

6. The DSP downloads from the location indicated in the NewReleaseMessage each of the relevant resource files.
   Where the record company or distributor is using network based URIs this is done by using the GET ERN Resource call and by then ingesting the files into its systems;
   Alternatively, the DSP can download the resource files directly if the URIs provided by the record company or distributor specify, either:

   1. A local path to a location that is managed by the DSP where the record company or distributor has already uploaded the resource files; or

   2. The location on a cloud-based file server.

7. The DSP informs the record company or distributor that it has ingested both the NewReleaseMessage and the resource files relating to the relevant release by using the DELETE ERN Message call with the URL used to locate the NewReleaseMessage.

Figure 1 – Basic ERN web service choreography

Figure 2 – Additional commands in the ERN web service choreography

Not shown in these diagrams is the approach to exception handling. So, for example, it is possible that a DSP requests a NewReleaseMessage based on the information received as a result of an earlier GET ERN Feed command, but that NewReleaseMessage no longer exists at that URL. In that case the response from the record company or distributor’s web service could be a “redirect” with a 301 status code, which could prompt the DSP to request the metadata and the resource files for the release using the information received in that reply. Such an approach however, is not defined in this part of the ERN standard.