Chronicles of a messaging slave: Part 1:: MS & Jugaad

Greetings Earthlings! Quite some time since I wrote the last review of the mailing servers. Treading on the path of discovery to the messaging world, a lot has happened to change my outlook. A lot of fiascos, a lot of “your silly code caused a crash at ***” and sometimes a rare success- making the journey quite an experience.

Though some things never change & I still consider Microsoft as the 'evil empire with a bunch of smart marketing professionals’.

As I look at it, Microsoft does make your life a lot easier by providing a lot of beautiful and apparently easy to use API's. It also guarantees a simple graphic interface for end users. But gradually I learnt that all that shiny stuff is also quite delicate and needs to be handled with care. Moreover, MS has gone far to provide a zillion features which it might not necessarily support everywhere. One classic example of a case that I came across:

Now, besides the bugs that we own, one of the biggest drawbacks of our product is that it is built on MFC. Where M stands for Microsoft. So we always live in the fear that the building blocks of our product: the Microsoft Foundation Classes may let us down even though we continue striving to make ourselves bug free (hell; who actually attains that hypothetical feat??).

The 'Read recipient' mail is commonly used in most enterprises. One of our modules screwed up this particular mail when we processed it with an aim make the world a better place (oops, sounds like my product tagline). After pulling the code inside out, banging my head at a couple of forums and eventually on my desk; I discovered that the CopyTo() call was failing. So the scenario can be described as: we are copying a MS mail using a MS function on a MS server. And it fails..

I must say I used to be a fan of the CopyTo() call. The extent to which it can be used is commendable. Use it anywhere for any object. But I guess it is natural that small problems arise when you try to make something too powerful attempting to make it handle innumerous objects of varying kind.

So bang, I know there's a problem with MS's CopyTo() call but what next? I could write my own function for the same operation but I know this will take quite some time. Also, there's no guarantee that I'll include all of CopyTo()'s features. Me being royally lazy does not help much either.

Option 2: I open a case with Microsoft so that they can start charging my business unit and augment their gazillion dollar pool. Nah..

So here comes Option 3. The powerful phenomenon that has helped India to attain spectacular heights. Corporations know the pros and cons of this when they move their businesses or processes to India. It's called 'Jugaad'. Since you may not find the definition in your Websters', allow me:

Jugaad may be defined as the star Indian management process revolving around 'managing' to do something without any resources broadly based on hit n trial. The name changes with regions and languages across India, but there is no denying this countrywide phenomenon. It may be 'adjust maadi', ‘jugaad lagao', 'try this, it just might work' in different dialects.

So not wanting to deprive my organization of this Indian technique (who knows, maybe they set up the development center in India with the sole purpose to capitilize this??), I got to work in these lines. Innumerous experiments and whacko concepts later, I decided to start excluding a couple of properties from the mail file before it comes to CopyTo(). One such property was PR_RTF_COMPRESSED. And hey presto: Problem solved!!!

PR_RTF_COMPRESSED: what it does? Effects of removing this flag?? As always, msdn does nothing more than describing little more than what a mammal with pea sized brain can guess from the name already. So some research later, we verify that we do not use this flag in any module and can live without it.

Some issues we have come across are thanks to time stamps in the microsoft messaging environment. Either the client or at times, the Exchange server itself messes with the time stamps making future tracking of messages almost impossible. The time stamps have always been the vital key to tracking of messages and any fault with this is bound to create havoc in your messaging infrastructure.

One instance was a changing PR_CLIENT_SUBMIT_TIME field particularly in the Exchange 2007 environment. We were absolutely certain that there were no 3rd party applications running, yet Exchange magically changes this field in the client mailbox. Now if you review this message again, finding a different time stamp your algorithm will definitely treat this as a distinct entity resulting in duplication. JK Rowling, in case you are reading this do ask Harry Potter to take a look at MS Exchange2003/2007 when he grows up.