I had a great time presenting at this year’s MDC – thanks to all of you who attended.  We covered Conchango’s newest Scrum template for TFS 2008, as well as their very cool new Task Board UI.  We covered eScrum, VSTS Lightweight Scrum, Scrum itself, process customization in TFS…come to think of it, it was a lot of content for an hour and a half…

My slides are available here.

Suppose you have delivery notification set up on a logical orchestration port (along with a catch block for DeliveryFailureExceptions).

Gotchya 1: If that port is bound to a send port that executes the flat file assembler, and you send improper xml to the assembler, you’ll get a warning in the event log along the lines of:

But you won’t get a DeliveryFailureException (or any other, for that matter.)  Nor will the orchestration progress past that point.

Workaround: Consider putting an xml validator as the first step in the pipeline (the flat file assembler will come next.)  That will cause an exception to be raised that you can catch in your orchestration…

Gotchya 2: If the message heading for a send port is terminated within the admin console for some reason, you will never get a DeliveryFailureException, nor will your orchestration progress past that point.

Workaround: No idea on this one.  Leave comment if you do…

At this year’s MDC, I’ll be doing a talk on Team Foundation Server 2008 and Scrum – all about where state of the art stands with TFS 2008 and Scrum process integration.  We’ll cover Microsoft’s eScrum, Conchango’s Scrum for Team System, and perhaps a few others to boot.

September 9, 2008 – Marriott Southwest.

The whole conference looks great – check out the speakers and sessions.

Jeff Brand has tagged me to answer a few questions on how I got started in this business…

I never do anything personal in this space, so this will be a first.  Here goes:

How old were you when you started programming?

Ummm, my grandfather supplied us with a TRS-80 Model 1 Level 1 (4k, cassette drive) when I was about 8 years old.  It started there, and proceeded through everything Radio Shack had to offer for quite some time.  No artsy Commodores/Amigas/Apples at our house…

What was your first language?

BASIC.

What was the first real program you wrote?

Gosh.  I tried my hand at writing a basic word processor for the TRS-80 – I think I called it TextStar.  I’m sure I lost some school reports as a result.  In that general timeframe were some text-based adventure games, too…

What languages have you used since you started programming?

Hmmm.  Basic and QuickBasic as a kid.  Pascal and Fortran in college.  C and C++ in all my early jobs in this field (along with VB6 to test all those COM components...)  After that, the only language I’ve approached seriously is C#.  (Does BizTalk count?)  I dabbled in a lot of other languages, but haven’t done project work, where you learn all the ins and outs…

What was your first professional programming gig?

As a college intern at CyberOptics, writing all kinds of applications for laser and vision-based inspection systems.  Very fun stuff, and some of the best mentoring I’ve ever had.  And hey, what doesn’t spell fun like writing your WndProcs for Windows 3.0 ?

If you knew then what you know now, would you have started programming?

Certainly!  This has been a great industry to be a part of.  I had serious dreams of pursuing music as a career at one time, but as David Chappell once said, regardless of what artistic value you might attach to a given gig, you’re really just there to sell beer.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Focus on the practice/art, more so than individual technologies.  Realize that the people you work with are the first order function for success, rather than a given technology choice.

What's the most fun you've ever had...programming?

I’ve always had the most fun when I’ve had the opportunity to work with a team that is “long-lived”, small, and dangerously focused. 

Often in this industry we work with team sizes (and organizational dynamics) that breed ineffectiveness.  It is amazing how much more apt you are to wake up before the alarm when team productivity is at its peek — and “in the zone” becomes normal.

Who am I calling out?

Loren Halvorsen

Matt Milner

Jon Flanders

Stephen Kauffman

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…