BizTalk Server: Using an Orchestration Sync or Async

Article
1/17/2024

One-Way, Two-Way, Three Ways For Orchestration

Sometimes, we have a business process that will service clients that use both a Synchronous and Asynchronous protocols, HTTP and MSMQ for example.

Ideally, this translates into a single Orchestration flow, maybe even several Orchestrations that perform this process. The sticky problem we face though is the initial Orchestration cannot be Activated with either a OneWay or TwoWay Port.

If we have only one kind of port, we could use the standard pattern, when we bind a port to orchestration at run-time. For example, for OneWay orchestration port we can bind File, FTP, MSMQ physical port. For TwoWay orchestration port we can bing WCF, SQL, SOAP physical port. But we cannot bind, for example, a TwoWay port to a File physical port.

One solution is to create orchestration that can be activated by OneWay or TwoWay ports. This generalizes our architecture.

One Orchestration, Two Port Patterns

First, let’s see what happens when this is configured in the Designer:

At build-time, the compiler kindly lets us know that:

error X2145: incomplete requestresponse operation; missing 'send'

This is a simple control flow error. While we may know for sure how the flow will always go, the compiler doesn’t.

One Process Orchestration, Two Port Pattern Orchestrations

We can solve that problem by adding one layer of abstraction between our business process and its external communication.

In this example, the ‘business process’ is nothing more than a Construct Shape with a Transform.

The thing to note is that the business process Orchestration is not Activated by a Port, it is a Called Orchestration so the Messages are now Orchestration Parameters.

For this example, we’re passing in AddRequest while AddResponse is an out variable.

Port Pattern Orchestrations

To Call the business process Orchestration we have a choice between one front-end Orchestration or two front-end Orchestrations. Which we choose depends on the production requirement.

One and Two Way in Production

If our application needs to support both Sync and Async processing in production, we can accomplish that with one front-end Orchestration like this:

This Orchestration is part of the main Project or Orchestrations Projects and is deployed as part of the whole application.

Two Way in Prod, One Way in Test

For cases where the application will only support Two Way Ports in Production, but we still want the convenience of a One Way interface for testing, we implement the patterns in two separate Orchestrations and in two separate Projects.

This facilitates testing because it eliminates the requirement to always use the synchronous ports which may require additional setup or infrastructure. With two One Way Ports, we can use the File Adapter instead of the actual LOB app or a special test client.

The test project would be configured to Deploy to a separate Application in BizTalk Administrator as well so when we generate .msi’s and Bindings, it is not included.

Now, to Call the business process Orchestration, we use two separate front-end Orchestrations, one with a Request/Response Port and the other with a Receive Port and a Send Port.

One Two-Way Port.

Two One-Way Ports.

When Deployed in DEV/TEST, we can run our single business process when called from clients that use either Synchronous or Asynchronous protocols.

Just to note, for the Called Orchestration, you do not need to Reference the main app in BizTalk Administrator.

Share via