ERN choreography using Web Services

The ERN Choreography for Web Services 1.7 defines how web services can be used for the delivery of metadata and other communication between partners. The specification for ERN Choreography for Web Service version 1.7 can be found here.

The standard contains detailed descriptions of the entire message choreography that can take place using web services between two business partners. Each step in the choreography contains a pair of messages, a request message and a response message, known as calls. The standard defines all of these request and response messages. In this standard, DDEX uses REST-like web services.

The calls defined in the standard provide the following benefits:

  • A well defined messaging interface between the sender's and receiver's systems without interfering with their autonomy;

  • High visibility of the status of releases and resources in the supply chain for both parties (e.g. information about upcoming releases in the sending party's part of the supply chain);

  • Enabling quick reaction to problems without the need of phone calls or emails (especially useful when managing different time zones);

  • An automated process without the need for human interaction for all the actions performed frequently; and

  • Control of the choreography and content flow for the receiving party.

Using all the calls defined in the standard provides full visibility and control over both partners’ view of the supply chain. However, some companies may wish to start by using the basic calls defined in the standard and build up from there.

About the standard

The ERN Choreography for Web Services 1.7 standard contains detailed descriptions of the entire choreography between business partners that it supports. The standard defines all the messages, known in web services as calls. Each call always consists of a pair of messages, a request message and a response message.

The calls can be implemented as asymmetric or symmetric calls, both have advantages and disadvantages. However, some calls only work effectively in the symmetric context, and are therefore not supported for the asymmetric choreography.

The standard contains a significant number of calls which fulfil different business requirements. Together these provide full visibility and control over your supply chain and the content it receives but to gain that full advantage requires the implementation of all the messages defined in the standard. Some implementers may find it more straight forward to implement the messages supporting the basic business requirements and then add to those over time. To assist in that approach the standard defines four groups of choreography and message options each of which provide greater visibility and control over your supply chain.

About the messages

Within the standard there are a significant number of messages defined, for example:

  • To request a new delivery;

  • To check the status of the product in the partners supply chain; and

  • To request reports.

All these messages contain a one common part, the header. The header:

  • Identifies the sender and the recipient of the message;

  • Identifies the message itself, for later reference (e.g. in the acknowledgment);

  • The type of web service choreography chosen;

  • The message creation date (including time zones) in order to identify the order of the messages, in case there are multiple message of the same type;

  • Some optional fields, such as the hash sum of the message; and

  • The priority of the message;

Implementers are advised not to send high priority requests all the time as this will make it impossible for business partner to identify high priority messages from those that are standard priority.

The actual resource files that relate to the metadata in the messages and certain types of reports will not be messaged as web service calls, mainly becuase of their large size. These are loaded to a defined location using the SFTP standard. All the resource files and their individual location are referenced in the web service message so that the two can be brought together by the recipient of the messages and the resource files.

About REST

DDEX uses REST-like web services. Each of the messages can be validated with an XML Schema file, making it easy to filter invalid messages from the start. DDEX highly recommends making use of the XSDs to prevent problems at later stages in the process. DDEX also advises that implementers not only validate messages received, but also messages you intend to send before they go.

DDEX works with namespaces in the XSDs, so if the messages you generate look good, but still fail, that is one of the first things to check.

Different programming languages and tools can be used to simplify the coding of the messages and also the processing of them. The schemas DDEX is using are very complex, making use of sophisticated XML schema constructs like unions, inheritance, choices etc. This approach makes the XML schemas very smart and easy to read, but demand from the tools that they are able to cope with these complex requests.

Part of the choreography enables the sending of acknowledgements to confirm the receipt of a sender's message. The acknowledgement messages enables the sender of the message to provide information about the status of the message to which the acknowledgement refers, such as giving detailed error information. However, DDEX has not created a list of valid error messages so far or defined the structure of these. This might become a DDEX work item once the community has more experience of using web services as defined in the standard.

Search