Multiple rootnodes in one schema in BizTalk 2004

Published Mon, Sep 20 2004 4:19 PM
BizTalk 2004 allows you to have multiple rootnodes in one schema. I thought that this was a nice way to capture a contract having multiple messagetypes in one document, so I use this in my current project. Since BizTalk identifies a messagetype by it's namespace/rootnode combination, I didn't really expect any problems with that.
 
But I just keep on running into issues that makes me wonder. The latest one I discovered just now.
 
I receive all message through the same receiveport and I want to map those messages to some central datamodel. Turns out that I can't. As soon as I specify one of the maps, the other ones dissappear from the list! Incredible. And I had more of such issues. I don't have the time to dive in now, but I hope to blog about those soon as well.
 
I just wonder if I misunderstand the value of multiple rootnodes and I shouldn't be wanting this or my approach in itself is good, but BizTalk is limited (and if so I like to know why). Any comments very appreciated.
by Carlo Poli
Filed under:

Comments

# Carlo Poli said on Tuesday, September 21, 2004 7:24 AM

Well carlo currently i am on a project with the same approach. Onde docspec with lotsa rootnodes.

The only thing I like about is is that we have only one XSD.

Maybe it is possible to just receive the messages. have a send port with a filter for every rootspec and have the send port map them
to the internal schema.

Send the uniform messages to a Que and have a receive again on the que.....

I dont know if it is possible to send a message back to the messagebox (kinda loopback send) otherwise you could pick up that message





# Carlo Poli said on Wednesday, September 22, 2004 7:22 AM

I now realise the comment above is complete useless......(maybe i should think twice before writing something)

But I got a mail yesterday that can be helpfull.


While there are actually some performance related reasons to put your maps in the receive and send ports, there are much better business reasons for doing it outside of your schedule. We tend to refer to mapping in receive and send ports as document normalization. In the case of receive ports, you are normalizing the documents from the format of your customers into an internal standard format. On the outbound side, you are converting out of your normalized format and into the specific format of your trading partner or internal application. If you embed the map in the schedule and the partner changes the format, not only do you have to rebuild the map, you have to rebuild the schedule to use the new version of the map. Also, what happens when you add a new partner with a new format. That is a new map and if you have embedded the map in a schedule, it means a new schedule. This is exactly why we added support for multiple maps (one per source message type) on the receive port so that you could create a single location for all of your partners and easily handle normalize into your internal standard formats. Putting these types of maps in schedules would be a bad idea. There are times when it makes sense to use a map in a schedule. When you need to generate a new message in the schedule and use the modified (mapped) contents of an existing message as the base. When you want to map multiple parts of a message into one outbound message (this type of mapping cannot be done in a receive / send port). There are performance gains which come from doing mappings in receive ports sometimes, but they are mostly around how many persisted messages your scenario generates and it is a bit complicated to explain. The actual mapping technology is the same. To keep your internal business logic from getting tightly couple with the document formats of your trading partners, you should do your document normalization (mapping) in the send and receive ports.”

The key take away from this post is that it is important not to tie your business logic to the format of one trading partner. Performance aside (for those of you who attended my perf talk at tech-ed, yes there are some perf benefits to doing this in the ports), the goal of this design is to make your system more robust and able to change as your business grows and adds new partners and also allow you to react easier to changes in your partners data formats. Brandon Gross comments (in Jeff Lynch's blog) that there are times when the "normalization" is quite complex and it is easier to model this in an orchestration than with our support in the mapper. It is true that there are cases when you simply have no choice but to do the mapping / data conversions in an orchestration, and in those cases, that is what you do. But in general, the best practice I am pushing forward here is a decoupling of your business logic from your partners data formats and so a more robust system.