BizTalk Server 2010 Released – Developer Edition Now Free

Microsoft has just released BizTalk Server 2010, and it is now generally available! Along with this release comes an updated licensing structure that will be a relief for consultants, and companies managing multiple BizTalk environments. While the cost of the Enterprise edition has increased, the cost of the Developer edition has been eliminated. The Developer edition includes the full capabilities of the Enterprise edition, with the limitation being only that you cannot use it in production.

The pricing and licensing page sums this up saying:

Note: Many customers who deploy BizTalk Server implement separate development, testing, and production environments for their BizTalk Server 2010 solution. For the development and testing environments, you can use the free download of the BizTalk Server Developer Edition.

For the production environment, you need a valid processor license of BizTalk Server 2010 Enterprise, Standard, or Branch Edition for each processor on which you install an edition of BizTalk Server 2010.

I applaud this move by Microsoft, as it could encourage a new generation of developers to download and experiment with this powerful platform. This is a move that could drive adoption while at the same time potentially lower the TCO for those organizations managing multiple environments. Given the nature of BizTalk Server, I trust that this will not result in an equivalent of Eternal September for the BizTalk community, but don’t quote me on that remark.

To further help out developers that are new to BizTalk Server in general, we are offering a major discount on our BizTalk Developer Fundamentals online course. Simply use promo code BT2010 when you register, and you will receive $295 off a self-paced registration. This offer expires at the end of September, so act fast!

Finally, go and get BizTalk Server 2010 while it’s still cached at a CDN server near you!

ESB Guidance 2.0: Build Loosely Coupled Solutions You Can Be Proud Of

It is no secret that Microsoft has been working on bringing its Enterprise offerings up to date, readying them for the next generation of applications and services, and fixing small pain points that have vexed developers for years. In just a short while, BizTalk Server 2006 R2 will make way for BizTalk Server 2009, and another interesting product from Microsoft will realize next version status. That product is Microsoft Enterprise Service Bus (ESB) Guidance 2.0.

What is an Enterprise Service Bus?

Dmitri Ossipov, a Senior Program Manager for Microsoft working on the ESB Guidance, in his interview on .NET Rocks defined ESB as an “architectural paradigm for policy driven mediation.” Nicholas Allen, a Program Manager at Microsoft working on BizTalk Server, argues that “the clearest definition of what companies think ESB means comes from looking at the products that they build.” In the case Microsoft’s ESB offering we see a solid implementation of the Routing Slip pattern built on top of BizTalk Server sprinkled with ample extensibility points. In the world of the ESB Guidance Routing Slips are called Itineraries, and act like an order placed at a menu of services that is the bus. The ESB Guidance provides flexibility through a loosely coupled design that allows routing and transformation decisions to be made at runtime instead of having to be statically configured at design-time. This enables service composition, dynamic transformation, and adds support for scenarios previously unimaginable in a BizTalk Server environment.

Version 1.0 of the Guidance was a paradigm shift for many BizTalk and .NET developers, but version 2 has the potential to take it to the next level. It introduces some killer new features such as the Itinerary Designer that can reduce XML induced eye-strain, Generic On-Ramps that allow you to send a message into the bus on the consumer’s terms, and support for Server-side Itineraries that can place ESB developers back in control of the content of their Itineraries.

Itinerary Designer

Someone once said, “XML is like violence, if it doesn’t solve your problem, you’re not using enough of it.” I’m not going to debate the truth of this one way or another, but I do find it interesting that XML is compared to something that causes such a universal adverse reaction. When color-coded, perfectly indented, and collapsible, I can handle XML. However, at that point I have already resorted to looking at a more human friendly representation of the data instead of the raw data itself.

Those who have downloaded the January CTP of the Guidance, have found themselves in the midst of peace – no XML to be seen (don’t worry it’s still there if you dig). The January CTP now includes a Visual Studio designer for Itinerary models. Creating Itineraries is now as simple as dragging On-Ramps, Itinerary Services and Off-Ramps into a visual model that can be exported to a repository, or as XML – even mere mortals can do it.

Server-Side Itineraries

Yes, I just said the word repository. Version 1.0 of the guidance was awesome, but it did leave developers with a puzzle: “How do I get the itinerary I need to route this message, and how do I get it to the server?” The answer of course was that you have the XML of the itinerary that you send within the header of the message when submitted to the Itinerary Processing web service.

But where do you get the XML from? How do you know it’s valid? Well, with CTP2, you know an itinerary is valid because it was modeled in a designer that validated it before each save and export. With CTP2 the XML can be retrieved from a SQL database (which bears a striking resemblance to the rules set database in BizTalk Server), and applied to the message in a pipeline component.

