I had a case today where I was mapping two fields N01 and N02 to two side by side fields in the output schema.
N01 was working, and N02 wasn’t. Both were under an condition that a certain variable MESSAGE_TYPE was equal to a certain value. Yet one worked, the other didn’t? How did I go about debugging this?
I did a right click “Validate Map”, and opened the XSLT. I searched for N01, and found the following.
In the image below, I have highlighted some of the code. The N01 is wrapped by one IF statement, so I would expect the same IF statement around N02.
But when I look at N02, I see to nested IF statements.
You can find the variables to understand what the tests are. So I searched for the extra test around N02, i.e. the variable v16, and found this.
That jogged my memory. I had another page on the map, where we were using a “trick” to not map certain fields.
This was a RosettaNet schema, and it contained many nodes with default values that were filling up the output document with unnecessary junk. The “trick” is to map “false” to the fields you don’t want to map. So I had essentially told the map that I did not want to output this element (even though I had mapped something to it).
Of course, this is only one small case, but I hope you like the methodology, and can use it to apply to your own debugging. Learning XSLT of course helps. The XSLT generated by BizTalk can be a little confusing because of all the “userCSharp” routines, and all the variables, but it can help you find issues in your map while testing.
Also note, I would not have found this issue unless I was carefully unit-testing. I hand-crafted 5 different input test files, and was running each one of them through the “Test Map” feature, and manually scanning the output.