trace of thought (Scott Colestock) - BizTalk Insights

BizTalk 2009 thoughts...

Scott Colestock — Mon, 15 Dec 2008 19:23:55 GMT

Have you had a chance to play yet ?

Many folks have noted that a lot of the Visual Studio elements that have been present within BizTalk to support the development experience are no longer...quite so BizTalk specific! BizTalk projects now build upon C# projects, and thus a lot of the differences that you used to see in navigating property pages, compilation settings and build mechanics are now gone. This is a very good thing - it allows you to leverage skills you already have on your team.

MSBuild support is now first class. Everyone who went through the trouble to install (and invoke) DevEnv.exe on their build server in order to build BizTalk projects will be glad to know that this is no longer required. (Builds can be ever so much faster when you aren't relying DevEnv...)

Because of the close relationship with C# projects, you can now have C# artifacts directly in your BizTalk projects. Many people have noted that when you "Add new item...", C# classes aren't offered as an option. The product group has explained that this is because currently, the designers (such as the Orchestration designer) are unable to provide intellisense for types that are within the same assembly. So, you are required to use "Add existing item...".

(This sort of reminds me of the interaction between pipelines and schemas - the former require fullly qualified assembly information at run time, which they won't get if you combine these two artifacts in the same assembly.)

If this limitation persists, will the feature get used? I tend to think so. There are often cases where the smart thing to do in an orchestration is to delegate to a component...but the work you do in that component is, at times, so specific to the orchestration that it makes sense for them to be co-located for deployment and organizational purposes. What do you think ?

The support for unit testing is extremely welcome - check it out. Debugging maps is great as well, but I'm now (often) partial to the external XSLT approach these days.

Delivery notification gotchyas...

Scott Colestock — Wed, 25 Jun 2008 19:51:37 GMT

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:

 

The adapter "blah" raised an error message. Details "Cannot find definition for the
input: foo”

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…

Slides on Unattended Deployments...

Scott Colestock — Thu, 19 Jun 2008 19:03:48 GMT

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.)

TechEd 2008 talk on unattended deployments...

Scott Colestock — Mon, 02 Jun 2008 15:00:34 GMT

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!

BizTalk Hotrod Issue 4...

Scott Colestock — Fri, 23 May 2008 14:15:37 GMT

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.