BizTalk and WCF enthusiast Bram Veldhoen remarked on his blog that it would “be a good idea to have the ESB be responsible for assigning the Itinerary headers.” Microsoft apparently agreed, and this is exactly what should be expected from this new version of the ESB Guidance.

New Resolvers

The latest ESB 2.0 CTP adds three new resolvers for resolving itineraries: BRI, ITINERARY, and ITINERARY-STATIC. This means that not only can consumers rely on the ESB to apply itineraries for them; the ESB can do it dynamically. For the ESB Guidance uninitiated, Resolvers are these wonderful classes within the ESB Guidance that can take a configuration string, parse it and execute a query of some sort to look up information necessary for transformation, routing, or some other custom process.

The first is the BRI resolver; a typical resolver connection string would look like this:

This string, when interpreted by the BRI resolver (the BRE moniker was already taken for a resolver that cannot retrieve itineraries from the repository), will tell the resolver to use the Business Rules policy named SamplePolicy to determine the Itinerary to use for routing. It will also include the message as a fact when calling the Rules.

The second is the ITINERARY resolver; a typical resolver connection string would look like this:

This is a static choice of an itinerary named Zebra. Its sister resolver ITINERARY-STATIC does exactly the same thing but is implemented using the Unity Application Block, but that’s a discussion to save for another posting.

You would use such resolver connection strings in the configuration of the ESB Itinerary Selector pipeline component, which is part of the ItinerarySelect* family of receive pipelines included with the ESB Guidance 2.0 CTP. Since this is all part of a pipeline, that means that in 2.0, you can create Itinerary On-Ramps that are first class citizens in the ESB which use transports other than an ASMX web service or WCF web service. The possibilities are limited only to the adapters installed.

Getting it Right

The new version of the ESB Guidance brings new features, enhancements, and fixes that really make it feel like a polished product. With version 1 they got it shipped, but with version 2 they’re getting it right.

kick it on Shout it

5 Reasons You Should Use the WPF TextBox in Your Next App

With the release of the .NET Framework 3.0, and then the .NET Framework 3.5 late last year, you might have settled down and started to integrate some of their more powerful features in your day to day programming. You may have absolutely fallen in love with LINQ, and embraced lambda expressions in C# 3.0. But have you taken a good look at WPF? WPF is not just for flashy effects, perfect transparency, and smooth animations. It’s not limited to kiosks and Silverlight infused web pages. It provides base components out of the box that can blow your WinForms socks off — and not just visually.

In this article I will pit System.Windows.Forms.TextBox against System.Windows.Controls.TextBox in a completely biased and unforgiving matchup, and give you 5 reasons why you should ditch the your old WinForms TextBox, and start using WPF. So grab the sample code, and follow along.

0.) It Works in a Windows Forms Environment

The rest of this article would kind of be pointless if this was not included, but you can use the WPF TextBox control from within a Windows Forms application. All you need to do is include some references, and add an ElementHost control to the form. I’m not going to get into specifics here, because there is plenty of coverage of this elsewhere.

1.) It Has Spell Checking Built-In

Spell Checking

This is something that I’m surprised has not received more coverage. People get caught up in animations, and the ability to completely change the appearance of controls, and miss the fact that a simple task is now actually simple. You don’t have to rely on your users having a $200 piece of productivity software installed to do spell checking on your “Approval Comments” field. You can just use a more intelligent TextBox.

So how much code does it take to get your WPF textbox to do what it’s doing in the screenshot? Count for yourself:

wpfTextBox.SpellCheck.IsEnabled = true;

But what if you want to actually make your application aware of the individual spelling errors themselves? There are methods provided for that as well. Here’s an example of how you might use the built-in methods to build a Dictionary of character positions where spelling errors have occurred, and the text that is spelled incorrectly:

 int index = 0;

Dictionary spellingErrors = new Dictionary();

while ((index = wpfTextBox.GetNextSpellingErrorCharacterIndex(index, System.Windows.Documents.LogicalDirection.Forward)) != -1)
 string currentError = wpfTextBox.Text.Substring(index,
 this.spellingErrors.Add(index, currentError);
 index += currentError.Length;

2.) It Has A Real Undo Stack

Have you ever written code that manually called the Undo method of the TextBox control, and been disappointed with the results. Spoilers follow for those who have not tried this: it only keeps track of the last state of the text. Since the advent of Adobe Photoshop* in the late middle ages, people have grown accustomed to programs being able to undo as many actions as they have done. Well with the WPF TextBox control that functionality is built-in. If you find implementing a custom Undo Stack fun, then cling tightly to the WinForms TextBox, if you would rather forego that task so that you can focus on a more important problems continue reading.

What code do you need to get it working? Check it out:

wpfTextBox.IsUndoEnabled = true;
 wpfTextBox.UndoLimit = 1024;

