Prioritisation of ERN messages

ERN messages are stateless; each ERN message communicates a “picture of truth” about a release, the resources it contains and the commercial conditions under which a DSP may make available that release to consumers.

Using ERN message queues to signal priorities

The ERN choreography standards for cloud-based file exchange and web services support priority/non-priority indicators when exchanging messages. These indicators enable a record company or distributor to provide a DSP with new releases and back-fills as discrete "queues".

Recipients can then process, for example, back-fills in a separate ingestion queue without impacting new release ingestion speed. When using the ERN choreography standard for cloud-based file exchange these different queues are signalled through the file naming convention:

  • A batch folder name starting with the letter “N” signals that the contained releases are to be processed with “normal” priority – this is typically used for regular new releases or updates;

  • A batch folder name starting with the letter “P” signals that the contained releases are to be processed with “priority” – this is typically used for new releases or updates that should be processed immediately;

  • The same convention can be used for individual ERN messages in the Release-by-Release profile; and

  • Other letters can be bilaterally agreed between the sender and recipient of the ERN messages (e.g. “L” for low priorities such as back-fills). DDEX expects this to be part of a future version of the relevant standard.)

When using the ERN choreography standard for web services, priorities can be implemented by the record companies to, for example, provide an Atom feed for each message queue (e.g. one Atom feed for releases with “normal priority” and a separate Atom feed for “high priority: releases).

It is the responsibility of the message sender to not overuse a priority queue in order to enable them to retain the ability to mark a specific batch or ERN message as being particularly urgent.

Rules for concurrently sent ERN messages

The rules of the ERN choreography standards dictate that the record company or distributor should ensure that it never includes information about the same release in different messaging queues at the same time.

This rule does not preclude a record company or distributor to include information about the same sound recording (or any other resource) and/or work in different messaging queues. However, as the metadata about a specific resource (or work) may differ between different releases anyhow, there is no issue even if the ERN messages are processed by the DSP in a different order to how they were added to their respective messaging queues.Picture1.png

Handling of party data in concurrently-sent ERN messages

The aforementioned rule does also not preclude a record company or distributor to include information about the same party (such as a writer or recording artist) in different messages. As core party data such as the ID and name are independent from release data, a problematic “race condition” can occur. (This race condition does not apply to the display name of the party in any specific release or resource as these are, again, release-specific):

  • Assume a record company releasing three releases R1, R2 and R3. All three releases contain music created by a specific party P.

  • On day 1 the record company communicates R1 in the “normal” messaging queue and R2 in the low priority “back-fill” queue. A few days later, the record company changes the data it holds (and shares) about the party P to P’ and, a few days later than that, R3 is communicated to its business partners (now with the new party information P’) in the “normal” queue.

  • A receiving DSP may ingest R1 (with P), then P3 (with P’) from the “normal” queue before, eventually, ingesting R2 (with, again, the old P) from the “back-fill” queue – potentially overwriting the correct data P’ with the obsolete data P.

This race condition is depicted below for the case where a DSP processes all “normal” ERN messages before ingesting any releases in the “backfill” queue:

Picture1.png

The DSP can only avoid this if it considers the timestamp of the ERN message when deciding to ingest party data:

  • On first encountering a party, the data is ingested and the time stamp in the header of the ERN message (not the time of ingestion!) is stored alongside the party metadata;

  • On receiving data about a party that the DSP already has in its database, the DSP should only override the data held locally if the time stamp of the current ERN message is newer than the time stamp held locally.

This process only applies to ERN messages from the same source; there is currently no advice available on how to handle the situation when a DSP receives differing party information from different sources.

Search