Anyone who has worked with the ESB Guidance Toolkit will tell you that the complex and troublesome installation of the toolkit is one of the most common reasons for the toolkit not getting wider coverage and usage.  The next release of the toolkit (due at around the same time as BizTalk 2006 R3) will make the installation process significantly simpler.  In the meantime, however, those wanting to use the functionality of the toolkit will find that the installation guide created by Peter Kelcey (available at ESBInstallProcess_V1.pdf) is a great guide that helps avoid most of the issues encountered during the installation.

Recently, however, a customer installed the toolkit and everything was moving along smoothly until they got to the final step of the ESB Management Portal installation: "Open the portal at http://localhost/esb.portal/ to validate that the portal loads correctly".  When launching this URL the customer was presented with the standard ASP.Net "Runtime Error" page, and 3 events were logged to the event log, stating "An exception of type 'System.NullReferenceException' occurred and was caught. Object reference not set to an instance of an object.", "An unhandled exception has occurred.", and "An exception of type 'System.Web.HttpException' occurred and was caught.  Session state can only be used when enableSessionState is set to true, either in a configuration file or in the Page directive ...".

This topic has been discussed on the ESB Codeplex site (http://www.codeplex.com/esb/Thread/View.aspx?ThreadId=17667) in which reference was made to the knowledgbase article for enabling ASP.Net applications to run on a SharePoint virtual server (http://support.microsoft.com/kb/828810).  The KB article states that the path for the ESB Management Portal should be configured as an excluded path in SharePoint and that the server's web.config file may need to be changed as well.  After excluding the esb.portal path from SharePoint's managed paths the error still remained.  The customer was reluctant, however, to change the server's web.config file as the server used hosted a number of other applications in IIS, and wanted to find out what changes could be made to the esb.portal web.config file to get the Management Portal to function correctly. 

Hence, the reason for this post is to detail the changes that were made to the web.config file of the ESB Management Portal to get the portal to function correctly on a server that has SharePoint Team Services 2.0 or SharePoint Server 2003 installed.

Following the guidelines given in the KB article, and through a process of trial and error the minimum set of changes to be made are as follows:

1. After the httpHandlers section, add the following:
   <httpModules>
  <add name="Session" type="System.Web.SessionState.SessionStateModule"/>
</httpModules>
2. Change the <pages> tag to:
   <pages enableSessionState="true" enableViewState="true" enableViewStateMac="true" validateRequest="false">

In addition to these changes you will still need to ensure that the esb.portal virtual directory is part of SharePoint's list of excluded paths.

A final note on this: if you encounter this error, make the changes to the config file, and then refresh the page you may still get an error in the browser.  This is because the ESB Management Portal is configured to use custom errors, so the error page is redirected to the URL http://localhost/esb.portal/DisplayError.aspx?aspxerrorpath=/ESB.Portal/Home/HomePage.aspx, and when you refresh your browser the error page is then refreshed, and not the home page located at http://localhost/esb.portal.  So, just check the URL before refreshing.

Hopefully this will save someone else the time and hassle associated with finding a solution for this error.

As the first in what I hope will be an on-going series of scenario challenges, I have uploaded a pack of information to the South African BizTalk User Group website (http://biztalkug.co.za/media/p/61.aspx).  This pack includes a scenario overview document, as well as some sample files that will be used in implementing and executing the scenario.

This is not a step-by-step walk-through of how to accomplish a specific task; it is a practical scenario that has been created to provide a common, fictitious domain in which you can grow your skills over time.  An additional benefit of this approach is that those that take up the challenge presented by the scenario can discuss their particular approach to solving the problem domain with others who have also taken up the challenge.  Through this process I am hoping that we can all grow our skills, whether you are a newbie or a seasoned veteran.

So, go grab the scenario pack, develop a solution you think will satisfy the requirement, and feel free to discuss the problem and post the solution for comment either on this blog or at the User Group web site forums.

Also, please feel free to provide any comments / suggestions / criticisms on this approach, information pack, or scenario.

The Issue

Earlier this week Bennie Wentzel, a developer from a customer I was engaged with last year, posed me a question which went something like this:

If I have a synchronous web service receive port, how can I return the result of a map on this receive port to the calling web service client, without using an orchestration or the ESB Guidance Toolkit?

Although I had never done this before I was pretty sure it was possible, so I took this as a challenge and set out to prove that it could be done.  After some tinkering I had the solution, which I have used as the excuse for this post.  As a bonus, the pipeline used to accomplish this task has been implemented in a generic manner, so that it can be used in any situation requiring configuration-based changes to be effected on a message's context properties within a receive pipeline.

The Investigation

The first step in finding a solution to this problem is to get a much deeper understanding of the requirement.  In most BizTalk solutions that use a request-response receive port, the request message is used to start an orchestration or it is relayed to a solicit-response send port.  When the orchestration or send port provide the response message, this message is then routed back to the calling service/application that submitted the original request message.  The requirement expressed within Bennie's question is that he wants to be able to use BizTalk's schema resolution, receive-side map resolution, and map execution logic to ensure that the output of the executed map is returned to the original caller.  In this scenario, the use of an orchestration or an intermediary send port would add unnecessary overhead.

The solution to this problem rests in understanding how BizTalk matches a response message to an initial request message.  When BizTalk processes a message through its receive-side architecture (receive adapter, pipeline, map) it identifies if the receive port is as a request-response port, and if it is then and instance subscription is created at the time that the request message is placed in the MessageBox.  This instance subscription is composed of the same EpmRRCorrelationToken promoted property that is in the request message's context, and a RouteDirectToTP promoted property with a value of True.  Any message that has the matching values in these two promoted properties will then be routed back through BizTalk's send-side architecture (map, pipeline, adapter) as the response message for the initial request.

To see this in practice, do the following:

• Create a request-response receive port.  One way to do this is to use the BizTalk WCF Service Publishing Wizard, and to have it create the receive port and receive location for you.
• Enable the request-response receive port.
• Create a send port that writes out to file, and has a Filter where BTS.ReceivePortName is equal to the name you gave to the receive port in the first step.
• Start this send port.
• Send a message to the receive port.  (A nice utility I use for sending a message to a SOAP/WCF service is SoapUI, but you could also use the WSDL from the service to build an InfoPath form)
• The request message should now be routed to the send port, and the request-response receive port will be waiting for its response message.  As no response message will be returned at this stage the client will eventually time out, but during this period we have an opportunity to see what the instance subscription BizTalk has created looks like.
• From the Group Hub Page, select the "New Query" tab, and select "Subscriptions" for the "Search For" field name.
• Add a new field name "Subscription Type" and set this equal to "Instance Subscription".  Your new query should now look like this:
   
• Execute the search, and you should see a result like the one shown below:
   
• If you look at the details of the instance subscription by double-clicking on it, and select the "Expression" tab, you will see that BizTalk has created a subscription based on the EpmRRCorrelationToken and the RouteDirectToTP context properties, as you can see in the screenshot below.
  

If you then also look at the context properties of the request message, you will notice that the value of the EpmRRCorrelationToken is the same as the value used in this instance subscription, and it is already promoted.  The request message does not, however, contain the RouteDirectToTP context property.  (For more info on these properties you can review the following MSDN page: http://msdn.microsoft.com/en-us/library/ms966048.aspx.)

The Solution

Having identified the problem, the solution becomes obvious: we need to add and promote the RouteDirectToTP context property, with a value of True.

The only point of extensibility we have available to use to do this is the receive pipeline.  If we can add the RouteDirectToTP context property, set its value to True and promote it within the pipeline, then the message coming out of the receive-side process will be a match to the instance subscription, and the message will be returned via the response portion of the request-response port. 

Not wanting to reinvent the wheel I embarked on a little Internet surfing, where I came across this post, which provided the code I needed to accomplish this.  Using this code as a starting point I made a few modifications (to support creating a property if it did not exist, and to be able to specify the Type to use when setting the value of the promoted property), and ended up with a version of this pipeline component which can be used when you want to create a new distinguished or promoted property, or when you want to set a value for an existing distinguished or promoted property, or when you want to use a regular expression to change the value of an existing distinguished or promoted property.  You can download the code for the ModifyMessageContext pipeline component here.  (NOTE: While this component is functional it is not of a commercial standard, in that there is no value validation, no tracing, etc. - so use at own risk).

I then created a receive pipeline using the custom pipeline component and the standard XML Disassembler component, and I set this pipeline as the receive pipeline to be used for the request-response receive port.  On the receive port I then set the properties of the custom pipeline component as shown in the screenshot below.  (The namespace is set to http://schemas.microsoft.com/BizTalk/2003/system-properties, as per the Expression in the screenshot above.)  Lastly, I deleted the send port created in the earlier section, as it was no longer required.

At this stage I had not setup a map on the receive port, so when I sent a message to the request-response receive port I got the same message returned.  Getting the map to execute and then have the mapped result returned as the response was simply a matter of configuring the map on the receive port.  I ran one more test and was happy to see the output of the map being returned as the response message.

Summary

While BizTalk does not by default provide a mechanism whereby the output of the process involved in receiving a request message can be returned as a response message, it does create an instance subscription which is used to ensure that when a response message is available in the MessageBox, this response message is returned to the waiting client.  By using this instance subscription it is possible, to modify the message generated by the receiving process in a way that will ensure that the message placed into the MessageBox at the end of the receiving process has the detail required to match the instance subscription, and thus enable the output of the receiving process to become the response message.

This post showed how, with a custom pipeline and custom pipeline component, it is possible to ensure that the message placed into the MessageBox (after the receive pipeline and any receive-side map has executed) matches the instance subscription, and therefore gets returned as the response message.

The result is a generic method whereby a message can be sent to BizTalk, the schema can be resolved, a matching map can be executed, and the output of the map can then be returned via the send portion of the request-response receive port.  All without an orchestration!

Any comments / queries / suggestions / challenges are, as always, most welcome.

After much promise, and many requests, the web site for the South African BizTalk User Group has now been launched.  Please pay us a visit at http://www.biztalkug.co.za/.

Thanks to Ryan Crawcour for taking the initiative on this, and thanks to all those who offered help and services. 

What we need now, though, is YOU!  The content at the site is still parse, so come and register at the site and help contribute to the user group by participating in the forums, reading blogs, writing blogs (simply register and mail Ryan or myself if you want a blog setup on the site), and uploading any media you may want to make public (such as patterns you have found useful, tips and tricks, etc).

If you have any suggestions / comments, please feel free to send them to Ryan or myself (you will need to register first) and we will do our best to act on them.

Hope to see you soon in the forums!

As a BizTalk developer I have come to rely rather heavily on a variety of tools to assist with various aspects of developing, deploying, documenting and testing BizTalk solutions.  The latest addition to this toolbox is the BizTalk MessageViewer HAT Plugin, referred to me by a colleague, Willem Fourie.

This little utility is a nice time-saver, allowing you to view tracked messages from within BizTalk's Health and Activity Tracking (HAT) tool.  Traditionally, if you wanted to see a tracked message from within HAT you would need to save the message to disk, and then load the message from disk.  Your other option for viewing messages is to use the BizTalk Group Hub, but that is geared towards displaying messages that are suspended, and does not by default display messages that have been successfully processed.  This new plug-in, available at http://www.codeplex.com/btsviewerhatplugin, hides this from you and presents you with a functional UI in which to view the message(s) selected.

The tool is very new - only having been released in its version on the 23rd of May - so there are few kinks to still work out of it, but it is nevertheless a great time saving tool, and one I will certainly be monitoring for further development, and using on a frequent basis.

I will endeavour to add more information on the tools that I use over the next few posts.  What are the tools you are using?

For those that are aware of the BizTalk Hotrod magazine will know how informative and jam-packed this resource is.  Those of you who are new to the Hotrod will marvel at the amount of content available in this freely available download.

Here's some more detail on the contents of this issue, from Todd van Nuurden, the self-proclaimed "Pirate Technology Specialist", as posted at http://biztalkhotrod.com/default.aspx:

Hi BizTalk Fans,

Its finally Spring here at BizTalk Hotrod HQ and Issue 4 has finally been put to bed! In this issue you’ll see that we’re continuing our expansion into WF (Windows Work Flow) and WCF (Windows Communications Foundation). Why, you ask, would we do this? Well BizTalk is the future! And we want to bring our .NET friends into the BizTalk fold and as you’ll see BizTalk continues to expands its process server capabilities across  the Microsoft platform. We’ve also expanded our coverage to include folks new to BizTalk Server so check out Sal’s “In the Beginning” article

As always we’re looking for new ideas and new authors so if you’re interested please contact us.

Oh we’re also considering a BizTalk Hotrod Resource issue that would include articles by BizTalk software partners as well as links to all the coolest BizTalk Content on the web.  So if you have content that we should link to or publish let us know.

Issue 4 of the Hotrod is now available at http://cid-b6c859f7a5f75e63.skydrive.live.com/self.aspx/Public/Q2FY08_biztalk.pdf.  Go and get it!

In my previous post on the default behaviour of the XMLReceive pipeline with respect to validating a message against a schema I detailed the creation of what I termed the "XMLValidatingReceive Pipeline".  In response to this posting, Payal Arya emailed me the following question with respect to this posting, which highlighted the need for more clarity around how the pipeline works:

"Your posting was very helpful, however I had one question that what's the use of XML Disassembler and Party Resolution in the Pipeline, when only XML validator solves the purpose."

After getting this question, and reading through my post again I clearly did not detail the reasoning for the use of these components, so here goes.

The reason why I kept the XML Disassembler and Party Resolution components in the pipeline is that I wanted the standard XML Receive pipeline to be enhanced with an automatic schema validation function.  This would then provide me with an enhanced, generic pipeline I would be able to use in any development that required schema validation.  This required that I keep the same functionality that the XMLReceive pipeline provided, and just extend its functionality: so that the XMLValidatingReceive pipeline effectively becomes an evolution of the XML Receive pipeline's generic functionality.

The alternative, if you wanted the simplest pipeline that would still do schema resolution and validation, would be to create a pipeline that just has the Xml Validator component in the pipeline.  As the Xml Validator component will automatically resolve the schema from the message's target namespace and root node name, it would be able to identify the schema associated with the received message, and then perform the validation as well.

By keeping the XML Disassembler component in the pipeline, however, the pipeline will still support any envelope and debatching processes embedded in the schema design, and the debatched messages would then be validated by the Xml Validator component. Similarly, by including the Party Resolution component, any party resolution logic that you may require in your solution is still supported. Obviously, if you do not require either of these functions in your solution and you do not want to incur the overhead of these additional components you could exclude these pipeline components, and your pipeline would still perform the validation function.

The ability to rigidly define the content of a data field is an essential element in any structured data definition.  It is no surprise therefore one can define data constraints on elements and attributes in a schema through the means of various facets, such as enumerations, min length, regular expressions, and many more.  The implementation of facets in a schema provides a large amount of value in terms of the data aspect of the contract to be used in an integration.  Whether the integration is WCF-based or not, this data contract must be adhered to and messages that do not adhere to this contract must not be processed.

There is, however, no value in defining the data constraints if these constraints can not be enforced at the time the data is received, as allowing "invalid" data to be processed will invariably lead to errors in the processing of that data.  It is for this reason that validating a message against its schema is oftentimes a necessary requirement.  Some might say that this validation should be performed by default, and any messages that do not validate should be rejected as early in the processing of the message as possible.  BizTalk does not do this by default.

At this point you may be saying what do you mean "BizTalk does not validate my message?" ... hence, the title of this post.

The point is that BizTalk CAN validate your message, but it does not do so by default.  One of the reasons for this is flexibility: you may prefer to do the validation later in your process, perhaps in an orchestration, where you can handle the validation errors in your own way; or you may want the receive pipeline to do the validation and have BizTalk route the failed message.  This decision is not made for you by BizTalk ... your solution design will determine the appropriate implementation.

In this post I will present two ways in which you can get BizTalk to fully validate your message against its schema as early in the receiving process as possible: at the receive pipeline.

Using the XMLReceive Pipeline

When using the standard XMLReceive pipeline in a receive location you can click on the ellipsis button to the right of the pipeline selection box to display the "Configure Pipeline" window.  The screenshot below shows how the XMLReceive pipeline makes use of the XML disassembler pipeline component and the Party resolution pipeline component.  When first setting up the receive location the ValidateDocument and DocumentSpecNames properties are False and blank respectively.  In this default configuration the XMLReceive pipeline will try and match the received XML document's target namespace and root node name to the published schemas in BizTalk, and the received document's structure will be validated against the schema's structure.  No data validation is performed on the received document, however.

By setting the ValidateDocument property to True the XML disassembler pipeline component will be instructed to validate the data contained in the received document as well.  Setting this property to true also requires that at least one DocumentSpecName is also provided, as the XML disassembler uses the schema specified by the fully qualified assembly name in the DocumentSpecNames property to identify the schema with which to perform the validation.  With these properties set, if the receive location processes a message that fails validation an entry like the one below will be logged to the event log.

While this approach achieves the objective it falls short for an ideal solution, because:

• The XML disassembler pipeline component has logic built into it to identify the matching schema for a received message, so why does it not use this schema to perform validation?  In other words, I would like to be able to change the Validate flag to true, without needing to specify a value for the DocumentSpecNames property.
• Every time the schema changes (possibly due to version changes) the developer will need to remember to go and change the configuration of the XMLReceive pipeline to ensure that the correct fully qualified assembly name is stored in the DocumentSpecNames property.
• If I have multiple receive locations that each need to do schema validation the previous task would be compounded as I would need to remember to set the properties for each receive location.

This leads on to the second method to ensure that BizTalk validates the content of the received message: a custom pipeline that can be used in any receive location to do full schema validation, without requiring any additional configuration.

Creating and Using the XMLValidatingReceive Pipeline

The concept behind the XMLValidatingReceive pipeline is to have a generic pipeline that one can use in any project, and in any receive location where the received document's structure and data content needs to be validated against an existing schema.  As the standard functionality of matching a received document with a deployed schema is still required, the XMLReceive pipeline is an excellent starting point.  As the XMLReceive pipeline uses the XML disassembler and Party resolution pipeline components, the XMLValidatingReceive pipeline will need to use these two pipeline components as a starting point as well.  In addition to these components, the XMLValidatingReceive pipeline will also make use if the XML validator pipeline component.

To create the XMLValidatingReceive pipeline, create a new receive pipeline.  I created this pipeline in a generic BizTalk solution and project, so that I could use it for any solution, at any customer.  In the new receive pipeline, add the XML disassembler, XML validator and Party resolution pipeline components, as per the screenshot below.

There is no need to change any of the default properties for any of these components.  The pipeline can now be deployed and used in any BizTalk application.  A message processed by this pipeline will now use the XML disassembler's schema resolution functionality and it will validate the structure of the document against the resolved schema.  The XML validator component will then use the resolved schema name to validate the received document's data content, in accordance with any facets defined in the schema.  Where a received document fails validation, the same error as in the previous method is shown (as below), except that the pipeline referred to will now be the new custom pipeline.

The result is a common pipeline that can be used in any receive location, and which does not require any configuration of pipeline properties to ensure that the received document is full validated.  At the same time, this pipeline does not require any changes to be effected in the event of a change to a schema.

Summary

In conclusion, don't assume that BizTalk will enforce those facets you diligently applied to your schema.  You need to instruct BizTalk to validate a received message against the data constraints you define in your schema, and there are two simple ways in which this can be achieved.  If it is a regular requirement to ensure that the received document is fully validated against the schema, then create a custom XMLValidatingReceive pipeline that can be used in any BizTalk development project.

With the amazing wave of new platforms (Windows Server 2008, .NET Framework 3.5, Visual Studio 2008 and SQL Server 2008) coming out of Redmond recently, some of the most asked questions are "When will BizTalk be able to utilise these new platforms?", and "When can I use VS2008 with my BizTalk solutions?".

Well, the good news is that the guys at Redmond have been hard at work to update BizTalk in order that it can work with the latest versions of Windows Server, the .NET Framework, Visual Studio, and SQL Server.  Once SQL Server is released as the final part of this technological tidal wave that Redmond has released on us, BizTalk Server will follow hot on its heels with support for these most recent platform releases.  The benefits of this will include providing customers with the ability to take full advantage of the improvements in scalability and virtualisation, and they will have improved support for next-generation web and service oriented applications.

In addition to the support for the latest platforms, a few additional capabilities are planned to be added to the next BizTalk release, to deliver additional customer-requested capabilities for our core SOA infrastructure.  More details will be provided on specific features in the coming months, but at a high level some of the new investments in the release include:

• New web service registry capabilities with support for UDDI (Universal Description Discovery and Integration) version 3.0
• Enhanced service enablement of applications (through new and enhanced adapters for LOB applications, databases, and legacy/host systems)
• Enhanced service enablement of “edge” devices through BizTalk RFID Mobile
• Enhanced interoperability and connectivity support for industry protocols (like SWIFT, EDI, etc)
• SOA patterns and best practices guidance to assist our customer’s implementations

Either way, there is something new for the BizTalkers out there to look forward to, with the first CTP expected to be available in the third quarter of this year, and the final release planned for sometime in the first half of next year. 

BizTalk Server 2006 R3 is coming!

After a lengthy absence from the BizTalk Community, the BizTalk Scheduled Task Adapter is once again available.  Greg Forsythe has kindly made it available at http://www.codeplex.com/BizTalkScheduledTask, together with the source code for this adapter.

For those who are not aware of this adapter: through the use of this adapter on a receive location you are able to schedule the creation of a message into the BizTalk message box, which can then be used to start a BizTalk process.  The scheduling options are flexible, allowing for a daily, weekly or monthly schedule to be created.  Configuration of the adapter provides for a selection of three standard tasks to take place once the scheduled time is reached:

• XmlString - generates a Biztalk message from a configured Xml string
• FileReader - generates a Biztalk message from the contents of a file
• HttpDownload - generates a Biztalk message from data downloaded from a web site

In addition to the standard tasks, custom tasks can also be created by creating any .NET class that implements the appropriate interface.

You asked, and we listened!  Following on from a number of requests for the South African BizTalk community, Quicklearn's BizTalk Deep Dive course is finally coming to Johannesburg, South Africa! 

I will provide more information, and a copy of the invite once I receive it, but for now reserve the dates of 12-16 May 2008.

Thanks to Frikkie Bosch for taking the initiative and arranging this.

Difficulty Level: Easy

What must you do to make the following equation true?

81 x 9 = 801

While testing the WCF-WSHttp receive adapter this week I ran in this very interesting, and rather obscurely worded error:

The message with To '' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher.  Check that the sender and receiver's EndpointAddresses agree.

The objective of this integration was to expose a service through which we would be able to receive a message from an IBM WebSphere Message Broker implementation initially.  The intention was that other applications and back-end systems would also be able to utilise this service at a later stage.  It had therefore been decided way back in the design stage of the project that we would accomplish this by using the SOAP 1.2 protocol for receiving messages into BizTalk.  To implement this on the BizTalk side we published the schema for the message we were expecting as a WCF service, and created the matching receive location.  My first mistake was that I thought we could use the WCF-BasicHttp adapter, as the only requirement was that the service needed to adhere to the WS-BasicProfile standard.  What I did not know at the time was that the BasicHttp adapter only supports SOAP 1.1, and to use SOAP 1.2 you have to use the WCF-WSHttp adapter.

After using the command line utility discussed in a previous post to recreate the service and update the receive location, I figured everything would be ready and I started to test the service via SOAP 1.2 again.  That was when this rather obscure error was returned in the SOAP response.  The actual response looked something like this:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">
   <s:Header>
      <a:Action s:mustUnderstand="1">http://www.w3.org/2005/08/addressing/soap/fault</a:Action>
   </s:Header>
   <s:Body>
      <s:Fault>
         <s:Code>
            <s:Value>s:Sender</s:Value>
            <s:Subcode>
               <s:Value>a:DestinationUnreachable</s:Value>
            </s:Subcode>
         </s:Code>
         <s:Reason>
            <s:Text xml:lang="en-ZA">The message with To '' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher.  Check that the sender and receiver's EndpointAddresses agree.</s:Text>
         </s:Reason>
      </s:Fault>
   </s:Body>
</s:Envelope>

After scouring the web for an explanation I came across a number of articles that discussed WCF coding changes and endpoint behaviour changes that would remedy the error.  The only problem with that is that we do not have access to making code changes, and changing the endpoint behaviour did not make sense either.  I also wanted to stay away from implementing custom WCF bindings, as this is supposed to be "out-of-the-box" functionality.

Eventually I came across this article: http://msdn2.microsoft.com/en-us/library/bb246105.aspx, which focuses on using incoming SOAP headers, and I noticed the "To" element within the SOAP Header section.  With a little more reading and surfing I came to realise that the WSHttp adapter utilises the WS-Addressing standard to identify the receive location to which the message needs to be submitted.  With this knowledge in hand I added the following section to the SOAP message I was sending to BizTalk:

<soap:Header>
   <To soap:mustUnderstand="1" xmlns="http://www.w3.org/2005/08/addressing">http://server1/virtualDir/MyService.svc</To>
</soap:Header>

The addressing namespace can, of course go into the "Envelope" declaration of the SOAP message, but for simplicity sake I am reflecting it as shown here. 

The URI that is put into the To element is essentially the URI used to get to the service in the first place.  A few interesting observations about this URI:

• The value of the server name portion of the URI ("server1" in the snippet above) is immaterial.
• The portion of the URI after the server name, up to and including the ".svc" must match the URI in your receive location.

After adding this section to the SOAP message and submitting it to BizTalk the message was received and processed successfully.

Difficulty Level: Easy

Two children have the following chores to do, before they will be allowed to play Halo 3.

1. Mow the lawn.
2. Wash the dishes.
3. Wash the car.

When done by one child each of these chores will take 1 hour to complete.  If they were to start at 9am how would they be able to finish their chores in the shortest amount of time possible, given that the two children can not work on the same chore at the same time?