Geeks With Blogs
Matt Gilbert An attempt at techy stuff

We used the model of canonical schemas as lot at my previous company. In fact we used it pretty much everywhere and retro-fitted older Integration solutions to use canonical schemas wherever and whenever we could. They buy you a lot and it’s a model I’m going to try and introduce to my current workplace.

If you are really lucky, your company might already have a notion of common business entities and a “data policing” department which controls what they look like. If so you already know what your canonical schemas are going to look like. If not, no matter; the key thing is that having an “Internal” schema inside of BizTalk provides a level of indirection or decoupling from the representations of business entities in the outside world. In an ideal world, all messages passing between systems within an Enterprise use the same schema and transformation is minimal or non- existent. B2B communication using industry defined schemas also minimises this. However, we very seldom find our selves in an ideal world and transformation at the middleware boundary is a fact of life for us.

Creating your “canonical” view of what an entity looks like and implementing it within your middleware can help insulate you from changes in the future. If you build an orchestration which directly uses an external schema, you are more susceptible to changes to that schema. If your orchestration handles a canonical message however, you may only have to update the transformation and continue to publish the canonical message to the MessageBox without further changes to any subscribing orchestrations. This really shows its worth if you have multiple subscribers to a single published message as you may only have a single change to make.

Canonical schemas also help developers understand business entities and provide consistency across solutions and integrations as they offer the opportunity for reuse. If you’ve defined what your company considers to be an “Invoice”, the same schema applies to all integration solutions. They can use meaningful names for elements and attributes rather than system or domain specific ones which may be alien to your organisation or someone not used to the sending platform (SAP schemas are a great example!). Referencing plays an important part also, and canonical schemas can reference other ones (a Canonical Invoice schema might reference a Canonical Address schema for example).

I prefer to keep all Canonical schemas together in their own containing application within BizTalk (<companyname>.Canonical.Schemas). I also like having an “Enterprise Header” applied to each schema which promotes content for routing and tracking. I’ll discuss that in another post.

Posted on Tuesday, April 7, 2009 3:48 PM BizTalk | Back to top


Comments on this post: A brief note on Canonical Schemas

# re: A brief note on Canonical Schemas
Requesting Gravatar...
Hi Matt, thanks for sharing the knowledge.
I am working on a B2B project on my client with their backend ERP is using SAP. There will be a number of B2B interfaces and each with have their own native schemas for exchange. From your experience, what the best practices or guidelines for be to design BizTalk canonical schemas - eg. handcraft or referred to "industry standard" etc... Please advise?
Thanks, Andy
Left by Andy on Jun 16, 2011 2:03 AM

Your comment:
 (will show your gravatar)


Copyright © mattjgilbert | Powered by: GeeksWithBlogs.net