Professional BizTalk® Server 2006

13.2. Looping/Storing Messages

Often, and especially when dealing with sequential convoy scenarios, you need somewhere to store multiple messages. Take a look at the orchestration fragment shown in Figure 13-1.

Figure 13.1. Figure 13-1

As you can see, each loop iteration invokes the Receive shape to receive another message and store it in the same BizTalk message variable, thus losing a reference to the message stored in the last iteration.

XLANG doesn't support arrays, so you cannot leverage an array of BizTalk messages to store each message. (You could use a .NET ArrayList, but iteration is hard without using nonserializable types.) However, you can take advantage of a couple of workarounds, depending on your requirements.

You must bear in mind, however, the memory and orchestration state overhead of such a solution. Obviously, storing many messages in this way will use increasing amounts of memory, so you should ensure that you fully test this aspect of your solution. In addition, each extra message stored through either method will incur extra orchestration state, which will be persisted during dehydration, thus increasing SQL I/O and CPU overhead. While this isn't necessarily a problem, you should bear it in mind and potentially make use of the virtual stream approach, as appropriate.

• Use a multipart message — As the name implies, a multipart message can contain any number ...