I just found another little gotcha when working with Orchestrations in BizTalk. If you create a variable that’s a string type and assign its initial value, you’ll want to make sure that you put quotation marks around the value. I failed to do so recently I had errors similar to these pop up when attempting to build the project:
identifier 'YOUR_VARIABLE_VALUE' does not exist in 'YOUR_ORCHESTRATION'; are you missing an assembly reference?
cannot find symbol 'YOUR_VARIABLE_VALUE'
This can be kind of confusing. Should you come across the same problem, the simple solution is to wrap the value in quotation marks, just as I had advised for orchestration filters in a previous article.
Just recently a colleague developed a BTS project with a large number of Orchestrations. When attempting to view any of the orchestations in Visual Studio, we found that instead of the Designer we know and love so well, we were presented with a massive amount of text that looked something like this (sorry for the redacted stuff–NDA, you know):
Naturally we were perturbed. Although I’m sure everything we need to know is in there, the designer is the much better (and intended) way to view an orchestration. Fortunately for us, Ian had the same problem and posted this on Stack Overflow.
Basically, you need to look at the .btproj file in a text editor and comment-out or remove all of the elements called SubType that are associated with the .odx files and are like this:
<SubType>Designer</SubType>. Once that’s done, the orchestration will show up in the designer again.
Thanks to Ian for this tip!
On some days, odd or unpredictable behavior seems to be the norm more than the exception when working with BizTalk Orchestration.
Recently, I’ve been building out an orchestration using a convoy pattern to aggregate messages before sending them on (See Richard Seroter’s excellent article on this pattern). An often-used part of this pattern (not used in Seroter’s article) is to place a Listen shape in the orchestration to set a time-out for how long you’ll wait for a new message before packing things up and moving on. Here is how we first implemented the Listen:
However, we found that in our loop that contained the Listen, the orchestration would execute the Receive portion first, even though a message had not come through. This caused other code in the loop to execute that should not have, or at least not yet. In our case, the orchestration placed every message in the aggregation twice.
Not so good…
Anyway, weird problems often have simple solutions. We just reversed the branch-order for the shape, causing (I think) the Delay to be accounted for first. So our new Listen looked like this:
And, for whatever reason, this seemed to work. If I find out more detail on the “why” of this, I’ll post a comment here. If anyone else knows, I’d welcome a comment or email.
For whatever reason, even as we move into .NET 4 and BizTalk 2010, you still cannot create an orchestration variable of a Generic type. It is my (somewhat) humble opinion that this is a major shortcoming in XLANG. If you’re like me, you rely pretty heavily on Generics when writing collections in .NET and as such may find it pretty frustrating to work with orchestrations at times.
Fortunately folks like Andrew Rivers have presented a fairly simple solution: just create a class that inherits from the Generic type that you’re interested in and create a variable of that particular type. In a previous article , as an example, we use a Generic Dictionary object to pass facts and tag info into some code that calls the BRE. Now, we can not only use this code from a .NET client as advertised in the article, but we could also use it from Orchestration as well, which would be handy when the Call Rules shape can’t be used.
BizTalk 2010 Recipes: A Problem-Solution Approach by Mark Beckner is a great book for the BizTalk developer who would like a basic step-by-step instruction list or a reference book on how to perform most tasks in the BizTalk environment. BizTalk is a large and difficult product to learn and master and Beckner’s book provides a great resource for the beginning to intermediate level BizTalk developer to do just that.
The layout of the book is very straightforward. A standard BizTalk task is presented, step by step instructions are provided to complete the task and then an explanation of some of the major technical points is given. I found the first section of the book on the new features of BizTalk 2010 to be particularly useful and recommend it for any user of previous BizTalk versions to get up to speed.
Beckner writes in a very accessible style. The book is an incredibly easy read. The examples are appropriate and “real world” enough to be useful and the explanations are technically sound and understandable. It is also covers all the basic functionality within BizTalk–schemas, maps, orchestration, BRE, etc. as well as some of the less-used features such as EDI.
Although I really liked Beckner’s writing style and the step-by-step approach to performing BizTalk tasks, I felt that the book does in some ways falls short of the goal provided in the title. While I was looking for a resource for discussion and insight into solving more Business or Architectural oriented problems, I found the approach in BizTalk 2010 Recipes to be more of a run-down of BizTalk features and a description of how to use them.
That is a valuable service all in itself, and I highly recommend this book for that use. However, if you’re really looking for something to help with BizTalk “recipes” from a business problem or architectural patterns point of view, another book such as Seroter’s BizTalk SOA book might serve that purpose better.