Archive | SOA RSS for this section

Dynamic Map and Pipeline Execution in a BizTalk Orchestration: A Case Study

Sometimes you just don’t know what needs to happen until it’s time for it to happen.  Most business process software requires the ability to alter its path while en route to wherever it may be going.  Recently, I worked on a project that had a similar requirement.

Here’s a very high level view of the process/requirements:

  • Data is received in the form of a message in a canonical format.
  • Based on the client identified in the message, a number of output documents would need to be generated.  The number and type must be changed easily as new clients came on board or as old clients added or changed output types.
  • After the messages are sent, the canonical message must be allowed to be processed further from its original state.

In most cases, the ESB toolkit would have been a great fit for this type of work except for a couple of things:  additional processing needed to take place against the original canonical message after the maps and pipelines had done their work; and the number of maps and pipelines that needed to be executed against the canonical schema was not known until runtime.

For our solution we decided to use a single Orchestration for the ability to maintain state of the original message (the last requirement), but also for ease in development.

Once we received the canonical message, the first step was to retrieve a list of output messages that would be required for the given client.  Each output needed two pieces of information:  the map that would be required to extract the specific data from the canonical message, and the special pipeline required to create the flat-file or other output needed (as necessary).  We used the BRE to determine which maps and pipelines were needed for the outputs.  Creating some fairly simple rules, we generated output that conformed to the following schema definition:

service map schema

As a point of interest (and necessity), we did not use the CallRules shape in BizTalk to execute the policy that returned our map list document.  We used .NET code in a separate assembly accessed from within an expression shape.  For info on how to do this, see my previous post on Calling the BRE from .NET Components.

Once it was known which maps and pipelines needed to be executed, it was just a matter of doing the work.  A looping structure was used to iterate through each output document required. 

Once we retrieved the info required to identify the System.Type of the map from our list, we could then run the map.  Inside a message assignment we executed the following code to create the mapped output.

We then needed to execute the pipeline.  Once again, we used our BRE-generated document to tell us which pipeline to use.  After capturing the type, we executed the pipeline:

After pipeline processing, we could then send the pipeline output to where it needed to go through a dynamically-bound port, once again using the BRE to get the information required to determine the correct location.

We then took the original message and sent it on its way for further processing.

For more info regarding dynamic map execution or calling pipelines from within an orchestration, see these MSDN articles:
Maps:  http://msdn.microsoft.com/en-us/library/aa950573(BTS.70).aspx
Pipelines: http://msdn.microsoft.com/en-us/library/aa562035(v=bts.70).aspx

Itinerary Pipelines and Losing BTS.MessageType Promotions

Part of the appeal of using an ESB architecture is that we can create a loosely-coupled system where such contractual data as a Message Type doesn’t have to matter at all.  But at some point, even the most loosely-coupled architecture must define a physical implementation. 

In the ESB toolkit, this activity takes place within specialized pipeline components.  These components perform such actions as loading itineraries, advancing a message through an itinerary, making routing decisions, and executing transformations.  It gains flexibility by using tools such as BRE and UDDI to resolve locations, select maps, etc.  You get the idea. 

And almost everything is done in a pipeline.

In an inbound pipeline like ItinerarySendReceive, for example, properties such as BTS.MessageType get promoted in the XmlDisassembler in Stage Two of the pipeline. But it is in Stage Three where the ESB Toolkit’s Transformation service is invoked.  Transformations, of course, usually result in a change in MessageType.  This is where there may be a problem and a possible bug in the component.  When the message changes, the BTS.MessageType property changes to the correct type as it is supposed to, but the property is no longer promoted.

Most of the time, especially in pure messaging scenarios, this isn’t an issue.  But orchestration is one area in BizTalk where Message Type does matter most of the time.  In fact, the message type is a key part of subscriptions that are used to activate an orchestration!

Here’s a sample itinerary that presents a problem:


Note that this itinerary ends with an orchestration that is immediately preceded by a transform.  In this example, the orchestration may not get activated because the MessageType portion of its subscription is not satisifed.  The message is suspended with the following (familiar) exception:

The Messaging engine failed to process a message submitted by adapter:YOUR_ADAPTER. Details:The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted. Please use the Biztalk Administration console to troubleshoot this failure.

 

