The other day I released a library (BizUnitCompare) for simplifying the testing of integrations in BizTalk using BizUnit.

Let’s say that you know what a message should look like when the integration is working like it’s supposed to. Using BizUnit you could drop a message into BizTalk and let BizTalk have its way with it. When BizTalk is done with it it might put the result somewhere on your file system.

Wouldn’t it be wonderful if you had a tool that compared the message BizTalk just put on your file system with another message containing the data like it should look and then tell you the differences – if there were any? Some of you might say that this is entirely possible using BizUnit as it is. Well, yes. It is possible. But only if you want to put in hours and hours of work configuring an XPath expression for each and every element and attribute with its expected result for your complete message (is that the echo of slowly dying BizUnit tests that aren’t being maintained?).

This is where BizUnitCompare enters the stage. With BizUnitCompare all you have to do is to tell it what the expected result is (a file stored somewhere on your file system), where to look for the newly generated file (created by BizTalk perhaps using BizUnit) and what elements/attributes/parts of a flat file it shouldn’t look at (e.g. time stamps and so on).

The whole idea behind this is that it’s probably less work to exclude the parts of a file you’re not interested in comparing rather than including everything you are interested in comparing.

Now go, get started building your BizTalk tests!

During the past day I’ve been struggling with a rather peculiar problem. It involves the following ingredients:

• BizTalk Server 2006 R2
• WCF (Windows Communication Foundation)
• A web service running on an IIS platform requiring NTLM as the authentication method
  • No authentication requirement for downloading the service metadata (WSDL)

I’ll spill the beans right away – you won’t succeed. At least not without building something involving unmanaged code (see this article for further information). This here, rather lengthy, article aims at explaining the reasons why you won’t succeed – it won’t give you a solution in the end, sorry about that. The only solution which might work is the one previously linked, haven’t tried it though. In the end we ended up opting for another authentication mechanism.

Here’s the whole story:

Due to the fact that generating the WCF client required no authentication the following problem didn’t surface until rather late in our development process, actually as late as when we were doing final tests in the BizTalk test environment.

So, what happens is this: the WCF port in BizTalk tries to send a SOAP message to the web service it’s configured to connect to. The web service states that the client (the BizTalk server in this case) is unathorized (HTTP 401, to be specific). Along with this message it says that the allowed authentication method is NTLM. As a result of the fact that downloading the service metadata required no authentication the generated configuration for the WCF port in BizTalk states nothing about how it should proceed to actually authenticate. What to do?

By now you’ll be digging around the various dialogs in the WCF adapter configuration in BizTalk looking for a place to enter a user name and a password. Depending on the port type chosen (WCF-Custom, WCF-BasicHttp or WCF-WSHttp) and the chosen binding (wsHttpBinding, basicHttpBinding or customBinding) the dialogs might look a little different. How ever, the end result is this:

• For any other port type than WCF-Custom there’ll be a tab called Security allowing you to enter credentials – but only if the authentication method chosen is set to “Basic” (or “Digest”, but that’s not really interesting for this scenario). For “NTLM” the Edit button allowing you to configure the credentials will be disabled.
• If you’ve chosen WCF-Custom as your port type there’ll be a tab named Credentials where you can enter a user name and password. Only problem is that this information will be ignored if you set the clientCredentialType to “NTLM” within the binding configuration for your endpoint. So no luck there either.
• Not even if you add the clientCredentials extension as a behavior and configure that behavior to be used for your endpoint you get settings for user name and password. What you do get though is a truck load of options for configuring client certificate authentication. Yay.

Just for fun one could try to set the authentication method (clientCredentialType) to “NTLM” within the binding, and never mind the fact that won’t be able to enter a desired user name and password. This only gets interesting with web proxy that’ll show you what is exchange between your client and the server. An excellent program to use for this is Fiddler. What you’ll notice after running the test is that the WCF port will try to authenticate with the service using the credentials held by the host process (the BizTalk host instance in this case). Of course the server hosting the web service won’t know anything about that account and therefore it’ll deny the request.

So how would you go about overriding the credentials sent by the WCF adapter in BizTalk? Should you be presented with this problem in a regular .NET run time environment (such as a console application or windows service) you’d probably end up doing it in one of the following ways:

