My loyal BizTalk readers :) may be surprised to know I'm pretty handy with writing code as well. As such I've been working on a ASP.Net site recently and had to deal with this weird situation.

If you have a webpage with two buttons 'Ok' and 'Cancel' say, and you set default button like this:

Page.Form.DefaultButton = btnOk.UniqueID;

Now lets say you're doing the right thing in regards to accessibility and paying attention to how your page behaves without the mouse and you tab to the Cancel button and hit the enter key, what do you expect to happen?

You would expect the Cancel button event to fire right? Well actually it doesn't. Even though the Cancel button has the focus, it is the DefaultButton event that fires and therefore it is the Ok button that executes. The exact wrong thing you would want to happen.

DefaultButton is implemented using a javascript method called "WebForm_FireDefaultButton". To fix the issue I've just described the solution was to add a javascript file to the page (in my case it was the Master page) that overloads that method. In a nutshell this overloaded method checks to see if the the focus is on a button and if it was the enter key which was pressed. If those two things are true, the FireDefaultButton is ignored. This is the script that we used:

 

// In the case where a defaultbutton is programmatically set button A the user tabs the focus to button B and hits the enter key, button A will fire. This is the workaround.

 

if (typeof(WebForm_FireDefaultButton) != 'undefined' )

      var origFireDefaultButton = WebForm_FireDefaultButton;

 

WebForm_FireDefaultButton = function(event, target) {

    if (event.keyCode == 13) {

        var src = event.srcElement || event.target;

       

        // Don't call original function if focus is on a button

        if (src &&

            (src.tagName.toLowerCase() == "input") &&

            (src.type.toLowerCase() == "submit" || src.type.toLowerCase() == "button")) {

            return true;

        }

    }

   

    return origFireDefaultButton(event, target);

}

As you can see, fortunately, the script is very lightweight and won't therefore cause much of a performance drag.

This question and response came up on a forum. I've never seen this referenced before so I thought it was worth blogging.

 

Problem:

BizTalk is receiving a flat file (can contain up to a million records) and doing a disassemble in a pipeline using a flat file schema. The individual messages are processed by  a sequential convoy (Singleton) based on a correlation. The orchestration receives the message in a loop that follows the correlation set from the receive port where receive location split the flat file into smaller messages.

To specify a proper exit criteria to exit the loop and stop the convoy I need to know the number of messages in the flat file. But since I am using the default flat file disassembler, I have no clue how many messages are in the  file.

 

Solution:

There’s a property promoted in the last of the disassembled messages in an interchange: BTS.LastInterchangeMessage = true.  This tells you the last message in the interchange and in conjunction with BTS.InterchangeSequenceNumber you can tell the total number of messages in the interchange (in case you get them out of order).

One of the areas that has historically been weak in the BizTalk world has been the operations piece. Well not any more. The BizTalk product group has, at the urging from people such as yours truly, put together a very comprehensive operations guide. BizTalk administrators now have a guide which contains pretty much everything they could need in one document. Its good stuff!!

The BizTalk Server Operations guide is now available for download in DOCX, CHM, and PDF file formats at the following locations:

http://download.microsoft.com/download/a/a/d/aad035e6-e03b-4bea-ad9a-fa1ff8d10ca0/BTS06R2_OpReadiness.docx
http://download.microsoft.com/download/a/a/d/aad035e6-e03b-4bea-ad9a-fa1ff8d10ca0/BTS06R2_OpReadiness.exe
http://download.microsoft.com/download/a/a/d/aad035e6-e03b-4bea-ad9a-fa1ff8d10ca0/BTS06R2_OpReadiness.pdf

If you're a nerd/geek like me, you will have noticed that the lego brick just had its 50th birthday. I think we should all take a moment now to commemorate such a profoundly important invention.

