Biztalk Maps Incrementing Variable Value in Multiple instances if Map| Orchestration Variable retriever Functoid

Q:
Hi All,

I have a following scenario.

I have a map which gets executed multiple times. I want to use one variable and its value which I should be able to increment for each execuation of map.

This can be done using orchestration paramaber or retaining value of static varible. (i am not sure).

This is urgent. Your help will be greatly appreciated.

Ans:

To pass a variable into a map you can either:

Send it in as part of the original XML input (naff if you don't want to start bolting fields onto your schema and injecting data)
Send it in as a second input message to your map (only possible if you use an Orchestration to call your map (or unless you're willing to write your own wrapper)).
Use a static variable in a .NET helper class to store your value (won't work if your map is running on different host instances)


Detail:

Source : Randal Van Spluttereen's Blog

You could try http://biztalkmessages.vansplunteren.net/2009/04/05/orchestration-variable-retriever-functoid-and-why-you-should-not-use-it

or

Add a .NET class library to your solution and create a class similar to this:

public class MapHelper {
	private static int _counter = 0;
	public static int GetNextCounter() {
		return ++_counter;
	}
}

Build and GAC your project, then use the Advanced Functoid shape to call an external .NET assembly, browse to your built library and select away.

The GetNextCounter() method will increment and return the next number.  You might want to expand this to provide some form of reset etc.

Remember, this is only available during the scope of the static object - so if you have any sort of complexity in your design or infrastructure you'll need to go to an external data store to ensure continuity.

source:  MSDN


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:

1. 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). 
2.  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.
3.  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:

• Orchestration variable retriever functoid (and why you should not use it)

• 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.