• Creating a class which inherits the ClientCredentials (MSDN link) type in which you would explicitly set the Windows.ClientCredential.Username property along with the Windows.ClientCredential.Password property and the Windows.ClientCredential.Domain property to what ever you like. This type would then be pointed out in your WCF client configuration as the type to be used by the clientCredentials behavior extension for providing credentials (see this link for documentation about the ClientCredentialsElement.Type property, and see this screenshot for an explanation of how to set it up).
• Another way of doing it is to do it directly on your generated client proxy within your applications code. A slightly more hard coded approach, but certainly viable:

serviceProxy.ClientCredentials.Windows.ClientCredential.UserName = “HelloKitty”;

Trying to send a SOAP message from your regular .NET application using any of these methods will result in the WCF client sending the correct (as in, desired) credentials to the server and thus succeeding in authenticating.

Why all the fuss with putting the user name and password in code and not in the WCF section (<system.serviceModel>) of your configuration file? Well, it’s been decided that giving the option of declaring credentials in a configuration file is insecure and therefore should not be supported out of the box. Not a totally stupid thought, actually. Worth noting here is that your code implementing any of the two solutions above could of course read the user name and password from anywhere you want – a database, a text file, basically anything.

Considering that the actual WCF configuration in BizTalk allowed me to specify a custom type for providing clientCredentials (as seen in this screenshot) I decided to go with the first alternative. Now that I had created a type that inherits the ClientCredentials (MSDN link) type I added it to the GAC, I added the fully qualified assembly name to the type-property of the clientCredentials extension for the newly created client behavior which I had added to the endpoint (screenshot shown again here). After doing all these things the setup is ready for another test. Nota bene: these configuration options require you to use WCF-Custom as your port type.

This test will fail! The Event Viewer will have an entry in its Application log saying this:

System.InvalidOperationException: The ClientCredentials cannot be added to the binding parameters because the binding parameters already contains a SecurityCredentialsManager ‘System.ServiceModel.Description.ClientCredentials’. If you are configuring custom credentials for the channel, please first remove any existing ClientCredentials from the behaviors collection before adding the custom credential.

Yes, this will be confusing to you (and me) since we in the configuration are only allowed to specify one custom type for providing our ClientCredentials. So where did the other instance come from, and why did it get there before our custom one?

Thinking about this I came to the following conclusion: the developers of BizTalk had a problem they needed to overcome. Remember what I said about storing user names and passwords in WCF configuration files? Since this was deemed to be unsafe by the WCF team this meant that the developers building the WCF adapter for BizTalk weren’t able to solely rely on the WCF configuration file structure to provide all the data needed for the WCF port to actually execute, especially if any credentials would be required by the service in the other end. You might also remember that you, as a developer configuring the WCF options of your WCF port in BizTalk, are allowed to enter credentials if “basic” is chosen as the authentication method. My guess here is that those credentials entered in that dialog end up somewhere in the SSO database used by BizTalk. But how do they get from the SSO database to the WCF runtime when the WCF port needs to send a message?

This is where the secret sauce enters the stage! The only explanation I’ve come up with is that the wrapper code for the WCF adapter in BizTalk dynamically generates a ClientCredentials instance which is populated with any data entered by the BizTalk administrator in the port configuration. This instance is then added to the generated WCF client in BizTalk and thus disabling any other instances of the same type to be added to the same client.

So, to sum this up I’d say the following:

• The credentials implementation for the WCF adapter in BizTalk 2006 R2 is broken. Possibly in more ways than one:
  • It won’t allow you to successfully specify user name and password for NTLM authentication.
  • It won’t allow you to successfully specify a custom type providing credentials for NTLM authentication.
  • It seems to have a hard coded behavior where it insists on sending the host processes’ account details as authentication credentials when NTLM is chosen as the authentication method. This may be by design or standard – I don’t know.
• The decision to deny developers the ability to store credentials in an application configuration file is not bad – but it should be more “out in the open” that there is a security reason behind this decision. During these days I’ve seen dozens of forum threads with people trying to figure out why they can’t find a place to configure their user name and password for the service they’re accessing, all of them assuming that they have missed something, somewhere.

The solution (which I said I didn’t have)?

Use any other authentication mechanism than NTLM, atleast if the host process account has no chance of being granted access to the target service. Or try out the linked article in the beginning of this post. Good luck!

I had the opportunity to assist one of my co-workers today in troubleshooting a web service + Silverlight client I had built for a customer a while back. The combination of the two enables users to upload large files to a server over intermittent internet connections. My co-worker mentioned that she got an error message in a message box from the Silverlight client stating that something was wrong with the parameters sent to it.

