Metadata messaging service
| June 24, 2019
Interfaces with the surrounding content systems, e.g. content management systems, online shops or PIM systems are an essential component of every digital asset management implementation. This of course also applies to Cumulus projects. With the Cumulus Integration Platform, we offer an extensive RESTService API with which context systems have both read and write access to Cumulus. However, unfortunately, when there are a lot of projects, this is no longer enough. The requirements for interfaces are constantly increasing. More and more, Cumulus is required to inform context systems about changes to assets and their metadata.
Informing context systems about changes
The new Cumulus module ‘metadata messaging service’ (MMS for short) meets this demand to a tee. Based on the Cumulus Trigger, MMS is able to send messages (so-called REST calls) to various content systems. The recipient of these messages must be a REST service which has to be provided by the respective target system. All types of Cumulus events are supported via various message types (new, update and delete). The content of the messages can be defined based on the message type in combination with the target system to be notified.
This way it is possible, for example, in case of a new event occurring, to pass on different information to the CMS than to the PIM system. If the extensive configuration options aren’t enough to meet the requirements of an interface, a BodyWriter plug-in can be developed, which a developer can define the content of the messages independently. This allows even complex infrastructures with different content systems and various interfaces to be used.
Error-tolerant architecture prevents inconsistent data
Of course, it can happen that a system might not be available, either because there is a network malfunction or because planned maintenance is being carried out. What of course can’t be allowed to happen in this case is messages get lost and aren’t delivered to the target system. For this reason, all Cumulus events in the MMS are cached in queues (based on Apache ActiveMQ). This ensures that no messages get lost. As soon as the target system in question is up again, communication is resumed, and the queued messages are sent.
Interfaces have to authenticate themselves
Of course, we can’t leave out the topic of security when it comes to interfaces: Even if the systems know one another and perhaps are even part of the same infrastructure, more and more, interfaces are required to authenticate themselves to one another. The MMS meets these requirements. The authentication methods BasicAuth and OAuth 2.0 are currently supported. Other authentication methods can also be added if needed through Canto Professional Services.
Use of MMS using the example of a content management system interface
A typical use case for the MMS is implementing an interface with a content management system (CMS). Thanks to the integration with the Cumulus asset browser, the editor in the CMS is able to search for assets from Cumulus and place them on a site. So far, so good, but what happens if the release of the assets changes or license rights expire? Of course, the delivery of the image to the website is prevented by Cumulus in this case (see Media Delivery Cloud). But the editor in CMS has to be informed about this change as well.
The MMS steps in here: If the metadata of an asset in Cumulus change, an event is sent to the MMS. This converts the change to a message and sends it to the CMS. The message directly contains the release status and license information. Based on this information, the CMS can start a correction workflow for the corresponding sites and notify the editor of this.
Other examples of use include interfaces with PIM systems or online shops. The basic principle of these interfaces is always the same: The MMS sends messages to a target system based on Cumulus events.
The MMS is a good example of how a generic and universally implementable Cumulus module can come out of a project solution.