Dear all,

The definition of canonicals is probably the most underrated part of an EAI. It is, in my experience, also the part which leads also to the most errors and inconsistencies in large integration projects.

This thing really gives me headaches espcecially since there doesn’t seem to be any ‘best solution’.
Or as it is summarized in the ‘GEAR 6 Canonical Strategy White Paper.pdf’: “Ultimately, there is no right and wrong canonical strategy for every scenario and
organization. Ultimately, the recommended canonical strategy will depend on each
organization�s specific business scenarios as well as organizational preferences.”

However, I am sure that everyone of you has some interesting ‘lessons learned’. E.g. how do you keep performance high without giving up too much maintainability, etc …
Also, what are your hints on keeping events flexible? (e.g. using structures, parsing different data in one string, etc …).
In short, let’s hear your opinions on canonical strategy. I am eager to read your input.
Rgrds,

cdrc

Like you said there is no right and wrong answer but there are definitely some guidelines for building a Canonical model around your enterprise.

There are 2 major type bases on my perspective, physical canonicals and logical canonicals. Meaning to have a physical structure (e.g. xml or even flat file) or logical structure (e.g. database driven semantics). There are some tools out there that will assist doing Canonical models but more importantly is the enterprise governess and support to steer their business unit/project toward this goal. Traditionally, mapper/integration analyst do straight mapping and it will be a battle getting them to follow the new way of doing things. Especially, the benefit of this extra work will only to be see/proven in the further rather then immediate.

There are just so so many area to be discuss to come up with the perfect plan

Hope this at least give you some pointers.
Alan Leung

Guys,

I currently facing the same dilemma: what strategy to take when designing canonical documents? However, I have a more specific question.

I’m currently working on a project in which I have to come up with canonicals for all the major B2B transactions (ex.: Order, Order Confirmation, Invoice, Ship Notice, Catalog, etc.) Given that the structure of these transactions can be quite large and complex, I’ve been thinking about ways in which I can minimize the effort and the risk involved in creating each canonical document. Having said that, I’m currently considering using an already existent standard protocol (ie. cXML, ebXML, xCBL, OAG, etc.) as the format for my canonicals. My plan is to download one of these standards from the web and import their XSDs or DTDs into the webMethods Developer and then use those document structures as my canonicals.

Is this a good/bad idea? Why? Have any of you done this before? What is your suggestion on what standard would benefit me the most?

Thanks,
Percio Castro

We have used some canonicals based on OAG but have had to do alot of modifications.

There is a canonical strategy guide in webMethods GEAR 6.

I have been on projects that have used various canonicals…custom, xcbl, chemxml, rosettanet. There are pros and cons to each, but I personally prefer the custom approach for the following reasons (obvioulsy you could argue whether these are pros or cons).

PROS:
-No force feeding data into fields (avoid the “we can just put that here” approach)
-No forced adherance to required/optional field specifications (just b/c CustomValueCoded is required doesn’t mean I want to use it).
-Ability to change on your time frame (enhancements are on your schedule)
-Ability to use a single document (order, order response, invoice, etc can all be merged into a single document for easier maintenance - since you do not have fields that are designed for other customers)

CONS:
-No adherance to a standard, so a map step is always involved (i.e. your XCBL transactions will need to be mapped every time, rather than allowing one XML flavor through without a map step)
-New developer familarity with custom practices (although most likely a VERY small issue)
-Future maintenance will rely on optional fields (in order to reduce re-mapping/regression testing, new fields may need to be optional)

Hello,
I like to build my canonicals in pieces and glue them together. This helps to in adding new feature field sets. I also like to use lists and tables to store very related sets of some kinds of data. Here is an example:
I would make an order out of a header and a detail portion to help share some parts and allow others to be seperate.
I would have an attribute table instead of individual attributes so that if I want to add a “PO” to an item, there is no change to the document, only an extra reference in a lookuptable on the processing service side.

I have had this need come around as I work on EDI (X12,EDIFACT) and there are so many options between versions that you need a glue in structure to help make things work. Good day.

Yemi Bedu

Hi All,

I prefer custom approach, because in our case:

I work with a lot of different formats in one single application and there is no standard which can fit to all our requirements. Just I convert all messages to internal format on the input and then make some computation with data and then convert to output message format and send. It is much easer to change internal formats. In this way application dose not depending from other external suppliers, this is very important because in case of critical issue can be solved faster. We can tune up performance of application, because a sources code is ours. There is a very big disadvantage, support activities are increased, but everything depend from application goals.

Regards,
Krasimir Zlatev