Let me explain. If you do a snap poll of all the people you know who build software, you will discover a very high correlation between the hours spent playing with lego as a child and their abilities with software. Why is this? Because lego requires you to assemble and disassemble larger objects from smaller objects. It requires you to be able to envision in your minds eye what could be created, and then also think about how to implement it. It teaches you to think about each individual component while simultaneously thinking about the whole.  It also requires an ability to hold complicated geo-spatial models in your head and then perform creative variations and run 'what if' scenarios on those models. The same parts of the brain that use you to do this with lego, are the parts we use when building software. These are all foundational mental skills required to be a good software developer.

So imagine if all the software people in world didn't grow up playing with lego?? Where would the software industry be now? Some less extreme variation on the scenario in the movie Idiocracy perhaps?

Lego is just one of those little things that we take for granted - like s-bends in plumbing. (Have you ever stopped to wonder just exactly how significantly the s-bend improves the quality of your life? You should)

So lets all take a sentimental moment to think about the impact the humble lego brick has had on our lives. (Or if you somehow missed on growing up playing with lego, you could commemorate the s-bend.)

Its a funny old thing writing a blog. You never quite know which posts people will care about and which they wont. Well except maybe the blog posts you write to get some miscellaneous topic off your chest -- those ones you know people won't care for. Where was I? Ah yes, so I was doing some blog maintenance and I got to looking at my stats, as feeble as they are, and it seems that this post on what makes a good BizTalk administrator is by far and away the most popular post. It also bounces between rank 3-6 on "The Google" for the term "BizTalk Administrator". Interesting eh? Seems like it had the desired effect. Company's have cottoned onto the idea that a BizTalk Administrator is a necessity analogous to a DBA.

A quick look around the intertubes shows quite a few mentions of the word "BizTalk adminstrator" and I see quite a few jobs ads for it. You could say my job here is done. So all those newly minted BizTalk Administrators out there owe me a debt of gratitude. I take paypal.

That wasn't really a state of the union address was it? That was a little trick I played on you. See I like to use subjects that make you think its going to be interesting and then waste your time by rambling on and on about increasing boring stuff. Say, did you hear the one about the man and a dog who go into a bar? Or maybe it was church. So a man and a dog go into a church and the bartender says to the man, "he can't come in here", then the dog says to the priest behind the bar, "why not"? Then the nun says ...wait I forgot the punchline.  You really should have stopped reading already.

As an IT geek, Dilbert has been my favourite cartoon for a long long time. It was the only cartoon that came close to reflecting my experience of the world as a cube rat.

However, Dilbert's place has been usurped (sorry Scott Adams) by Randall Munroe at www.xkcd.com. Randall is brilliant (he built robots at NASA so its not really hyperbole to say that) techically and comically as well.

His creations are a fresh take on all things geeky and I'm becoming a big fan.

I predict Randall Munroe will be the next millionaire cartoonist a la Scott Adams.  The tshirts have started. The books will follow soon.

 

here is a particular favourite

Lets say you were looking to buy a new car. You visit a car dealer to look at your options. You tell the sales guy the type of car you're after and he directs you to a red one. You like red so you open the door and sit behind the wheel. As you cast your eye over the interior your intelligent brain registers an incongruence. THERES NO DASHBOARD! The steering wheel, gear shift, pedals are all there, the things looks like a car should except there are no gauges, dials, or dash lights. In a state of confusion you turn to the sales guy and blurt out "what the hell?" The sales guy smirks at you, puts his hand on his chin in a thoughtful pose and says "We ran out of budget when we were engineering this model of car, so we went into production without the usual dashboard". "But how would I know if the engine is overheating and about to cook itself?" The sales guys shrugs. "What about oil pressure. Surely you have a sensor for that?" The sales guys shrugs again.

In a state of disbelief, you quickly decide to put some distance between yourself and such an misconceived infernal machine just incase its evilness somehow infects you while in close proximity.