Oh yeah, and whereas the System.Windows.Forms.TextBox control has an Undo method, the WPF equivalent supports this beautiful couple:


Just be sure to never include those two lines of code one right after another like that. People have been immortalized for less.

3.) It Handles Lines Intuitively

Go ahead and click the screenshot to the left. Okay, pop quiz: What line is highlighted? If you said the line beginning with “Integer ac tortor”, System.Windows.Forms.TextBox says you’re incorrect. Many programmers might agree with the Windows Forms TextBox control, and that’s because they’re right. Technically the text is word wrapped, and the newline character doesn’t occur until the very end of all of the text pictured. But looking at this from a user experience standpoint, it’s terrible. When wrapped, that is the third line of text, not the first.

With the Windows Forms TextBox control, you access the lines of text through the Lines property of the control. Unfortunately, I can do that much myself by Splitting the Text property on ‘n’ and Trimming the result. The WPF TextBox control, on the other hand, does some heavy lifting for you. It can tell you what line, visually speaking, is the current line of text. It can also tell you what line that would be more mechanically speaking. Good luck trying to do that with the Windows Forms TextBox control, but here’s how you might do it with the WPF Textbox:

int characterIndex = wpfTextBox.SelectionStart;
int lineIndex = wpfTextBox.GetLineIndexFromCharacterIndex(characterIndex);
string currentLine = wpfTextBox.GetLineText(lineIndex);

4.) It Uses Anti-aliasing To Make Text Readable

Let’s be honest, your grandma’s web site makes use of anti-aliasing, and there’s no reason your LOB app should avoid it. It’s easier on the eyes, easier to read, and makes your text look great in any resolution. With the WPF TextBox control there is zero effort, configuration, or lines of code to achieve this effect. It’s supported out of the box and always looks great.

5.) It’s Included For Free in the Framework

Since WPF is included as part of version 3.5 of the .NET Framework, you can use it anywhere that you can install it. You don’t have to buy a third party component to take advantage of all of the features of the new TextBox, it does not require Windows Vista, you don’t need to install Expression Studio, and you don’t have to write a line of XAML. You can use your favorite language to leverage the classes you need when and where you need them. You could even use it to implement spell check within an ASP.NET web application. Don’t even think about reaching for Word Automation.


The WPF TextBox wins – use it. It also supports the aforementioned flashy effects, perfect animation, etc…

* – Save for Adobe Photoshop LE where they thought it would be fun to limit undo – shame on them

Building Expert Series training for BAM

Over the past month I’ve been working really hard on our new BizTalk Expert Series class for Business Activity Monitoring. I have to say that I’m really excited to start teaching it. In three days, we manage to cover almost everything one could want to know about BAM. The most interesting part of it for me is the data consumption lab. I’ve never been very fond of the BAM Portal. It’s nice, but certainly not something that I’d like to parade in front of a CEO of a big company. Don’t get me wrong, the capabilities are awesome, but the way it looks and some of its behaviors aren’t the best. In the consumption lab, we examine how to create custom consumption models for BAM data using PerformancePoint, SQL Reporting Services, and an AJAX based web site. I’d never worked with PerformancePoint before and I was surprised by how easy it was to create a dashboard based on the BAM OLAP cube.

Resuming Suspended Messages

Last week while teaching the BizTalk Developer Immersion, I was demoing how to resume suspended messages using the BizTalk Group Hub. I submitted six messages while my send port was stopped, so all the messages were suspended. I was foolishly trying to show my students that if I resumed the message, it wouldn’t be processed because the send port was in a stopped state. I resumed the message and it disappeared, actually, it went out through the send port. This confused me, I had six suspended messages, I resumed one and it was processed so I only had five. But why? I couldn’t figure it out, the port is stopped, the message shouldn’t be processed but if one went through why not all of them. I was stumped, then it occurred to me. If I were in production there are dozens of scenarios where I could have dozens or hundreds of messages in the MessageBox waiting for my send port to start, but before I actually start it all up, I want to send a few specific messages as a test. By stopping the port I can see all the messages that the port subscribes to and choose which ones should go through. So now I think it’s pretty cool.

BizTalk 2006 Book Rating

Students frequently ask my opinion on which BizTalk Books will be most helpful. I have reviewed several books, and will recommend a few of them here. I haven’t really seen any terrible BizTalk 2006 books (and believe me, I have seen some terrible technical books in the past!), so this is really a ranking of several really good books. It should be noted that many of the books below mention BizTalk Server 2006 R2 only in passing, because they were all written prior to the release of R2. I do not know if updates are planned for them.

In the interest of full disclosure, I should mention that QuickLearn has received a slew of books from Apress that we occasionally pass out in classes (thanks, Apress). Also, Darren Jefford, the author of one of the other books, is a friend and has provided signed copies of books that we have given away at various conferences. Despite my affiliations, I hope to provide a fair assessment of the literature.

