The MS Technical Editors responsible for the BizTalk posters have recently updated some of the posters for BizTalk 2009. 

Check them out at the following URLs:

· BizTalk Server 2009 Scale-out Configurations Poster

· BizTalk Server 2009 Database Infrastructure Poster

· BizTalk Server 2009 BAM Poster

In a recent internal discussion I was enlightened to the fact that there is a BizTalk Server 2006 R2 certification exam available.  This exam is available at http://www.microsoft.com/learning/en/us/Exams/70-241.aspx, so get going and be one of the first to get your BizTalk certification updated.

After a very valuable and interesting TAP (Technology Adoption Program) process, a public beta of BizTalk Server 2009 is now available at https://connect.microsoft.com/site/sitehome.aspx?SiteID=218.  In unison, the CTP of the ESB Guidance Toolkit v2 is also being released, and is available at http://codeplex.com/esb.  Go and grab it!

For those who are not aware of these two technologies, the detail below should provide good context:

BizTalk Server 2009

With the public beta release of BizTalk Server 2009, Microsoft is delivering the first customer preview of the multi-release road map announced in September 2008 and is giving customers the first look of the feature-complete download. BizTalk Server 2009 supports the latest Microsoft application platform technologies, including Windows Server 2008, Microsoft Visual Studio 2008 SP1, Microsoft SQL Server 2008 and the .NET Framework 3.5 SP1. BizTalk Server 2009 also delivers expanded new connectivity options including new integration with Oracle Corp.’s E-Business Suite, as well as updated platform support for the most recent versions of IBM Corp.’s Customer Information Control System (CICS), Information Management System (IMS), DB2, DB2/400, DB2 Universal Database and WebSphere MQ.

BizTalk Server 2009 also delivers improved scalability and reliability through support for SQL Server 2008, Windows Server 2008 Hyper-V virtualization and enhanced failover clustering. It provides significant new enhancements to both individual and team productivity by enabling new interoperability with Microsoft’s application life-cycle management (ALM) solution Visual Studio Team System and Team Foundation Server. This allows development teams to utilize the integrated source control, bug tracking, team development support, Project Server integration, and support for automating builds via MSBuild for a more seamless development and testing experience.

BizTalk RFID Mobile also extends the power of BizTalk Server RFID to mobile devices running Windows Mobile and Windows CE. In addition, BizTalk RFID Mobile delivers simple device management and offline processing capabilities, all of which help reduce the total cost of ownership.

ESB Guidance 2.0 CTP

The first public CTP release of the Microsoft ESB Guidance 2.0 for Microsoft BizTalk Server 2009 incorporates many new and expanded features include the following:

• New samples:
• SSO Configuration provider for Enterprise Library 4.0
• Multiple Web Service Execution Sample
• Exception Handling Service Sample
• New ESB Web services:
• Generic Itinerary Services ( no itinerary header required)
• New core features:
• Alignment with Microsoft BizTalk Server 2009 ( Beta )
• ESB Configuration tool
• Centralized itinerary store
• Itinerary resolver components
• Itinerary forwarder pipeline component
• Itinerary selector pipeline component
• Itinerary designer
• Centralized configuration uses Enterprise Library 4.0 Configuration Block
• Centralized caching uses Enterprise Library 4.0 Caching Block
• Multiple service invocation using both messaging and orchestrations
• Itinerary BAM tracking
• Improved ESB Core engine and itinerary execution

David Chappell is both a technologist and an amazing wordsmith.  In his most recent whitepaper, titled A First Look at WF 4.0, “Dublin”, and “Oslo”, he does an amazing job of detailing the new release of WF, and the new “Dublin” and “Oslo” technologies.  Read it at http://msdn.microsoft.com/en-us/library/dd200919.aspx.

For those who focus on BizTalk, and who may be feeling that “Dublin” is encroaching on BizTalk’s territory, make sure you read the section titled “Dublin” and BizTalk Server.  Although it only touches on this topic briefly it is a great synopsis of the different objectives of the two technologies.

Quite a while back I posted what was to be the first in a series of BizTalk Scenarios that could be used as a practical learning aid.  I was hoping to have the solution for this scenario uploaded within a month of that post, but alas it was not to be.  The idea of posting the solution is that it would serve as a reference solution that could be used to compare your solution for the scenario with my proposed solution.  By comparing different approaches to solving the same problem one can then learn and grow one's skills.

Well, I have finally gotten round to posting the solution to the South African BizTalk User Group forum at EATS - Scenario 1 Solution Pack.  Download it and compare it to your solution, or download it to see one possible solution as to how the challenges presented in the scenario could be solved.

As always, any comments / suggestions / criticisms are most welcome.

