Canonical model: A great step in managing clutter in your ESB
In our previous blogpost we discussed how an ESB can keep your IT environment clutter-free. So, how do you keep said ESB uncluttered and make sure your IT environment doesn’t end up a big “wiry” mess? At inQdo, we use the canonical model. A canonical model is an agreement that states how certain fields that go through the ESB, are defined. Therefore, it’s a design agreement. Its biggest advantage is that it allows you to easily re-use data.
By: Michiel van der Winden
Canonical documents: what are they?
A canonical model consists of canonical documents. A canonical document is a generic data structure (a specific ‘design agreement’ or ‘definition’) made to be (re-)used in your ESB applications. Your ESB developers can discuss the structures, making sure to create generic objects for specific use-cases so they can be used throughout the ESB. As they are free in creating the objects, they can discuss amongst each other what data to contain in which structure, what the naming conventions will be and how they’ll be using them. All of this results in a more consistent way of working, making it ideal for an IT environment that is prone to clutter or lack of oversight.
Using canonical documents
To optimally use canonical documents, developers will have to analyze, discuss and document the choices they make regarding the data structures. They’ll determine the correct way of use, what fields contain which data, and the meaning of each field. A (simple) example of using a canonical to make sure you have all the data you need: Address data. The simplest form of address data consists out of a street name, house number, postal code, city, country etc. To make sure the canonical format can be a consumer and provider for all sorts of applications, we at inQdo, for example, have decided to formulate our canonical in such a way as to use separate fields for the street name and house number. If an application uses a combination of street name and house number in the same field, we can concatenate those on the ESB ourselves for that specific mapping.
Figure 1: A simplified version of a mapping from a CRM system to a web shop using a canonical document.
As you can see in figure 1, we’ll use the canonical format as an intermediate structure, as to make sure we can receive all relevant data and map those through to another format entirely. In this case it’s regarding a message from a CRM system that has to be shown in a web shop, whilst both formats are entirely incompatible with each other. Having mapped the source format to our own, intermediate format, we can then create separate target mappings as to provide the data to every other system interested in said information.
Using this approach, we can see that we only have to have one mapping from the original source format to provide the data to all other, interested targets. In practice, this means halving your work as you’ll only have to make sure your data is available in your canonical format and your mapping to the new target is done correctly. Another thing this can prevent is the issue of duplicate code (sequence of source code that occurs more than once), as we’re re-using the first mapping for each new target. All in all, using a canonical document we can provide a faster, more efficient way of mapping a source document to multiple targets, whilst your code remains clear and concise.
Figure 2: Creating multiple target formats from one canonical document.
What to look out for using canonical documents
As soon as you start using canonical documents in your organization, you’ll have to make sure every involved party keeps communicating amongst each other regarding the structure of said canonicals. The developers and operational specialists will have to decide which data goes where, and what naming conventions will be followed. And whatever they do: Document it. You’ll want to make sure as little ambiguity as possible is used when coming up with naming schemes and data formats. It’s never convenient if you have to retrace your steps just to find out if your specific ID field should go in “CustomerNumber”, “CustomerID” or “PersonNumber”, just because they were never properly specified.
We fully recommend you use canonical documents in your ESB. using a canonical document we can provide a faster, more efficient way of mapping a source document to multiple targets, whilst your code remains clear and concise. Also, the canonical provides clarity to the developer and minimizes the issue with duplicate code. As long as all parties involved keep communicating and documenting changes and decisions, using a canonical document will always be a valuable addition to an ESB.
How can we help you?
Would you like to know more about our system integration services? We work with integration every day and would love to help you with your questions regarding IT. Call Peter Perebooms on: 06-45 34 40 46 or send an email to: info@inQdo.com.