Friday, November 28, 2008
If my previous posting was kind of sophisticated, this one is a lot more down-to-earth and basic...
I've been struggling during the morning trying to use the "Call Orchestration" feature of BizTalk. A pretty straightforward feature. But, I couldn't just get it to work. If the called orchestration was in the same project as the calling orchestration, it worked Just Fine<tm>, but as soon as I tried to put the called orchestration in its proper place, it just failed.
The solution? Well, I got the answer from someone who is much more experienced with BizTalk than me: Make the called orchestration public. This is pretty straightforward if you think about: orchestrations are really standard CLR classes (even though not generated manually by writing C# or VB.NET code), and as such, they have visibility parameters just like classes usually have.
If it doesn't immediately work after making sure the callee orchestration is public, try rebuilding the project that is referring to the callee. Yes, you heard me right. Even thought it might fail (since you are likely to have a Call Orchestration shape that is unconfigured), something happens when you build it that sometimes makes it work.
Restarting Visual Studio is also something that can be helpful. 
For me, in this specific case, building the project didn't work straight away - one of the files was being locked. But when I restarted Visual Studio, it found the callee orchestration anyway, so - problem solved.
I ran into a strange issue the other day with BizTalk Server 2006 R2. Imagine a map (.btm file) that takes multiple messages as its input. Imagine two of those messages being of the same document type, having the same schema. Now... make the first message be normal, like this (this is an excerpt from the full multipart input message to the map):
<InputMessagePart_2>
<ns4:stock_warehouse_fetch_response xmlns:ns4="http://StockWarehouse">
<ns4:stock_warehouse stock_warehouse_id="170A9532-BD20-11DD-85B6-3DFC55D89593"
company_id="1EBB0C44-BD20-11DD-9025-69FC55D89593"
[... More attributes existed but have been removed to preserve
the integrity of the customer ] />
</ns4:stock_warehouse_fetch_response>
</InputMessagePart_2>
<InputMessagePart_3>
<ns4:stock_warehouse_fetch_response xmlns:ns4="http://StockWarehouse">
<!-- This is the part that causes the problems -->
</ns4:stock_warehouse_fetch_response>
</InputMessagePart_3>
When I used the message above (with more messages in the multipart message and so forth), a very weird thing occured: the map output was completely empty, the only thing that remained was the root node! Obviously, many of the input elements existed in the input messages, so this is clearly a bug in BizTalk (IMO). The problem first occured when running the application in BizTalk Server 2006 R2, but was reproduced with the Visual Studio-integrated "test map" function.
The solution? Add a "content node" in the document, like below. It seems like BizTalk really, really dislikes documents with only a root node. There must be at least one content node in all the input documents to a map. Otherwise, the map output is completely eradicated, except for the root node.
<InputMessagePart_3>
<ns4:stock_warehouse_fetch_response xmlns:ns4="http://StockWarehouse">
<ns4:stock_warehouse></ns4:stock_warehouse>
</ns4:stock_warehouse_fetch_response>
</InputMessagePart_3>
Well, that's it for this time. I hope this helped you, it would have helped me.