Fellow BizTalk developer Bram Veldhoen was kind enough to send me some suggestions for a future version of my PipelineTesting library, as well as with a question that could point to a potential bug in the library.

The problem basically revolves around consuming a stream returned by the XML Assembler component in a send pipeline when testing under a library. What Bram noticed was that executing the pipeline would seem to work, but trying to read the body part stream of the output message would fail with a ComException with error code 0x8004005 (E_FAIL).

I was fairly confident this should've been working, based on my own use of the library, but I sat down to test it just to make sure. What I discovered was that indeed this can happen if the pipeline context for the test is not aware of the schema for the message being processed by the pipeline.

I added a new test to the library to make sure this was working correctly:

There are a few things to keep in mind about this issue:

1. If you're using the XML Assembler, make sure your pipeline context has all the necessary schemas. There are three ways you can do this, depending on how you are creating the pipeline:
   1. If you're using the original raw API, you can use the AddDocSpec() method of the SendPipelineWrapper class.
   2. If you're using the new, simple API, you can add the schema through the WithSpec() method, which is what the test above does.
   3. If you're using the simple API, but you're dynamically creating the pipeline, you can just add the schemas directly in the XmlAssembler configuration using the WithDocumentSpec() and WithEnvelopeSpec() methods (see the XmlAssembler.cs file for details).
2. Make sure you're testing the right thing. Sometimes, it's enough to make sure that the pipeline can be executed successfully. Remember, however, that pipelines are streaming beasts, so a lot of the work will oftentimes happen just when you read the resulting stream, thus causing the processing to happen.
   This is exactly the scenario we're seeing here today.

The second point is really important, but, for some reason, I never put much emphasis in it when creating the library and when talking about it. I think this is important enough to warrant doing something about it.

For starters, I've committed a few changes to the PipelineTesting repository. Besides adding the test above, I've also added a few ConsumeStream() and ReadString() helper methods to the MessageHelper class to make it easier to validate your components work by simply reading the entire stream from a message. I'll add a few other helper methods for this later on, but the idea is to make it so that you can write less code for your tests.

BizTalk, PipelineTesting

I just noticed that Console 2.00b140 was recently released on its SourceForge site. Downloaded it and started running right away and it's working pretty well so far. I can't tell for sure yet, but it appears to be a bit faster than b139.

The new version seems to built using VC++ 9.0 (2008), but the download zip file comes with the runtime libraries if you need them.

Console is a most excellent utility that I use everyday. Highly recommended if you're not using it yet.

Console

I don't really know much about fonts, but I still love them; particularly monospaced fonts for writing code. I've tried a lot of monospace fonts over the years, including two of my past favorites: Consolas and, more recently, DejaVu Sans Mono. Great fonts both.

However, I'm a huge fan of Damien Guard's Envy Code R font. It's an absolutely beautiful font all around and Damien has put a lot of effort into making it very readable on screen with good hinting. It just looks gorgeous on Visual Studio, particularly thanks to the italics-as-bold trick Damien came up with. (Which reminds me that I really owe Damien at least a few beers if we ever meet!)

Unfortunately, every time I tried to use Envy Code R  on one of my Ubuntu machines, the result was not what I expected; for whatever reason it just didn't look as good as it did on Windows. DejaVu Sans Mono, however, looked good on both platforms, so I was using that as my default font for GVim.

Here's how Envy Code R looked like in GVim under Ubuntu, contrasted against the Windows version (with ClearType enabled):

Ubuntu	Windows

Both images were taken using the Envy Code R at size 13. You should be able to spot several differences right away:

• The text in normal weight (non-bold) looks a bit thinner on Ubuntu
• Some characters really show a significant difference in how they are rendered. The 'm' in particular looks very thin and aligned too much to the left.
• The quotes are a lot harder to see, especially in comments where there is less contrast between the foreground and background colors.