BTW: Look out for the second scenario, which will be posted soon.  As can be expected, each subsequent scenario will present greater degrees of difficulty and will cover greater areas of BizTalk's capabilities.

The guys from K2 have provided some more detail on what they will be showing us during the User Group meeting on Wednesday:

Home Improvement Retailer – Integrated Sales Order Solution.

• Charles (Sales Officer) creates a new sales order.
  • Customer data is received from SAP using BizTalk. (Using BizTalk SAP Adapter)
• Charles submits the order.
  • K2 uses BizTalk to do a credit check on an IBM server. (Using BizTalk Host Adapter for IBM DB2)
  • Based on the data received from the IBM server an approve or decline decision is made in the K2 process.
• When the credit check is approved
  • The Sales Order information is sent from K2 and captured back into SAP using BizTalk. (Using File Adapter and SAP Adapter)
  • An availability date is received back into the K2 process from SAP via BizTalk. (Using K2 Adapter)
• A message is sent back to BizTalk to update data into the BizTalk BAM. (Using BizTalk MSMQT Adapter)
• K2 creates a calendar entry in MOSS based on the availability date.
• K2 sends an Office Communications Server message and email to the Sales Team to indicate the sale has been processed.
• An email is sent to the customer indicating the sale has been processed.

Although the K2 guys will be using stubs to simulate SAP and DB2 this should be a great demo!  We should get a good idea of how K2 adds value to BizTalk and how human workflow can be integrated into BizTalk's business process automation focus.

Time permitting, remember that after this demo we will do a dive into the enhancements and new features coming down the line with BizTalk Server 2009.

It's going to be a jam-packed session ... so we hope to see you there!

There is plenty of information on the Net relating to being able to send an HTML email from BizTalk using a dynamic SMTP port and an orchestration (see here and here).  At a client I needed to achieve the same objective, but without the use of an orchestration and with a static SMTP port. 

The basic requirement was that the customer was looking to develop a solution that would make use of the standard send port filters, outbound map resolution, and BizTalk's management console to provide a flexible solution for sending HTML email to one or more standard email addresses.  They specifically did not want to use an orchestration and a dynamic send port, as they wanted to use the send port filters as the "rule base" to determine which messages should be routed to which static email addresses, and they wanted to use the BizTalk administration console to maintain the email addresses and the filter rules (which are mainly BTS.MessageType filters).

This set of requirements presented the following challenges:

1. How do you architect the solution so that you can setup and manage a specific send port once (e.g. a send port for billing@joesrouting.com) and route different messages to this send port.  Yet, each message needs to be transformed in accordance with the message's unique type before the message is sent to the specified email address?
2. Once you understand how you are going to manage the routing and selective transformation requirements, how do you ensure that the selected transformation produces the HTML formatted email content specific to the message type you are sending?
3. The last challenge, although far easier to state, was somewhat more complex to resolve: How do you send an HTML email via a static send port?

Routing and Transforming Messages

For those who have worked with BizTalk for a while, this problem will not present too much of a challenge, as this functionality is native to BizTalk.  The send port in BizTalk follows the following process (simplified for the purposes of this post):

1. Receive the outbound message, in accordance with the send port's subscription.
2. Find any maps configured for the current send port, where the source schema in the map matches the current message's BTS.MessageType context property.
3. Execute the map, if a match is found.  If no match is found the message is passed on to step 4.
4. Call the configured pipeline, passing in the output of the map.
5. Execute the pipeline.
6. Pass the output of the pipeline to the configured adapter.
7. The adapter then performs its logic on the finalised message.

Through this process the send port is able to receive any message type, and for each message type that is received a different map may be executed before the message is processed further.  This process therefore fulfills the first "challenge" in this scenario, as we will.

Producing HTML Output

Using this approach to route and transform messages, the next challenge is how to produce HTML from a map.  Once again, BizTalk provides a simple solution to achieve this: a BizTalk map can be configured to use an XSLT file, by choosing the XSLT file from the "Custom XSL Path" property in the map's properties.  The XSLT that you use can then produce HTML and it can use content from the source schema to produce an HTML formatted output containing data from the input message.  An example of such an XSLT file is shown below:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output omit-xml-declaration="yes" method="xml" standalone="yes" version="1.0" encoding="UTF-8" />
    <xsl:template match="/">
        <html>
            <head>
                <title>Billing Enquiry: Corporate</title> 
            </head>
            <body> 
                    <p>
                        The details below relate to a billing enquiry receive at <xsl:value-of select="//Header/QueryTime" /> on <xsl:value-of select="//Header/QueryDate" />.
                    </p>
                    <table style="border:none;padding: 0px;width:100%;">
                        <tr>
                            <td>Contact Person:</td>
                            <td>
                                <xsl:value-of select="//Query/ContactName" />
                            </td>
                        </tr>
                        <tr>
                            <td>Contact Number:</td>
                            <td>
                                <xsl:value-of select="//Query/ContactNo" />
                            </td>
                        </tr>
                        <tr>
                            <td>Account Number:</td>
                            <td>
                                <xsl:value-of select="//Query/AccNo" />
                            </td>
                        </tr>
                        <tr>
                            <td>Query:</td>
                            <td>
                                <xsl:value-of select="//Query/Description" />
                            </td>
                        </tr>
                    </table> 
            </body>
        </html>
    </xsl:template>
