carbon14 Blog

While unit testing my own functoids, I came across an odd scenario where my map was working with inline C#, but if I switched to testing the external assembly version, the results were completely different. Obviously I started with the assumption that my functoid was broken, but in fact it appears that it's Microsoft's LogicalAnd functoid which is broken, and has been since BizTalk 2006.

I must stress, that the failure only occurs when you are using the external assembly version of the functoid, which would occur only when you have set the script type preference on your map to give higher priority to the external assembly script type than the inline C# script type. And frankly I still don't know why you would ever want to do that. But if you do, the LogicalAnd functoid is broken.

In BizTalk 2004, the functoid used this code which works:

// Microsoft.BizTalk.BaseFunctoids.FunctoidScripts
public bool LogicalAnd(string val1, string val2)
{
	bool flag = false;
	try
	{
		flag = bool.Parse(val1);
	}
	catch (Exception)
	{
		if (BaseFunctoid.IsNumeric(val1))
		{
			int num = Convert.ToInt32(val1, CultureInfo.get_InvariantCulture());
			flag = (0 < num);
		}
		else
		{
			flag = false;
		}
	}
	if (flag)
	{
		try
		{
			bool flag2 = bool.Parse(val2);
			flag = (flag && flag2);
		}
		catch (Exception)
		{
			if (BaseFunctoid.IsNumeric(val2))
			{
				int num2 = Convert.ToInt32(val2, CultureInfo.get_InvariantCulture());
				bool flag3 = true;
				if (0 >= num2)
				{
					flag3 = false;
				}
				flag = (flag && flag3);
			}
			else
			{
				flag = false;
			}
		}
	}
	return flag;
}

but at some point, either in BizTalk 2006 or in 2006r2 they changed to this code:

// Microsoft.BizTalk.BaseFunctoids.FunctoidScripts
public bool LogicalAnd(string val1, string val2)
{
	bool flag = false;
	if (!bool.TryParse(val1, out flag))
	{
		if (BaseFunctoid.IsNumeric(val1))
		{
			int num = Convert.ToInt32(val1, CultureInfo.InvariantCulture);
			flag = (0 < num);
		}
		else
		{
			flag = false;
		}
	}
	if (flag)
	{
		bool flag2 = false;
		if (!bool.TryParse(val2, out flag2))
		{
			flag = (flag && flag2);
		}
		else if (BaseFunctoid.IsNumeric(val2))
		{
			int num2 = Convert.ToInt32(val2, CultureInfo.InvariantCulture);
			flag2 = true;
			if (0 >= num2)
			{
				flag2 = false;
			}
			flag = (flag && flag2);
		}
		else
		{
			flag = false;
		}
	}
	return flag;
}

The new code is cleaner, and uses the TryParse method of the Boolean, presumably to avoid the overhead of the try..catch block. But the sense of the second parse test is the wrong way round; that second exclamation mark shouldn't be there; and as a result this function will almost always return false.

The fact that this bug appears to have survived for a decade suggests that no-one ever chooses to prioritise external assemblies in their maps, but you never know.

A Boolean and function should be the easiest thing to get right, and it certainly shouldn't be difficult to have unit testing this function.

Recently I ran into an unexpected problem with a custom pipeline component which I thought had been working fine. Suddenly it stopped working, but with an unexpected workaround. Today I worked out what the problem is, and although it makes perfect sense it caught me by surprise. I can't find any mention of this gotcha elsewhere on the internet, so I thought I'd write about it here.

Last year I wrote a custom pipeline component (Message Dump component) which optionally dumps the message body and/or the context of the message, and I use it regularly in my pipelines. Because the dumping is optional, and can be quickly controlled at runtime, I place the component in pretty much all of the pipelines that I use. When turned off, the overhead is minimal, but when you want to check what's going through any given stage of a pipeline you can quickly turn it on and get what you need.

This year we decided that one of our pipelines should always dump a copy of the message body and so I created another cut down version of this component (Archive component) that didn't have the optional switch. It has just 1 configuration option which is the path to the file that should be written, and that file path can contain various macros which can be expanded from the message context.

Everything seemed to work in the development and test environments; we went live with it and it was great. After a period of live commissioning I turned off the Message Dump components in the pipeline, and that's when it all went wrong.

Read more!

Starting some serious development in Microsoft BizTalk 2013 and I was looking for a way to streamline some of our maps. One common place where we have clutter is in the if..then..else design pattern. Typically you want to map one element if something is true, and if it's not true, you want to map something else instead.

BizTalk doesn't provide functoids that do that neatly, and over the years several people have commented on this; it's a problem that goes right back to at least BizTalk 2006.

In this post I'm going to show you the custom functoids that I created to try to streamline my maps.

Read more!

I've just had to help a friend with here broadband email service. It was working on Monday, but at some point during the week it stopped.

It was complaining that it couldn't get a response from the POP3 server. So I double checked all the documentation and rechecked the password. No good.

I had a look through her existing emails and discovered that she'd been sent details of a new email service that she was being moved onto. So I checked through the settings for that.
There were quite a few settings changes and I thought that would sort it, but no.

So then I went to the ISPs extremely slow, and badly organised AJAX enabled website, where eventually I managed to get the help pages to open for me. There I double checked all the settings, still OK and then looked for more help.

"Perhaps your password has become desynchronised in the move to the new service. Go to this page and change your password." It suggested.

I eventually had to find a different computer to get through the website without the AJAX choking and then I changed the password.

It still wasn't working.

I logged into the provider's site again, to be sure the password was right.
I logged into the provider's webmail service, which I discover is now a GMail solution.

There I find, in my friend's inbox, sent after the changeover, a new, and subtly different set of instructions on what to do to get POP3 working. Now you have to log into the webmail service and ENABLE POP3 apparently.

IF you move someone to a new email service.
AND some changes are necessary for them to continue to use it as before
sending them instructions AFTER the changeover is NOT GOOD ENOUGH!!!

Last week I saw something, a visual effect and I thought "ooh, I must remember that, I could use it in a website design".

But I don't have a particular project to use it in right now.

By the time I do, I'll have forgotten the idea.

So here's my suggestion. Make yourself a sourcebook, a scrapbook if you like. Set aside a directory on your PC, or a junk space on your website. And then when you come across a cool visual idea, or something like that, clip it, or create an example and put it in your scrap book.

In years to come, when you are looking for inspiration for your current project, you can look through your sourcebook for ideas that you would otherwise have forgotten. Probably a lot of it will look dated, but you know, 'what comes around goes around' It'll come back into fashion eventually, and you'll be ready for it when it does.