In BizTalk Server, modularity is achieved by having one orchestration invoke another. While the Call and Start shapes might look similar in the toolbox, they behave very differently under the hood. Choosing the wrong one can lead to performance bottlenecks or logic errors.
BizTalk assigns one thread for every orchestration, even if you are using a parallel shape inside your orchestration!
📝 One-Minute Brief
Choosing between the Call and Start orchestration shapes depends on your need for synchronicity. Call Orchestration is synchronous; the parent waits for the child to finish and can receive out or ref parameters. Start Orchestration is asynchronous; it “fires and forgets” the child process, allowing the parent to continue immediately. This post breaks down the technical differences, impact on variables, and performance implications of each.
When you use the Call Orchestration shape vs the Start Orchestration shape?
The way BizTalk handles messages internally is different when it comes to calling or starting orchestrations.
Call Orchestration will use the same thread to run another orchestration, while using Start Orchestration will create a new thread to run the started orchestration.
A Call Orchestration returns the control back to the caller. A Start Orchestration shape starts the orchestration in a non-deterministic way.
As a conclusion, Call Orchestration will be a synchronous operation where the caller waits for a response, while Start Orchestration is an asynchronous operation.
Call Orchestration
- Will reduce latency as call orchestration doesn’t go via the MessageBox.
- Possible to pass all types of parameters.
- Call shape will tightly bound orchestration.
Start Orchestration
- Allows executing orchestrations asynchronously.
- Will increase latency as the start orchestration call goes via the MessageBox.
- Possible to pass all types of parameters. No return param is supported.
- Start shape will tightly bound orchestration.
Short hint
If you call an orchestration from another project, you have to set the Type Modifier property to public. Otherwise, the orchestration will not show up in the dialog where to choose the orchestration you call.
The Performance Impact
If you have a high-volume system, Start Orchestration is generally more scalable because it doesn’t tie up the parent’s resources. However, if you “Start” too many instances at once, you can put significant pressure on the MessageBox. Call Orchestration is safer for maintaining tight control over the sequence of events.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