</xsl:stylesheet>

A particular snag that caught me during the implementation of this XSLT within the map is that BizTalk Mapper kept adding a META tag into the produced HTML, and it would change the nature of some of the tags, e.g. if we had a tag that was "<br/>" in the XSLT file, it would come out as "<br>" once the map had been executed.  It was only after I realised that I had forgotten the output control declaration that I realised why this was happening.  The point is: make sure that you include the following line in your XSLT file to ensure the correct processing takes place:

<xsl:output omit-xml-declaration="yes" method="xml" standalone="yes" version="1.0" encoding="UTF-8" />

Sending HTML via a Static Send Port

With the routing sorted, and the maps producing HTML, the next challenge was to get the static send port to send the HTML in the body of the send port.  The challenge here is that the SMTP adapter does not natively take the content of the message and put it into the body of the email being sent via the send port.  Even if you select the "BizTalk message body part" option in the "Compose" tab of the SMTP adapter properties, the content of the message is not used as the body of the email.  Instead, the message is sent as an attachment to a blank email.  There are examples of how to ensure that a specific set of text is used as the body of the email, via a dynamic port, but there are no examples of how to do this for a static port. 

After trying many different options the result was to use a pipeline component and pipeline to set the "ContentType" property of the message being sent to "text/html".  Once this was done, the SMTP adapter was more than happy to take the content of the BizTalk message and place it within the body of the email it sent, and the email was received as an HTML-formatted email.  The code used to set this is shown in the single line below:

inmsg.BodyPart.ContentType = "text/html";

In Summary

With the challenges solved, the final result was a flexible solution that did not use an orchestration, and which used a map per message type, and a send port per email address (with each send port configured with the appropriate maps and with the pipeline that set the content type).

Some very interesting news around BizTalk today.  Not only was there the announcement around BizTalk's future on the BizTalk Server Roadmap page, but there was a Q&A session with Oliver Sharp, the General Manager for the Connected Systems Division.  Some really cool info is contained in these updates.

The first point of interest is that the announcement and Q&A provide a very clear commitment to BizTalk customers that existing investments in BizTalk will not be lost, that BizTalk will continue to grow as a product, and that upgrades will take previous investments into account.  As some customers saw "Oslo" as being a potential replacement for BizTalk Server, this should set their minds at ease.  The announcement emphasises this point by indicating that BizTalk will continue to grow as a product and will, over time, be able to interoperate with the modelling initiatives that are the embodiment of "Oslo".  So, BizTalk is here to stay!

This announcement and update also provide some more clarity around how the "Oslo" initiative is shaping up.  "Oslo" has gone from being a broadly stated idea to becoming a more and more realistic strategy and set of initiatives within Microsoft.  As with any large-scale idea, the concepts on which the idea are based go through a number of changes as the idea evolves over time and the concepts slowly formulate into more concrete definitions.   This has happened with "Oslo" as well, and this post provides some clarity around how the core of "Oslo" is focused on the concepts of model-driven development and management.  Even more interesting announcements relating to other concrete definitions that have come from the original "Oslo" idea are going to be made available at PDC in October ... so make sure you listen out for the news.

Another very interesting point is the change in name for the next release of BizTalk from the previously used name of "BizTalk Server 2006 R3" to the new name of "BizTalk Server 2009".  This is a clear indication of the number of changes and additions that have been included in this next release of BizTalk; not only is there a whole new set of platforms being used, but there are also new features being introduced, such as native support for unit testing, TFS, Hyper-V, etc.  Some might feel that this is just a marketing ploy, but I believe this change is for the best due to the number of changes that have been incorporated in BizTalk since the original BizTalk Server 2006 release, and because this naming convention is more in line with the naming convention used for products such as SQL Server and Visual Studio.  So keep a look out for CTP drops of BizTalk Server 2009 in the coming months. 

Lastly, the guys in the Connected Systems Division of Microsoft have committed themselves to making a major release of BizTalk every 2 years, with some tantalising promises of functionality that will come available through the next two releases.  The ones that pique my interest the most are the "Low-latency messaging enhancements", the hint at new BizTalk Mapper functionality, and the "Real-time business event visibility".

So, all round ... a lot to look forward to both in the short and medium term.  Interesting times lie ahead!  :-)

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.