I pinged Damien to ask if he knew what this might be related to. He pointed out that every Operating System had a different way of rendering fonts so it was natural for them to look a bit different on each one. I was, of course, aware of this and even remembered that Jeff Atwood had touched on this topic in the past. Damien also suggested I verified that my Ubuntu installation had sub-pixel hinting enabled.

I went ahead and checked it one more time, and the font settings clearly showed sub-pixel rendering and full hinting enabled:

Damien's comment regarding the settings made me remember something: I use Xubuntu, which uses XFCE as the desktop manager. However, I believe GVim is written on top of GTK+ (Gnome) and wondered if this had anything to do with it.

I went ahead and checked the Gnome settings just in case, and they did not have sub-pixel smoothing enabled; only the "best appearance" setting was checked. So I went ahead and changed the Gnome settings as well, restarted the machine (just in case) and.... no dice. The font still didn't look right.

Solving the Puzzle

After a couple of days of tweaking options here and there, I finally found a combination of settings that allowed Envy Code R to be rendered on Ubuntu a lot better for my taste.

Here's the catch: I had to enable sub-pixel hinting (setting it to RGB), but change the hinting setting from Full to Slight. This makes some fonts look a little bit more fuzzy, but it makes both Envy Code and DejaVu Sans Mono look great (or at least a heck of a lot better), which is what I wanted all along:

Turns out that the XFCE vs. Gnome thing wasn't really important after all. In the end, here's how I got it to work:

1. Open the XFCE Settings Manager, and then launch the User Interface applet.
2. Make sure that the "Use Hinting" option is set to "Slight" and that the "Use sub-pixel hinting" option is set to "RGB" (or whatever is appropriate to your screen).
3. If you have any GVim instances open (or other GTK+ based apps, like gnome-terminal), then close and restart them. Otherwise, they won't completely pick up the changed settings.

If you're using Gnome as your desktop, you can get the same using the Gnome appearance applet:

1. Run the Gnome settings UI by launching the gnome-appearance-properties application from a terminal window. I don't remember where this is located in the UI, but should be easy to get to.
2. Go to the Fonts tab and then click the Details Button. In here, set the Smoothing option to "Subpixel (LCDs)" and the Hinting option to "Slight". Make sure the subpixel order option matches your screen.
   
   
3. Apply all the settings.

Now I can enjoy Envy Code R on Linux as well as Windows .

Ubuntu, Vim, Fonts

Like most other people making a living out of working with computers, I'm first line technical support for my friends and family. This morning my sister came up asking why her computer wasn't booting anymore, so I go to take a look.

It's not pretty.

My sister got a Dell Inspiron 1525 laptop a few months ago, running Windows Vista Home, and it has been working mostly fine since then (except for a minor issue with the wireless network). Last night, however, Windows Update popped up asking her to install the latest batch of critical updates. So she installed them, of course.

This morning, when she turned on her laptop, Vista greeted it with an empty black screen, with just the cursor in it. Shut it down (forcefully), and restarted only to get stuck at the same place.

So I tried the obvious list of things to check:

1. Was the machine hanging up? Not really. You could still move the cursor, and the keyboard seemed to be responding; you just couldn't do anything at all because the black screen came before the logon desktop appeared.
2. Try starting in Safe Mode? All of the three safe mode variants (regular, with network, with command prompt) get stuck at the same black screen.
3. Try booting with default VGA drivers? Nope; still gets stuck.
4. Try booting with the "Last known good configuration"? Nope. Apparently black screen was considered a good configuration. Go figure.

I then tried the recovery console, which did manage to start correctly. Unfortunately, it's useless. I checked for booting problems, and it found none. I then tried going to a previous restore point, only to find to my dismay that the system drive did not contain a single restore point. I'm pretty sure neither me nor my sister disabled system restore, so I can only guess that Dell disabled it when it shipped it from the factory. Why? Who knows.

Off to Google I go. Apparently, we're not the only ones to get hit by this issue. I was able to find at least one other Inspiron 1525 owner stuck with the same problem, but no solutions.

