My blog has moved!

Visit http://blog.adamroderick.com/ and update your bookmarks.

Thursday, November 20, 2008

Using the pass-through pipeline - String versus XmlDocument

As part of a larger solution, I had what I thought would be a quick orchestration to build: take text files from a folder and combine them into a single text file. There are a lot of examples of the aggregation pattern using BizTalk out there, and I used the sequential convoy pattern.

I set up a receive port and location to receive the individual text files. I set up a filter expression on my initial receive shape to receive only messages that came in through that receive port. In my orchestration, I created a message of type string to receive the individual text files.

When I deployed, the receive port picked up the text files and immediately suspended, because no subscribers were found. I examined the subscription of the orchestration, and wouldn't you know, it required the MessageType to be set to string. The problem is that with the pass-through pipeline, no MessageType is set. I had a few options.

  1. Create a flat file schema, a receive pipeline with a flat file disassembler, and a send pipeline with a flat file assembler. Seemed like overkill when I really didn't care about the contents of the files.
  2. Create a custom pipeline component that simply created and promoted a MessageType property of string. That would also have required receive and send pipelines that contained the customer pipeline component.
  3. In the orchestration, change the message type from string to XmlDocument. The interesting thing about this is BizTalk does its subscriptions differently for these two cases.
I chose #3, because if the message type is XmlDocument, BizTalk does not set a subscription on the MessageType. Then my filter and convoy will work.

In the orchestration, because my message was an XmlDocument and not a string, I could no longer append the string values of my messages. I created a method in a helper class that would convert my message back into its true string form:

public string GetString(XLANGMessage msg)
{
StreamReader reader = new StreamReader((Stream)msg[0].RetrieveAs(typeof(Stream)));
string retval = reader.ReadToEnd();

return retval;
}

Some of the other options are discussed in more detail at http://support.microsoft.com/kb/837860

Labels:

Thursday, November 13, 2008

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Oooh, I hate seeing this one. There are many situations where this can occur, and I am confident that I am not aware of all of them. But I most often see it on an ASP.NET website, set up to use Windows authentication, with a SQL Server backend.

The simple explanation is that your credentials are lost, and by the time you go through all the layers and reach the SQL Server database, you appear to be an anonymous user. For more detailed explanations, see this article or search the internet for "double hop."

In my case, the problem actually lied with Internet Explorer and not with ASP.NET, IIS, my code, or SQL Server. The site I was trying to access was listed in my "Trusted Sites Zone" (see Tools > Internet Options > Security Tab). Sites under the Trusted Sites Zone do not pass windows credentials correctly. You should have any sites that use windows authentication either in the Intranet Zone or on the same domain of your client machine.

Adding my site to the Intranet Zone allowed the browser to correctly pass my windows credentials all the way through to SQL Server, and I had no more errors about anonymous logons.

Labels: , ,