In the end it turns out that the parameter for the maximum file size allowed to upload had been set to 3 GB. The specification I received when building this stated that the maximum file size that the system should be able to handle would not exceed 1 GB. So I figured a regular int would suffice for managing the maximum file size restriction.

So what this malconfiguration gave was that the Silverlight client tried to stuff the value of 3GB into an int – this is a no go. My co-worker is not to blame for this, she just got this particular setup handed to her from someone else.

What you specify is what you get.

The past couple of months I’ve had reason (more than usual) to sit back and think about all the different frameworks and patterns available out there. One specific example of this is the following:

Imagine that you would want to build a web service whose role it is to impersonate a SharePoint list. This list is then supposed to be consumed by an Outlook clients calendar tool. The data you want to fill this calendar with is stored in a database containing approximately two tables. The reason I got in touch with this was that I was asked to solve some problems regarding the switch from regular time to daylight savings time and calendar items tagged as all day events. Upon hearing about this existing system I thought something along the lines of “How hard could this be? It’s just a bunch of tables and a web service contract to fulfill.”. Well, as it turns out – the joke’s on me.

I’m not kidding when I say that the code base in the repository for this project consists of ~200 files! Factories, Repositories, Providers, Containers and god knows what! When you open a project and within the time frame of about five minutes can’t figure out where approximately to begin solving a specific problem there has to be a problem with how the code is organized. And I don’t see myself as an under qualified developer. What I ended up doing was setting a breakpoint in Global.asax at the start of a request and then step my way from there. And the funny thing is that all the database access code was hand written. NHibernate (or any other OR-mapper for that matter) hadn’t crossed the mind of the previous developer (or at least wasn’t implemented).

Grossly over engineered. That’s what comes to mind when I look back at this.

A couple of days ago I was recommended the following article: Joel On Software – Why I hate frameworks. Read it! It’s quite a funny read and I can definitely relate to this problem. I also think that this specific issue should be more widely discussed. Somehow it seems that the software development world has moved away from solving real problems to solving problems related to the problem solving. Not quite sure how that adds immediate value for the customer. Also not quite sure how it relates to working agile. If we extrapolate the current situation just a liiittle bit more we’d end up with architects and developers adding a bunch of frameworks to their project and organizing them according to some new patterns (which are bound to appear) they’ll expect the code to write itself!

And I haven’t even mentioned the frameworks managing the other frameworks.

So, as a part of my current consulting assignment I’ve been asked to work out a way of documenting the integrations that are deployed in the BizTalk 2006 platform I’m working with. I’ve stumbled across a tool called BTM2HTML/BizTalk Map Documenter (a codeplex project), but the main problem with this tool is that it only documents BizTalk maps. Orchestrations or pipelines and so forth are left out of the equation. Also the presentation of the mapping wasn’t really useful to us, it was somewhere in between technical and end user friendly. A developer wouldn’t be happy with it because it’s too much of a user presentation and the user wouldn’t be happy with it because he/she wouldn’t understand it fully.

What I set out to find was some tool that would help me extract the generated XSLT from a BizTalk map (either from the .btm-file or the assembly) and preferably not require me to manually load over 1500 projects in one instance of Visual Studio (and then right-click every single map to select “Validate map”). After asking around I got this tip: BizTalk Server 2006 Documenter (also a codeplex project). This looked exactly like what I wanted! Everything in my BizTalk platform would be documented in detail and neatly packaged into one comprehensive file. Only problem: it threw an exception when I tried to document my local BizTalk server!

It turns out that the application (or well, rather the base library that the application uses (BizTalk OM, yup – another codeplex project)) has issues with multiple versions of the same binary being installed on the same BizTalk server (i.e. in the servers assembly cache (GAC)). For some weird reason a design decision was made to store the map names, orchestration names, pipeline names, schema names and assembly names without version information as keys in a hashtable. It comes to no surprise that when confronted with a second version of for example a pipeline the application will encounter an exception due to the fact that the name already exists as a key in the hashtable storing pipelines for the current BizTalk application.

So for the last couple of days I’ve tried to spend as much time as possible extending the base library so that it will be compatible with BizTalk installations that have multiple versions of the same map names, pipeline names, orchestration names and assembly names. To be brutally honest my solution isn’t the most elegant, but it works. All it does is append the version of the artefact in question to its name when the instance of the type is created. What should be done is rather some re-engineering of the way the class library is built and how the inner collections are stored. Also, I don’t know if I’ve missed some artefact type which should be extended in the same manner just because it isn’t used in our server.