So obviously no car manufacturer would do such a bizarre thing, but how is then that sometimes, people put a complicated piece of server software (such as BizTalk) into production without the ability to see what's going on "under the hood"? It, of course, depends on how critical the application is, but if you know it will cost $$$ if your application is down, you need a good level of application level monitoring.

What I see quite often is customers who have OS level monitoring of the BizTalk boxes. This is typically a product like Tivoli or BMC Patrol. Maybe they have configured their OS monitoring tool to monitor whether the BizTalk host process is in the started state or not. That is about the equivalent of having a light on the dashboard of your car telling you if the engine is running or not. Not very helpful. (But I might add, it is better than nothing at all).

The problem with OS level monitoring is that none of these tools have visibility into the health, stability or performance of the application level (BizTalk) processes. As we know, BizTalk is a complicated beast. There is a lot going on under the hood. Don't you think it makes sense to have maximum knowledge of what's going on so you can fix problems before they become critical? Isn't that why we have engine diagnostics in our cars these days?

Take a look at the BizTalk Server 2006 R2 Microsoft Operations Manager Management Pack list of contents. http://technet.microsoft.com/en-au/library/aa561939.aspx. Isn't that the kind of list that you'd really want to have monitored for your production application?

Here's how it is: OS level monitoring is not enough. If you care at all about best practices you need to know what's going on in BizTalk. The more visibility you have the better prepared you will be for the production down critical situations. The only product that does this out of the box is Microsoft Operations Manager 2005/System Center Operations Manager 2007 with the BizTalk management pack.

For more information on this topic, go here: http://technet.microsoft.com/en-au/library/aa577973.aspx

 

Mark

As i mentioned earlier this week i am now a "Consultant". This means i will spend most of my working life from this point forward on customer sites. Thats fine except I am now required to wear "notjeans". In my world there are two kinds of pants. Jeans and NotJeans. NotJeans are for weddings, funerals, court appearances and job interview dentist appointments. My sad realisation which i was aware of already but of which I was in deep denial about is that i am now required to wear NotJeans to work.
Sigh.

Well, its groundbreaking and earth shattering, if you're either Me or if you care in any way about my career. That of course limits the impact of this news to about 4 people, all of which are closely related to me (and none of which read this blog).

However, as of today I am now a "Consultant". I have just had my first day in Microsoft Consulting Services as a BizTalk Consultant. So far it feels the same as being an Engineer so maybe they forgot to give me my upgrade to my social/influencing skills. Also they seem to have forgotten to retrieve from me my hardcore geek, brain upgrade kit that I had from my last job.

Anyway needless to say I'm "super excited" to be starting this new job although a little sad to be leaving my old team. But life goes on right? 

So if you're either of my loyal blog readers and you need a BizTalk operations consultant, I'm now OPEN FOR BUSINESS.

Mark

After my last post on this topic Alan Smith left a comment on my blog.

His comment was a good point and is worthy republishing here, to round out the topic.

Here it is verbatim:

"I'd agree with you there that quite a few .net ppl will try to solve problems with C#, rather than learning the correct way to solve things in BizTalk. I spent my first few weeks thinking "I can do this in 2 hours in C#, why does it take me 2 days in BIzTalk?". As you get your head aroud how BizTalk works, you do things in BizTalk in 2 hours that would take 2 days (or 2 weeks) to do in C#.
But there's also a catch 22 here, if I was hiring a BIzTak guy, i'd pick someone who was a good .net (or java) developer. Even though you don't 'usually' write much code, there are situations when you need to, and you need to have good programming skills to do so. Custom pipeline components, custom functoids, and C# utilities to call from orchestrations are usually required (ok, maybe not functoids) on most BizTalk projects, and the code for these component needs to be solid.
Along with the dangers of having .net ppl solving everyting with C#, you also have the danger of ppl who are scared of programming jumping into BizTalk development because thay think it's easy, and think they can build apps by drawing things."

 

It never occurred to me that a non developer would look at BizTalk as a way to dev work with out code. Thats never gonna work. BizTalk is well and truly a developer technology.