As I mentioned previously, I did some talks recently (user group, Teched 2008) on “unattended” deployments for BizTalk.  You can download the slides here.

Soon, I’ll be posting a generic Team Build script for BizTalk projects as well as a MSBuild script that can be used with TFS Deployer (for unattended deployments.)

Are you going to be at TechEd this week?  I’ll be delivering an expanded version of the talk I gave on May 15 at the last Twin Cities BizTalk User Group.  The talk (mostly demos!) is all about achieving unattended deployments with BizTalk using Team Foundation Server (with TFS Deployer.)  

The session is on Wednesday at 12pm, titled “SOA07–TLC  – Automated Remote BizTalk Server Deployments with Microsoft Visual Studio Team Foundation Server” in Green Theater 2.  (That’s a mouthful…)

See you there!

My article on “smart” use of XSLT within BizTalk appeared in BizTalk Hotrod Issue 4.  Once again, a great set of content thoughout this issue.

The article talks about the “why and how” of using a “straight” XSLT approach with BizTalk – where your XSLT files reside directly on disk, and not within map assemblies.  It discusses caching compiled XSLTs, and using XSLT 2.0 via the Saxon libraries.  You can download the sample code and comment over on the article’s Codeplex project.

There has to be a better way to do this – if you know of one, kindly post a comment.

Until then, here is a technique that will allow you to ensure that if a stored procedure that BizTalk is calling is unable to complete its work successfully, you can rollback the work and be notified of that fact within your orchestration.

1. In the stored procedure, use RAISERROR with a severity greater than 10 in the event of an error.  This should abort the (DTC) transaction that the BizTalk Sql Adapter initiated (that wraps the work within the stored procedure.)
2. Use a scope around the Send/Recieve shapes in your orchestration that deal with this stored procedure.  You will want to catch Microsoft.XLANGs.Core.XlangSoapException…but you can’t.  The designer won’t let you.  So…be brave, open the ODX, and look for the catch block so you can modify it as shown below (see “ExceptionType”):

<om:Element Type="Catch" OID="e7590870…" ParentLink="Scope_Catch" …>
  <om:Property Name="ExceptionName" Value="soapex" /> 
  <om:Property Name="ExceptionType" Value="Microsoft.XLANGs.Core.XlangSoapException" />
  <om:Property Name="IsFaultMessage" Value="False" /> 
  <om:Property Name="ReportToAnalyst" Value="True" />
  <om:Property Name="Name" Value="CatchException_2" />
  <om:Property Name="Signal" Value="True" /> 
</om:Element>

3. With this solution, you will wind up with the message you are sending to the stored procedure in a suspended state whenever the RAISEERROR occurs.  This isn't a huge deal, but you have to plan how these will get cleaned up.  It could be done manually, with a script, or with an orchestration or send port that subscribes to these suspended messages (try a filter with ErrorReport.FailureCode == 0xc0c0167a to get started, though you probably want to be more specific.)

After you’ve gone to these lengths, it is always worth considering whether you want to have your orchestration call a component so you are a little closer to the action.  But, if you have need of the adapter, this should work out.

BizTalk 2006 R3 was announced today!  This answers the frequently recurring question of “When will BizTalk live inside of Visual Studio 2008?”

Well, this release will make that happen…In addition, R3 will provide support for Windows Server 2008 and Sql Server 2008.  You can expect a release after general availability of Sql Server 2008…

Like R2, this is a pretty incremental release.  Steven Martin indicates that releasing fresh bits is a better user experience than a “large Service Pack”…well, at any rate, it always seems like a good idea to avoid delivering new features in a service pack.  Expected to see some new (and updated) LOB, legacy, and database adapters – in addition to a mobile RFID piece…

Have you been getting an intermittent error similar to the following during a TFS Team Build execution (within the CoreGet target) ?:

Access to the path 'C:\Documents and Settings\tfsbuild\Local Settings\Temp\TFSTemp\4580{#$@;._}808' is denied.

If you look around, you will find a few folks who point at antivirus software as the culprit, but in our case it turned out to be the disk defragmentation service…

 

I sat down with Jeff Brand from Microsoft to discuss “BizTalk for .NET developers”.  We touched on how BizTalk fits in with a typical SOA effort, dealing with the learning curve, typical usage scenarios, and several other topics.  Great fun.  You can grab the MP3 here if you like.

I still can’t quite believe we dared to wade into this topic – but Jeff Brand (Microsoft) hosted myself, Rocky Lhotka, Matt Milner, and Jason Bock for a podcast that hit on REST, web services, tooling, and a few other loosely connected topics.  It was fun to do.  I must have been sitting closer to the microphone – I’m the loud voice, for better or for worse.

Find it here.

This bit of documentation explains that when you want to send a message out over the MQSeries adapter and receive a correlated response, the typical pattern is to:

1. Generate a value for the MQMD_MsgID property on the outbound message
2. Set the MQMD_CorrelID property on the outbound message to that same generated value, so that your “Send” shape can initialize a correlation that refers to the same property that will be present on the message you receive.
3. Send the message (initialize correlation with MQMD_CorrelID)
4. Receive the response (follow correlation with MQMD_CorrelID)

This assume that the destination system is following the usual pattern of setting the correlation identifier on the reply message equal to the message identifier on the request message.

Great.  Except when you don’t have the luxury of specifying the MQMD_CorrelID message on the outbound message to a value of your liking.  This occurs when you’re using a CICS bridge, or anything else that requires you to set the MQMD_CorrelID property to IBM.WMQ.MQC.MQCI_NEW_SESSION (signifying a new session interaction…)

In this case…you might be attempted to use the other pattern suggested here.  In this case, you engage in a solicit-response interaction with the adapter – where you send your request message and receive an immediate reply that contains a message with BizTalk_CorrelationID populated as a context property.  The message ID has also been generated for you.  You are then supposed to do a “dummy send” to initialize a correlation based on the BizTalk_CorrelationID property (sigh), and then follow that correlation with another receive shape that is the actual transaction response. 

To see this in action, see SDK\Samples\AdaptersUsage\MQSeriesAdapter\MQSCorrelationSetOrchestration under your BizTalk installation, or see the orchestration here.

Unfortunately, this design lends itself to a race condition.  The response coming back can occur prior to your correlation being initialized by the “dummy send”, resulting in a routing failure.  (This isn’t hypothetical – I just spent some time helping someone debug this issue.)

To work around this, you could try to do content-level correlation instead (i.e. use a promoted property in your request and response content.)