The project I am working on will connect a new partner (with new messaging standards) to our existing BizTalk hub. Because the new project and the already existing operations share the same message types (whithin the organization), we decided to give the message types an upgrade.
One of the main reasons for this is the problems we had before, connecting BizTalk to a Siebel system. BizTalk uses as a message type identifier the root node name and the namespace of a message (and the port to which it was sent). In older releases (7.5) of Siebel, it was not possible to provide namespace information in the messages in a form that can be used by BizTalk. Things have improved since a recent upgrade of Siebel to 7.7 (Enterprise). We decided to use those new possibilities of namespaces in all Siebel to BizTalk messages, including the already operational ones.
Now, here is a serious warning: Only decide to change namespace (message type) information in operational BizTalk processes involving complex maps, when
- you are an experienced BizTalk developer
- you understand the intricacies of message types, subscriptions and namespaces
- you have ample opportunity (available time and budget) to realize the changes
Make sure that you have tested all affected maps in detail, and understand the purpose and functionality of all components of the map, before you even start making changes. This includes having test data available and having backups of basically every development object.
This is what happened when we made the changes to the namespaces:
- Some changes to XSD's could not be done in Visual Studio, because they required mass updates of the tags in the XSD. We used a text editor to things like TagName changing into xsdLocal:TagName. We had examples of XSD's using the namespaces as required, and we could easily check the results of the changes to match those examples.
- Using a test orchestration, we checked the behaviour of the new XSD's when deployed. Do they subscribe to the messages as they will be sent (including namespace)? The properties “Attribute FormDefault“, “Element FormDefault“ and “Target Namespace“ of the node of the XSD play a vital role here.
- Though we thought we updated the XSD's consistently, the promoted and distinguished properties of the XSD's did not seem to work anymore. When requesting “show promotions“ in the XSD, all looked normal. However, in the node hierarchy (Visual Studio) of the XSD, the promoted properties did not show up with that special icon indicating that the element / attribute is promoted. Solution: remove all promotion information (including reference to property schema file) from the XSD and save it. Check the property schema for correctness (no reason to doubt that, but still...). Then, add the promotion information to the XSD again.
At this stage, all definitions looked ok again. Then, we started testing the maps. To my surprise, the maps that had been working correctly, did not lead to any result apart from the root node. The existence of the root node in the mapping result indicates that the namespace information has been included correctly in the definitions.
What happened?
- The maps were originally built some 18 months ago, before service pack 1 for BizTalk was installed (and also before some big patches to Windows Server 2003 were applied)
- The maps used the “Value Mapping (Flattening)“-functoid to map some date optionally available in the source message, or for conditional mapping.
- The maps combined information from various segments of a hierarchical source message into the (relatively flat) destination. We managed to do this without using too many “Looping“-functoids originally.
- The lack of “Looping“ functoids caused the target message to be empty after the changes. I had to add looping functoids for all segments in the destination message, with input from all relevant source message segments, including the root node.
- The next problem we ran into were the “Value Mapping (Flattening)“-functoids. During testing (or project building), we had errors like “Exception Caught: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index“ and “Exception Caught: Key cannot be null. Parameter name: key“.
- By replacing the “Value Mapping (Flattening)“-functoids with plain “Value Mapping“-functoids, we managed to resolve this.
- I believe this particular problem is related to the installation of SP1 on BizTalk. Before that, we had a working, not well-defined solution, which was no longer allowed after SP1. For the previously working maps, we apparently have been using some side-effect of the functoids, or something like that.