General implementation workflow

Experience has shown that the successful implementation of DDEX standards follow a four-step approach. Obviously this approach will vary in detail depending on which standard you are implemented but these four-steps apply at a high level to all implementations:

Work with a business partner

The easiest way to implement a DDEX standard is to work with a chosen business partner with whom you wish to exchange data relating to a particular type of business transaction, using a DDEX standard. Implementing a DDEX standard alone can lead to mistakes because there is no one receiving your DDEX formatted message to determine if you have implemented correctly. Implementing with a business partner has proven to lead to fewer errors as issues are likely to be discovered early on. It also means that, when you wish to implement with other business partners after that, having a working implementation will make future partner integration much more straight forward.

Implementation planning

Once you have chosen a business partner to work with, whether the implementation is your first one or you are bringing on new partners to exchange DDEX formatted messages, the partners need to agree a plan for the implementation. This includes details about which message standard or profile is to be used and the message exchange choreography or protocol to employ. Each partner will also need to ensure that its own operational personnel and technical personnel understand both the business and technical requirements for the implementation. This will include ensuring that the partner creating the DDEX formatted message has access to all the types of data required for the standard being implemented. All this will make the work on the actual implementation much easier.

Mapping systems to the standards

Once an implementation plan is in place, the most complex and critical step towards implementation is to map the data fields from you existing database to the fields supported by the relevant DDEX standard, whether you are creating or ingesting a DDEX formatted message. The DDEX standards are based on a comprehensive data model describing works, resources, releases, right shares, parties, deals and other entities. Great care needs to be taken with regard to this mapping process as this is the only way to ensure that when DDEX formatted messages are being exchanged for real, both parties will know precisely what data is being communicated. Mapping of systems can be carried out in parallel with code development for the tools needed to create or ingest and communicate messages, but without successful mappings, that work will be in vain.

As a result of experience gained from previous implementations here are few easy tips:

  • Use XML schema mapping tools only if you have expert knowledge or have the time and skills to build up expert knowledge. Many XML mapping tools have quirks which need to be fully understood to gain maximum benefit;

  • Exclude parts from the mapping completely and manually parse them instead. For example, if working on the ERN standard set NewReleaseMessage to xsd:any and parse the xsd:any elements with SAX/DOM/something;

  • As with any good coding standard, if changes are made to the original DDEX schema these should be documented lest they get forgotten.

Integrating with a partner

Once the mapping and relevant code development has been concluded, the partners should run orchestration tests to ensure the cloud-based storage server or web server communications work as envisaged. Only then can integration tests be conducted. During the integration phase, the sender and receiver will need to conduct a “peer conformance procedure” where:

  • The sender determines if the receiver is able to receive and ingest messages according to the provided test packages; and

  • The receiver reviews the test packages from the sender to verify the delivered packages comply with the standard.

The sender will need to send a series of sample messages containing test data for a range of business scenarios. These sample messages are intended to test the receiver’s ability to receive and ingest them using the chosen delivery choreography, as well as their ability to correctly interpret the content of the messages. During the integration phase, the sender would typically send the receiver various messages representing different constructs within the message standard, depending on which standard is being used.

The test messages, delivered during the conformance test phase, will need to have the IsTestFlag set to True to indicate that the messages are test messages and their content should not be made available outside the test environment. These messages ensure that the receiver’s ingestion engine interprets the messages accurately. During this process, the sender will need to verify the message ingestion results with each receiver based on their choice of choreography. After the sender and receiver have passed the integration conformance tests, the sender can “turn on” the message communication in the value chain to kick off the production deliveries of messages.

Search