Adding BasicHttp Binding OnRamps to ESB Toolkit

ESB Toolkit comes with few default OnRamps which use WSHttp bindings.
If you want to use BasicHttp binding, you need to do following:

1. Run the Biztalk WCF Service Publishing Wizard to create a new Service

a. Choose option Publish Schemas as WCF Service.



b. Give the Service your desired name. Keep Operation name as "SubmitRequestResponse".

c. For Request and Response choose schema: Microsoft.XLANGs.BaseTypes.dll#Any



2. Modify the Web.config file of the new Service.

a. Under System.ServiceModel element add:

<extensions><behaviorExtensions><add name="soapHeaderMetadata"
type="Microsoft.Practices.ESB.ServiceModel.Helpers.SoapHeaderMetadataExtensionElement
, Microsoft.Practices.ESB.ServiceModel.Helpers, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35"/></behaviorExtensions></extensions>

b. Under behaviors add:

<soapHeaderMetadata enabled="true">
<soapHeaders>
<add headerTypeName="ItineraryDescription" operation="SubmitRequestResponse" message="ItineraryDescription"
operationType="Input"
targetNamespace="http://schemas.microsoft.biztalk.practices.esb.com/itinerary"
xsdFileName="ItineraryDescription.xsd"/>
</soapHeaders>
</soapHeaderMetadata>

3. Once the Wizard completes, it will create a Service in IIS and a Receive Location(On Ramp). 

Make sure to create a seperate App Pool for this new service. You cannot have both the services(ESB default and new one) runnning under same App Pool. 

4. On Ramp needs to be modified now. 

a. Modify the pipelines. Choose the same pipelines as in default ESB On Ramp(ItinerarySelectReceiveXml). 

b. Configure the adapter. You can keep Security settings according to your need(None, Transport etc.). Message tab needs to be modified same as WSHttp adapter on default On Ramp. 

This basicHttp On Ramp is now ready.

Itinerary Broker Service - Routing on Context Property

Recently, I worked on a Biztalk project which used ESB toolkit 2.0 for integration. I was working on a scenario where I had to make routing decisions, based on some property within the message, in Itineraries.

I knew that Itinerary Broker service shape should be used to make routing decisions in Itineraries. Itinerary broker services provides Message Context resolver which can be use to resolve destination on the basis of message context property.

So the first thing I did is, used property promotion in schema, to promote the message property on which routing had to be done. Then I created my itinerary using On Ramp shape to receive the message, broker service to route the message and finally the Off Ramp shape to send the message to destination.

However, after completing the itinerary, I realized that none of my filter condition was being set as true and I was getting below error:

There was a failure executing the receive pipeline: "Microsoft.Practices.ESB.Itinerary.Pipelines.ItinerarySelectReceiveXml, Microsoft.Practices.ESB.Itinerary.Pipelines, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "ESB Dispatcher" Receive Port: "OnRamp.Itinerary.Response" URI: "/ESB.ItineraryServices.Response.WCF/ProcessItinerary.svc" Reason: Error 197501: Cannot determine next service, none of the filter conditions returned true

On analysing the message in tracked message instances, I realized that the property on which routing was being done, was not at all promoted in the message.

Reason:
Since itinerary is executed in the pipeline, the property promotion has not occurred at the time when we are calling the broker service and hence we get this error.

Workaround:
The workaround is to include a map shape in itinerary before broker service. This map should do nothing substantial, it should map input schema to input schema itself.
Because of this map, the property gets promoted and broker service shape can now use this promoted property.




Another important fact:
As soon as you use the Broker Service shape in Itinerary, the Export Mode of the Itinerary changes to "Strict".

In strict mode, you cannot use the Off Ramp Extender shape to resolve the destination. You need to use a Messaging Extender in Itinerary to resolve the destination:



I hope this helps someone.