Fortunately, there’s a work-around that you can use to get past this hurdle.  Simply using a generic XmlDocument object as your inbound message will solve this issue because all messages in the BizTalk Message Box are of this type.  You’ll need to take obvious caution here–make sure the filter expression on your orchestration is well-defined enough so that it doesn’t attempt to process unwanted  messages.  Orchestrations used by ESB Toolkit Itineraries will have subscriptions based on ServiceName, ServiceState, ServiceType, and IsRequestResponse so this is often not an issue.  Another cautious step to take will be to assign the XmlDocument to a message of the desired type early in the orchestration to avoid other type-related issues in processing.

Good Luck!

BRE Rules Evaluation in ESB Toolkit: Document Types Are Different than Expected

One thing that is incredibly useful about the use of an ESB Toolkit Itinerary is that decisions can be made at runtime regarding the routing of messages or selection of transformations to execute against messages.   For my projects, the most useful tool to facilitate this resolution has been the Business Rules Engine that comes with BizTalk.

When you use a BRE resolver, you have the option to select whether the Rules Engine will use only the context of the message you pass into the engine (the default setting) or you can have the Rules Engine use the content of the message as well by setting the useMsg attribute to true. 

I have not experienced any problems when using message context as evaluation criteria in my rules but until recently I have been unsuccessful in using the message content as part of  the evaluation criteria.  The trouble I had was that regardless of how I arranged the Facts in the Business Rule Composer, the evaluation always returned false and the rule never fired while processing the message.

This is truly a frustrating scenario.  Here is the error message you will  most often see (or something similar):

Error details: There was a failure executing the response(receive) pipeline: “Microsoft.Practices.ESB.Itinerary.Pipelines.ItinerarySendReceive, Microsoft.Practices.ESB.Itinerary.Pipelines, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “ESB Dispatcher” Send Port: “YOUR_SENDPORT_NAME” URI: “YOUR_URI” Reason: Transport location could not be resolved from teh resolver string BRE:\\policy=YOUR_POLICY;version=;useMsg=true;messageFile=;recognizeMessageFormat=false;.

 

Fortunately I found this interesting tidbit: the Document Type that the Itinerary components send into the BRE is not what you expect.  Instead of the Document Type that shows up in the Rules Composer  when you select your fact from an XML schema (like the schema name, for example), it sends in Microsoft.Practices.ESB.ResolveProviderMessage instead.

So what do you do?

One work-around is to replace the Document Type attribute in the BRE Rule Composer from its default to Microsoft.Practices.ESB.ResolveProviderMessage.  This will allow the rules engine to recognize the document type and fire rules correctly as it processes the message . 

Here’s how: 

  1. Open the Business Rule Composer
  2. In the Facts explorer, select “XML Schema” and load whichever schemas you will need to work with.
  3. Select the schema name.  Note the Document Type property in the Properties Window.  It will be the same name as your schema.
  4. Change the Document Type property’s value to Microsoft.Practices.ESB.ResolveProviderMessage for each schema. 
  5. Drag-and-Drop nodes from the schema into the Conditions section as you normally do.  Note that the new type is represented with the XPath in your conditions.

When the rules execute, it should now be able to find the referenced nodes and evaluate your rules correctly.

WCF in IIS Gotcha: Enable the Right Protocols

Sometimes tough problems have simple (usually overlooked) solutions. If you find that you have WCF code that executes well in the Visual Studio web server only to fail to load in IIS, you may have a protocol problem. I tried running a service that supported multiple protocols only to find this exception when loading to IIS 7:

Could not find a base address that matches scheme net.tcp for the endpoint with binding NetTcpBinding. Registered base address schemes are [http].

You may not think about it much, because most of us are used to running all our IIS stuff using only HTTP.  One nice thing about WCF however, is that a single service can support multiple protocols (in this case netTcp and wsHttp).  But IIS must have all protocols registered so when my service, which also supports netTcp, tried to execute in IIS it fails to load.

It’s a simple fix.  Here’s all you need to do:

  1. In IIS, right-click your application.
  2. Select “Manage Application | Advanced Settings…”
  3. Add “,net.tcp”  (leaving off the quotes) to the end of the text in the “Enabled Protocols”

Your application should work after this.

%d bloggers like this: