biztalkbiztalk-2010biztalk-2013biztalk-2009biztalk-mapper

BizTalk core format: redundant but all according to standard or "keep it simply stupid"?


I'm quite new in BizTalk mapping and my question now is:

Let's say that I need to receive UBL document, convert it to my Biztalk Core and send out same UBL. Of course I can perform 1:1 UBL->UBL without core format but I may need this core if I need to send out something else - EDIFACT, OIOXML, whatever else, so I believe it's a good practice to use core. So it looks like UBL -> Incoming map -> Core -> Outgoing map -> UBL.

So the question is: what is the best practice to create core format schema?

My incoming file must meet all OIOUBL standards so I have to use something pre-defined as XSD schema (e. g. like this: http://www.oioubl.info/Classes/en/Order.html). The same for outgoing file.

But on the other hand I know for the fact that in my case this standard contains a lot of redundant fields. I will never use some of these fields or parameters; some other are constants and there's no need to store it - we can just define default values in outgoing map...and so on.

So my question is: what is the best practice to build core file? Is it better to use full UBL xsd which meets all standards, even if it's redundant (in this case it will simplify incoming and outgoing maps - I can just use 1:1 mass copy) or it's better to KISS and to simplify core as it's possible using only fields that I really need and adding something one by one if I need anything else?

This question is not about code - just about what is the best practice.

Thanks. I would appreciate any advice.


Solution

  • Best practice would be for the internal core or canonical schema usually to match the inbound external schema (apart from target namespace) so you don't lose any data from the first mapping, as quite often when you find you do need to send it to another system and need another outbound mapping the fields you require might include on that you didn't for the original system. Of course to any rule there is an exception, and it is a matter of judgement as to when it isn't appropriate to do this.