After running across this topic several times (and in several different places) over the past few weeks, I thought it would be worth writing up a quick blurb about it. This topic I’ve run into revolves around the parallel shape in BizTalk orchestrations and whether or not it actually provides you with parallel processing.
The answer is NO!
It’s a common (and understandable) misconception that the parallel shape in BizTalk orchestrations is there to allow you to setup and run concurrent processes. After all, one would think that that if we have a parallel shape, then we’d be able to setup parallel processing. I’ve seen several clients and partners try and use this shape to increase performance by processing large messages using parallel activities. This is NOT what the shape is intended for as it does not result in your activities being performed in parallel. Activities that you put in parallel branches will still execute one at a time, however they will not have to execute in any specific order. I.e. a process involving steps A, B, C could execute as BCA or CAB or ABC.
Now it is understandable if this seems odd. It would seem obvious that a parallel shape should result in parallel processing. The trick here is to understand that what the parallel shape is referring to is a parallel activity in a business process and not a parallel activity in your computer program. The parallel shape isn’t designed to instruct the system to run multiple threads, it is designed to allow multiple business activities to occur independently of each other without one having to wait for the other to complete.
A great example of this would be something like an online insurance quotation website. This site would likely want to use BizTalk to implement a scatter-gather pattern. Following this pattern, our online web application would submit a single message to BizTalk. This message would contain all of the information required to generate a quote for our end user. A BTS orchestration would be required to broadcast this message out to multiple external insurance companies and then wait for a message to come back from each one. (Example shown below).
(Note: I’ve borrowed this picture from www.enterpriseintegrationpatterns.com a great site)
Now because our orchestration will be waiting for external systems to respond, we won’t have any control over the order in which each of these vendors will respond. You wouldn’t want to create an orchestration that laid our your three receive shapes in sequence. Instead we’ll use a parallel shape and put each of our receive functions in a separate branch. This will allow the orchestration to receive the return messages in whatever order they occur. We will still be receiving the messages one at a time, but we will be able to receive them in any order.
So keep this example in mind when using the parallel shape. You can’t think of it as a low level instruction to BizTalk to launch two processing threads. You need to be thinking at a higher level in the processes stack and remember that the parallel shape is referring to the activities happening with the business process.
It is an important concept to understand as it can have performance impacts. In my next post, I’ll look at a scenario where improperly using the parallel shape will actual decrease your performance instead of increasing it!
Cheers and keep on BizTalk.