Geeks With Blogs
Evan Koch Musings on BizTalk Server and SQL Server

At its heart, BizTalk is based on the publish/subscription model.  As messages come in to the message box, BizTalk checks to see what orchestrations have subscriptions that match the criteria of the incoming message.  This pub/sub model is opens up a new paradigm for developers in terms of programming.  For this example we’ll use the following process diagram for lending:


A developer could create one monolithic orchestration to handle all the tasks shown above.  The downside of this would be that the entire orchestration would have to be modified if steps were added to the diagram above, nor would we be able to easily facilitate reuse.  Another option would be for the developer to create an orchestration for each of the steps above and then another orchestration to call the others and pass information between them.  A more interesting option, however, would be to create separate orchestrations and have them activate as needed.

We can accomplish this by routing messages between the orchestrations.  Messages are routed based on their context properties, so we’ll add a Status element to our basic LoanRequest schema and make it a promoted property.


After the task is completed in each orchestration, we’ll create a copy of the message and update the status to indicate that the task has been completed.  After the new message has been created, it will be passed into the message box using a port that’s directly bound.   The following orchestration will be checking the messagebox looking for messages where the status indicates that the preceding orchestration has been completed. 

The following orchestration will have a receive port that’s directly bound to the message box.  The receive shape that’s connected to this port will have a filter that’s looking for messages where the Status context property indicates that the previous orchestration has completed.  For instance, we’ll look at the code in the Message Assignment block of the Prepare Loan orchestration.

 

Let’s also take a look at the filter expression for the Receive shape in the GenerateLoanDocuments orchestration.

So going back to the terms used at the beginning of this post, the PrepareLoan orchestration publishes a message to the messagebox which matches the subscription for the GenerateLoanDocuments orchestration and activates an instance of the orchestration.  Similarly, the GenerateLoanDocuments orchestration publishes a message to the messagebox with a Status value of “LOAN DOCUMENTS GENERATED” that matches the subscription for the ArchiveLoan orchestration and activates an instance to consume the message.

As mentioned earlier, this type of model can more readily accommodate changes to the process diagram.  We’ll use the updated process diagram below.

In order to handle this, we’d create an additional orchestration that handled the specifics of the Generate MIN logic and activate it with a receive shape that looks for messages with a Status of “LOAN PREPARED”.  After the MIN logic has been performed, it will create a new message with a Status value of “MIN GENERATED”.  Additionally, the GenerateLoanDocuments receive port filter would need to be updated so that the filter expression matched the new Status value.  The direct bound ports are only logical ports and have no physical representations that can be updated within the BizTalk Administration Console, so this change can only be made at design time within Visual Studio.

This pub/sub model could also be used to promote reuse in orchestrations.  Imagine that there was a new requirement that each step within the loan process be logged.  To accomplish this, we could create another orchestration  called LogProcess with a receive shape that had a filter on Status values of AUDIT.  Each orchestration could be updated to create a message for auditing with a Status value of AUDIT and send it to the messagebox before sending the other message indicating that the orchestration had completed its task.

Source code for this example can be found here.

Posted on Thursday, October 4, 2007 2:20 PM | Back to top


Comments on this post: Loosely Coupled Orchestrations

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Evan Koch | Powered by: GeeksWithBlogs.net