This week I spend some time on writing a functoid that retrieves the value of a variable in an orchestration. Lets take a look on the functoid’s usage first.
Usage
This is the declaration of a string variable ‘lastName’ in a very simple test orchestration:
This is the expression shape where the value of that variable is set to my last name:
This is the map that is executed using a transform shape right after the expression shape above. The map contains the variable retriever functoid. It has one parameter that takes the name of the variable to fetch.
Please pay special attention to the icon because that bloody thing took me 50% of the development time. The result shows why I try to stay away from UI development as much as possible. 
Finally this is the Xml message returned from the orchestration via the file adapter.
Disadvantages
At first I was a little excited that I got this working. I did some testing with different orchestrations and it seems to work OK. After a while (and thinking this over) my excitement was tempered because I think the functoid has three big disadvantages:
- Although questions related to this popup regularly in the BizTalk newsgroups I could not think of any real world examples. The sample above could also be implemented by using a message assignment shape after the map. In the message assignment shape the value of the variable can be assigned using xpath, properties or distinguished fields. The only way the functoid can be useful is when you need an orchestration variable value in a map to do some processing while the actual value is not mapped to the destination schema. But then again there are other ways to implement that. (Using a helper message and a multi message map).
- The functoid code contains a considerable amount of reflection code. I didn’t do any performance tests but it is obvious that reflection comes with a cost. So in terms of performance it will probably be much better to use alternative methods.
- This is probably not supported by MS. Mainly because it uses XLANG code which is normally hidden from the developers.
These disadvantages make me conclude that this functoid is not very useful in real world scenarios. I really want to know what others think about this. So whether you agree or don’t agree please share your thoughts on this!
The other way around
Now that I figured out a way to access a variable it is a small step to take this a little further and build a functoid that WRITES the value of a variable in an orchestration. I didn’t implement such a functoid because of above mentioned points. I also think writing, as opposed to, reading is very tricky because you need to take things like serialization and locking into account.
If your still not convinced that you should not use this you can download the functoid “dll” from here.
Installation instructions:
- copy the .dll to the ‘Mapper Extensions’ folder which resides in the BizTalk installation folder.
- put the .dll in the gac.
- Open a map in Visual Studio, click right in the toolbox area and choose the functoids tab.
- Browse the the functoid dll in the ‘Mapper Extensions’ folder to add it to the toolbox.
The source is also available here. It is build using BizTalk 2006 R2.
Posted by Randal van Splunteren 
) I asked the real expert (Yossi) to validate my results.
RSS feed
