Putting HTML code within HTML code

While posting previous entry, I came across the issue of posting HTML code in the blog. Just copying and pasting didn't work quite that well, which was expected.
I ended up putting the code block within < xmp></xmp> tag pair to display the HTML.

Detect if JavaScript is enabled.

I needed a way to detect if Javascript was enabled in the browser, and display a warning if Javascript was disabled. After looking through tons of blog posts, how-to's and documentation on Javascript - I came up with fairly easy solution: to use <noscript> tag.
The code looks as follows:
<script type="text/javascript"></script><noscript>Javascript is disabled.</noscript>Good thing about it - you can put it pretty much anywhere in the page to display the warning.

BizTalk duplicates files in FTP receive adapter.

I ran into the problem of BizTalk duplicating files during FTP transfer, which caused a lot of grief on my side. I thought, our partners were dropping duplicates onto the FTP server, but it turned out BizTalk was duplicating them, during transfer if the file was still being written on the FTP server at the same time as BizTalk tries to pick it up.
It is still rather unclear on behind the scene of how this is happening, but this is something that needs to be addressed. Either by enabling Service Window in the BizTalk FTP receive port, or by storing data in temp file while writing out to FTP, and then renaming it for BizTalk pick up as the last step of the process.

BizTalk 2006 Ghost Exceptions

Quite for some time now, I was getting NULL exceptions, which didn't include any messages or exception data whatsoever. This, in its turn was causing the exception handling to fail and throw an unhandled exception. Since it was rather unclear on what was causing this kind of behavior in the first place, it took me a while to figure out the root cause of it.
It turned out - this was caused by the transaction timeout expiring on the "caller" orchestration, before the "callee" orchestration finished its processing.
What I mean by that:
I would usually have one "wrapper"/"caller" orchestration with the long-running transaction in it (timeout set to X seconds), from which I would call the "processing"/"callee" orchestration. "Callee" orchestration would have a long-running transaction in it as well with the timeout set to Y seconds. When I set X too small and/or less than Y, ”caller" orchestration sometimes would force the "callee" to fail with the null exception being thrown, which propagates into "wrapper" orchestration as well. This makes it next to impossible to figure out the cause of failure. I called these exceptions - "ghost exceptions", as they seemed to appear from nowhere.
Another symptom for this is the Error Description - "The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended." In this case, orchestration is forced to quit, before all of the messages/responses have arrived.