I then turned to Dell support, which was, predictably, useless. Without even bothering to look up any details or see if anyone else had reported a similar issue I got the standard "reinstall windows" response. Oh, well, I also got told that "Dell recommends that you turn off automatic Windows Updates after installing Windows". Not sure what to even respond to that.

Of course, at this point, there's really no other choice, but the fact that is that, for all I know, Windows Update might crap the machine again after repaving it; and for obvious reasons not getting the updates doesn't strike me as a good alternative.

A Suspect

At this point, I still don't know for sure what might have cause the issue. I do, however,  have a suspect. I noticed this morning that Vista had also downloaded and applied the updates on my own laptop (a Dell Latitude D820), without any nasty side effects.

So I checked the list of updates installed and ran into the hotfix mentioned by KB951618:

A black screen issue occurs on a Windows Vista-based computer or a Windows XP Service Pack 2-based computer that has Onekey Recovery 5.0 installed when you upgrade the operating system.

Well, the article never explains what a "Black Screen Issue" really is, but it sounds familiar. We don't have OneKey Recovery (at least in theory), but it's the only thing that sounds even somewhat related.

To be honest, though, I'm not even sure if that update got installed on my sister's laptop or not, since the recovery console doesn't really let you do much spelunking around (and I'm not very familiar with it).

Looks like I get to spend some quality time installing Vista again. Yippee!

Vista, Windows Update, Dell

Neil Houghton asked a couple of days ago if I could share my PowerShell prompt() function. Here's what my prompt looks like:

I tried to keep my prompt relatively short while still on a single line. There are two things I care about in my prompt: The machine name I'm working on (useful when I have VMs opened) and the current path, in abbreviated form.

Thus, my prompt() function looks like this:

