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