I’ll see if I can get in touch with the persons responsible for the various bits and pieces I’ve changed in order to add my efforts to the project or atleast receive some feedback. If you should feel that my changes would make your life better before I’ve managed to add them to the official project you can always contact me through this blog and I’ll be happy to send you the code (or even the packaged installation) – the license permits this from what I can see.

(Of course there’s a slight chance that I’ve completely missed something about all this multi-version yahoo which solves my initial problem with the exception, but if so – I haven’t found it yet).

Today I’m going to do something that is against my standards. I’m going to deploy stuff to a production environment on a friday.

Generally it’s a bad idea to deploy things in to production on fridays and some readers might wonder why. Well, do you like working weekends? Thought so. If something can go wrong with the package you’re deploying it most certainly will go wrong if you’re deploying it on a friday – it’s like asking for it!

Ah well, sometimes you just can’t choose. As I like to say: The money always wins. And by that I mean that the people in charge of the money always tend to win, and if they want the deploy on a friday they get the deploy on a friday.

If you’re in the same business as me – try to stay away from deploys on fridays if possible, but don’t break your back over it. Because that’ll be you dying, not them. =)

If you should have the need to some day produce a mockup of an interface without letting the person who asked for it think that you’ve actually implemented stuff behind the mockup (and thus believing that the product is ready to ship) you should have a look at this: Balsamiq Mockups. It’s a flash application, so it should work with any browser (that supports Flash of course =).

The only drawback is that it’s a demo which’ll show you a popup every 5 minutes while working with your mockup – but I think I could live with that.

Ijust finished reading this really interesting article about Windows Workflow Foundation written by David Chappell. I’ve only tinkered around with WF a bit and therefore this article was a good read in order to confirm some thoughts I had about it but also to give me a few new ways to think about WF.

If you, like me, prefer to write your own (bad? =) code and don’t mind handling threading and stuff like that yourself, using WF might not be the most appealing thing for you to use. But rest assured, something called custom activities is available and that’s the place where you wanna strut your stuff! As many others say, this technology just means you get to spend more quality time writing business-related code and don’t have to bother with the infrastructure, which – to be honest – gets a bit tedious the n:th time you implement it.

Happy reading!

<P.S.> I wrote the most of this post on my P1i (which happens to have an absolutely horrid keyboard) using the WPhone plugin for mobile WordPress access. The only drawback is that I haven’t yet figured out how to add links using this plugin, therefore I had to finish this post in a real browser. </P.S.>

I guess every blogger needs to go down this road sometime…

For some reason my post about geotagging has become some comment spammers new favorite darling. When my server came back online (after this little outage) the comments started flowing in at a rate of approximately one comment every four minutes (360 every 24 hours). What I did then was to enable the akismet plugin which is shipped by default with the wordpress installation. And sure, it did mark all the offending comments as spam. But then another problem arose – the usability. How can you guarantee that none of the comments marked as spam are actually mismarked comments, so called false positives? The only way to do that is to manually check the whole spam queue before deleting all comments in said queue. This struck me as slightly sub optimal. What I wanted was a 100% reliable solution.

So I started looking for captcha plugins for wordpress. I came up with one called simpleCaptcha but as it turns out it requires an image processing library (e.g. GD) to be installed on your webserver. While I am the administrator of my own webserver I didn’t really feel like fiddeling around with that kind of stuff, so I kept on looking. The next suggestion on the interwebs is reCaptcha which is actually a quite nifty idea!

ReCaptcha is basically using images of words which can’t be recognized by OCR software from scanned books. The good thing about this is that my server doesn’t have to generate the images itself, they’re already obtainable from another server. And the whole idea of using words which can’t be recognized by machines is most likely drastically reducing the amount of autonomous captcha busting bots able to post comments to my now reCaptcha protected comment forms!

Now the only one remaining issue with this plugin is that it still saves the comments in my wordpress database – although marked as spam. Sure, they’re not published but I’ve still got a spam queue to clean up once in a while. It’s not that much of an issue really since after having disabled akismet there’s only one way a comment could end up in the spam queue and that is by failing the reCaptcha test. Ergo – I can empty the queue without checking it manually beforehand.

The ultimate solution (in my opinion) would be a reCaptcha plugin which doesn’t save the comment as spam when the check fails but rather deletes the comment all together. Atleast this could be a configurable option. If I could set an option like that it would mean that I could re-enable the akismet plugin again and then the only way a comment could end up in the spam queue is by failing the akismet test. Let’s see if anyone picks up on this. =)