The abbreviation of the current directory is partially inspired by Unix (use ~ if it's under the $HOME) and partially by how GVim shortens paths for its tab captions:

Here's the function that takes care of this:

One thing to keep in mind regarding shorten-path: I do a very simple replace of $HOME by ~. The reason it works correctly is that I ensure in my profile script that the $HOME variable has a fully qualified path and "completed" using the resolve-path command. I also modify what the home directory is under PowerShell by using a trick I've described previously.

PowerShell, Customization

I've mentioned in the past some of the color scheme scripts that I've used to make Vim nicer, and there are some really nice ones. However, I was growing tired of them lately. I looked around the Vim site trying to find something better but came up empty handed.

Around that time I ran into Hamish Macpherson's blog, and noticed he was using a really nice color scheme on his code screenshots, and then read in one of his comments that it was a slightly modified version of the monokai theme for TextMate.

I decided to try porting them to Vim, though it's a very loose port. I've been using and tweaking it for a few weeks now, but I'm pretty satisfied with it. I decided to post it here just in case anyone else is interested.

There are two variations to the theme; which one is used can be controlled by setting the g:molokai_original variable in your .vimrc file.

The default option (molokai_original == 0) uses the dark gray background variation similar to Hamish' version, and looks like this:

With molokai_original == 1, the script will use the original monokai colors, and looks like this:

You can get the script from my dotfiles repository on github; where you'll find always the most recent version. Enjoy!

Vim, monokai

I thought it would be fun to bring up a list of some small things I love about using PowerShell as my default command line / scripting tool on the Windows platform. Without further introduction, here they are:

Switching to Network Shares

One of the most annoying limitations of the old cmd.exe was that it provided almost no support for network shares that were not mapped as drives.

The PowerShell provided model, fortunately, didn't make this mistake, so you can use set-location to switch to a network share and execute commands there just like in any other local folder:

Location Stacks

Like other shells, PowerShell supports pushing folders into a stack and then popping them back out, making it a lot easier to navigate around a few folders without having to remember the complete paths each time. You manipulate the location stack using the push-location and pop-location commands, which are aliased to pushd and popd respectively.

I find this very useful when running doing builds or when working with Vim and some scripting language.

The PowerShell implementation, however, has a couple of advantages:

1. It works on the provider model, so you can push/pop more than just file system locations. For example, you could use the location stack to move around the registry.
2. It supports multiple stacks: You can keep multiple, named location stacks at the same time by simply using the -stackName parameter: 
   
   

The contents of the location stacks are stored as part of your PowerShell Session State, and you can see the contents of each stack by using the get-location command:

Notice that the default stack will always have an empty string ('') as its name.

It's .NET-based

The fact that PowerShell is based on the .NET Framework can be confusing to some people due to some of the underlying complexity of the framework leaking to the shell (like value types).

However, for a developer like me, this is a great thing. It means that a lot of the things I used to create small C# apps for, like quickly trying out a framework class/method, I can now try interactively on the shell. It also means that there is a lot of functionality already built, right at my fingertips that can be used very quickly.

Here's an example: I was recently working on a new Virtual Machine I had just setup and needed to generate a new GUID. I'm very used to going to the command line and running the old uuid.exe utility to do this, but, unfortunately, I had not installed the Windows SDK on the VM yet and was not planning to. With PowerShell, though, this was not a problem:

Shell Introspection

Another aspect that I really enjoy about PowerShell is the built-in introspection features. It's a lot easier to learn the shell when all the information about what's available and the objects you're manipulating is easily accessible.

Here are some of the introspection features I like:

• The get-command command. Great way to see what commands are available. Coupled with get-help, it's a really nice way to figure something out.
• The built-in providers. One really nice feature of PowerShell is that functions, aliases and variables are all exposed as providers, meaning you can list them / examine them to your hearts content using the standard location commands like get-childitem. Just try running "ls function:" or "ls variable:" next time.
• The $MyInvocation, $ExecutionState and $Host variables give you access to plenty of information about the execution environment, as well as lots of options for manipulating it.

No need for Calc.exe

I used to constantly start calc.exe to do a quick calculation. Since PowerShell is a full scripting language, however, I now do most of those quick calcs by directly entering expressions into the PowerShell prompt.

It's a heck of a lot easier and very convenient for me since I always keep around a PowerShell prompt opened and ready to go.

PowerShell

Just saw the announcement that the final, non-beta release of Vim 7.2 had come out. Go forth and download!

Been using the beta for a while, but I'm already updating my Windows installations to the final release.

Vim

I started having some problems on my Windows Vista machine lately regarding sleep/hibernation: Sometimes (but very often) the machine would not wake up. Well, actually it seemed it had woken up correctly and the keyboard seemed to work, but the screen would stay black no matter what I'd do.

I also noticed that when this happened, trying to shut down the machine again wouldn't work either, so I had to resort to completely shut down power to it and reboot from scratch. Looking at the event log, though, it would indeed appear the machine partially woke up, even to the point that the network cards would pick up an IP address. No errors at all on the event log.

However, I suspected this was the fault of a recent hardware change: I had recently gotten a Microsoft LifeCam VX-7000 to replace my older VX-6000 and I had installed its drivers and software (which I'm sorry to say is still crap).

Next time the machine hung while trying to come out of hibernation, I tried disconnecting the LifeCam from the USB port before turning the machine on. No dice; it still hung up.

But then I noticed that if I disconnected the LifeCam before putting it to sleep/hibernate, it would wake up without a hitch! Weird, to say the least. I still don't know what the LifeCam drivers do or why they might cause the issue, but at least I know how to work around it for the time being.

Vista

Every so often I see people asking in the newsgroups how to solve certain challenges they encounter while working on their BizTalk applications. One common question revolves around being able to go "back to the past" when an error happens during processing of a message.

This isn't a bad question at all, and usually revolves around how to simulate the behavior of atomic transactions in an environment where transactions can be a lot more complex and not always as natural.

The question usually goes like this: "I'm receiving a message in BizTalk, which is triggering an orchestration instance. The orchestration does this and that, and if it any of those things fail, I want to put the message back where I got it from".

The question might seem simple, but it's not always necessarily so. In fact, sometimes you have to stop a moment and ask yourself whether this really makes sense. There are several aspects you need to consider:

1. Handling the case where "this" causes an error is probably not a big deal. Handling the case where "this" succeeded but "that" failed, however, might not be that simple. Not all actions your orchestration might do can be undone.
2. Most of the time you'll find that both actions can't be done as a single unit in a single atomic transaction. Fortunately, BizTalk provides very good support for long-running transactions and compensation which can help quite a bit.
   
   Unfortunately, long-running transactions and compensation models are often misunderstood (cue in the inevitable "How long does a transaction have to last to be a long-running transaction?" jokes/questions).
   
   Here are a few articles that do a great job of describing the BizTalk Transaction features and how to use them effectively:
• Charles Young: Transactions in BizTalk Server 2004 Orchestrations and BizTalk Server 2006: The Compensation Model
• Richard Seroter: Transactions and Compensations using BizTalk Server
3. The sentence "put the message back where I got it from" can be either a very good thing, or a very problematic thing. It basically relates to leaving stuff as you found it; in particular, leaving the message back into its origin (thus relating to the transactional concept of "nothing happened here, move along")so that you can try processing it again later on and hopefully it will succeed at that time.

The problem with number 3 is that it (a) isn't always possible, and (b) it isn't always a good idea.

It might not be possible to put the message back where you got it if someone was pushing the message to you instead of you pulling it from somewhere. If you had a SOAP/HTTP WebService exposed that received a message from someone else, then you probably can't put the message back where you got it from!

On the other hand, this is a very common model for queued messaging systems: If you run into an error processing the message, you put it back into the queue and try again later. And this works great many times and can simplify error handling a great deal.

The point where this becomes a problem is when you rely on this as your only error handling mechanism. If you blindly send the message back to its origin to retry processing for any and all errors and a message comes in that always fails, you've got yourself a poison message!

I've already talked about Poison Messages in the past, so I won't comment much more on them. But there are other things you can keep in mind to improve the "back to the past" error handling technique, particularly if you don't care about message processing:

1. If you can identify and classify the source/cause of the errors, you can make your orchestration smarter about how to handle them. For example:
• Can you distinguish transient error conditions? For example, a timeout connecting to the database might be a temporary condition because of a network fluke or a server being restarted. Sometimes retrying the operation after a short while is enough to deal with this situation effectively.
• Can you distinguish errors that might require manual intervention to fix? Example: Validating an operation fails because some configuration data is missing. This is a case where you want to be proactive and raise an appropriate alert so that someone can get in there and fix the issue. Extra points if you can tell apart conditions that require intervention from a business users and those that require it from a systems administrator.
  
  Notice, however, that in this case putting the message back at the start right after creating the notification is not the right thing to do. People don't react that fast. You need to set the message aside until such time as the corrective measure has been taken and it is safe to try processing it again.
2. Can you control when the retry might happen? Can you throttle it if necessary? If the answer is no, then you might want to be very careful about using this technique. You could easily increase the system load substantially if lots of messages fail in a short time and you try reprocessing them in a tight loop.
3. Be mindful of adapters that provide no ordering semantics. For example, if your original location used the FILE adapter and you put the message back in the original folder, it will likely get picked up very soon again for processing; which can quickly get you back to step 2.
   
   At least with an adapter like MSMQ you can push the message to the end of the queue, which might buy you some time.
4. Even if you take 1, 2 and 3 into account, you still need to provide a way to deal with poison messages. Keep in mind that what started as a transient error condition can suddenly escalate to a full-blown problem you can't do nothing about, like when that temporary network fluke turns into a days-long outage after some idiot digging a whole outside snaps your network fiber cable in two.
   
   In fact, sometimes you might need to go so far as to completely shut down processing. Sometimes being able to detect that some things that should be working keep failing after an extended period of time and alerting about it can help get things sorted out before they spiral out of control.

These are just some ideas that might help make your system more reliable and more manageable. Some of them do cost money; that is, you have to invest time and development/testing efforts in getting them done, and that's where you're going to have to evaluate what makes sense and what not.

Messaging, BizTalk, Architecture