The top of my list is Professional BizTalk Server 2006, by Darren Jefford, Kevin B. Smith, and Ewan Fairweather, published by Wrox Publishers. “Wrox” is pronounced like “Rocks,” which is exactly what this book does. It’s very telling that, as I was writing this post, Amazon has eight listed reviews, and all eight give the book full marks (five stars) – I would definitely give it the same. Because this book assumes a moderate level of existing BizTalk knowledge, it is definitely not a good book to learn BizTalk from scratch (it’s a great companion book to our Deep Dive). Nevertheless, it’s a book by three guys who have been there, done that, and own the tee shirt when it comes to BizTalk implementation. This is a book that I refer to frequently.

Coming in at a close second on my list of favorites is Pro BizTalk 2006, by George Dunphy and Ahmed Metwally, published by Apress. (These books share more than a similarity in their names!) This is also an excellent book with very similar coverage to the Wrox book (Deep Dive level). If you own either of these books, you’re in good shape. I prefer the writing style of the authors of the Wrox book, but you may like this one better. Either one or the other of these is great, but you probably won’t need both.

If you’re looking for a book for someone totally new to BizTalk, consider Foundations of BizTalk Server 2006, by Daniel Woolston, published by Apress. This book contains good, concise description of common BizTalk terms (BizTalk vocabulary on steroids), and is a great pre-class primer for QuickLearn’s BizTalk Server Developer Immersion. If you’ve already attended any of QuickLearn’s BizTalk classes, you will probably find this book overly simple.

If you’ve identified a problem in your design/development, and you’re looking for a quick way to solve it, your best choice is BizTalk 2006 Recipes: A Problem-Solution Approach, by Mark Beckner, Ben Goeltz, Brandon Gross, and Brennan O’Reilly, published by Apress. This may not be the best book for learning BizTalk from scratch, but it’s a necessity for every BizTalk shop. This book takes a no-nonsense approach to “Here’s the problem, now how do I fix it?”, and identifies the implementation of the patterns necessary to solve the problem.

Although not a BizTalk book, per se, a good general overview of messaging and other integration patterns can be found in Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, by Gregor Hohpe and Bobby Woolf. DO NOT EXPECT TO LEARN ANYTHING ABOUT BIZTALK FROM THIS BOOK! I am recommending this book as an excellent resource about integration in general non-Microsoft terms; however, many BizTalk-related documents, available from Microsoft sources, reference the patterns revealed in this book. So do the BizTalk 2006 scenarios (more on these later, if you aren’t familiar with them). Gregor maintains a site that contains much of the information available in the book, but the book still makes a great paperweight, (it’s big and hardcover) J. I have been referencing it in my classes for so long that I thought I better mention it here as well.

Where’s my functoids?

QuickLearn is in the process of updating our now famous BizTalk Deep Dive course (NEW and IMPROVED!). As I have been collecting and reviewing content for the advanced mapping module, I am reminded of one of the most common “Eureka” moments for many students is the realization of just how easy it is to create custom maps without using functoids. Many people come to BizTalk after having developed a custom integration project that required them to create their own XSLT. Often I am asked, “Can’t I leverage the work that I’ve already done and use the XSLT I’ve created? Do I have to use all those functoids?” The answer: Of course you can use your own XSLT, and some of the best maps do! You really have three options here: The first two involve the use of Scripting functoids; the third relies strictly on the XSL that you provide.

Inline XSLT

Many times, the result of chaining several functoids together can be more concisely defined in a little custom XSL. When using the inline XSLT option, the Scripting functoid cannot have any input links; rather, it should contain references to the source schema nodes through XPath expressions. The functoid must link directly to a record or field in the destination schema (it cannot be input for other functoids).

Inline XSLT Call Templates

Like an inline XSLT script, the inline XSLT call template must connect directly to a destination node; however, it may receive input through links coming from other functoids, or from the source schema. On the map grid, setting the Custom Extension XML property enables Scripting functoids, configured as either Inline XSLT or Inline XSLT Call Templates, to make calls to external assemblies.

Custom XSLT Code (Look ma, no functoids!)

If you have XSLT code you have written to convert instance messages, you can use that code directly, instead of creating a map.

  1. Create an empty map and set the source and destination schemas as you normally would.
  2. With the map grid selected, configure the Custom XSLT Path property to use the file containing your custom XSL.

NOTE – Using custom XSL overrides all links and/or functoids in the map.

Remember that you can always validate your map to access the generated XSL, which will be executed for the map. Also remember that maps do not validate the messages generated, except while testing in Visual Studio. The warnings you receive in Visual Studio provide design-time assistance to identify possible problems. BizTalk is totally content with generating exactly the message that you tell it to, valid or not!

Until next time, have a great day.