BizTalk enrichment pattern without Orchestration

One common pattern in BizTalk is to enrich a message with information that it does not have. For example if you receive a customer update from your web site and you need to update the ERP system.

Problem is the web site does not know what the customer number is in the ERP system, it only knows the web customer number.

In this scenario one usually has a side system in sql server containing a mapping between the two numbers. The common way to solve this is to create an orchestration that calls the sql server to retrieve the ERP customer number, the last step in the orchestration is to map the sql response with the original web message.

As the title shows my solution does not use an orchestration, instead it uses a WCF behavior.

The WCF behavior has two properties

  • MapName. Here you must add the full name of the map. That means full name of the map + the name of the assembly.
  •  Namespace. Add the namespace that the new .merged, message should have. The root node is always RequestResponse in this implementation.

Enrich_BehaviorProperties

What we do is to intercept the request message before it is sent to sql server in the BeforeSendRequest method.

Enrich_BeforeSendRequest

The method TransformMessage executes the BizTalk map which you would normally do in the send port, but as we want to save the original message we execute it in the BeforeSendRequest methodinstead.

I have also created a custom stream that allows you to stream an XmlDictionaryReader as the class BTSXslTransform , Transform method, only takes stream as input.

I have written an earlier post on how to execute a BizTalk map in BizTalk pipeline component, you can read it at   https://fernandodosanjos.wordpress.com/2014/07/16/executing-biztalk-map-in-pipeline-with-arguments/.

The original message, not the sql request, is returned in the BeforeSendRequest method which is later on available in the AfterReceiveReply method.

Enrich_AfterReceiveReply

The AfterReceiveReply is executed when the response, reply, message is returned, the parameter correlationState contains, in this case, the original message.

Here we merge the original message with the response message that could either be a valid sql response message or a fault message.

I have written an earlier post on how to merge request and response messages similar to this post, you can read it at http://code.msdn.microsoft.com/Wcf-merge-request-response-37e7801b. The post explains how you create a schema for the merged messages and how to handle fault messages.

Download code

As always i hope for some feedbackon how to improve the solution.

Happy coding

Leave a comment