Connecting Systems

WCF Behavior To Remove Whitespace

2009-12-17T01:45:00.001-08:00

After finding a bug in the way BizTalk executes body xpath expressions in WCF ports (details here) I came up with a custom behavior to remove the leading and trailing whitespace in an inbound xml message.

First the WCF behavior needs to be implemented, it looks like:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Configuration;
using System.ServiceModel.Dispatcher;
using System.Text;
using System.ServiceModel.Description;
using System.Xml;
using System.Xml.Linq;
using System.Xml.XPath;
using My.Helpers.Xml;

namespace My.Helpers.WcfBehaviors
{
    public class NormalizeMessageBehaviorExtension : BehaviorExtensionElement
    {
        public override Type BehaviorType
        {
            get { return typeof(NormalizeMessageEndpointBehavior); }
        }

        protected override object CreateBehavior()
        {
            return new NormalizeMessageEndpointBehavior();
        }
    }

    public class NormalizeMessageEndpointBehavior : IEndpointBehavior
    {
        #region IEndpointBehavior Members

        public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
        { }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
        { }

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
        {
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new NormalizeMessageInspector());
        }

        public void Validate(ServiceEndpoint endpoint)
        { }

        #endregion
    }

    public class NormalizeMessageInspector : IDispatchMessageInspector
    {

        #region IDispatchMessageInspector Members

        public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
        {
            request = NormalizeMessage(request);
            return null;
        }

        public Message NormalizeMessage(Message inboundMessage)
        {
            Message normalizedMessage = null;
            MessageBuffer buffer = inboundMessage.CreateBufferedCopy(Int32.MaxValue);
            Message tempMessage = buffer.CreateMessage();

            using (var inputStream = new MemoryStream())
            {
                using (var writer = XmlDictionaryWriter.CreateTextWriter(inputStream, Encoding.UTF8))
                {
                    tempMessage.WriteBodyContents(writer);
                    writer.Flush();

                    inputStream.Position = 0;

                    using (MemoryStream outputStream = new MemoryStream())
                    {
                        XmlParser.Normalize(inputStream, outputStream);

                        using (var reader = XmlReader.Create(outputStream))
                        {
                            normalizedMessage = Message.CreateMessage(inboundMessage.Version, null, reader);
                            normalizedMessage.Headers.CopyHeadersFrom(inboundMessage);
                            normalizedMessage.Properties.CopyProperties(inboundMessage.Properties);
                            buffer = normalizedMessage.CreateBufferedCopy(Int32.MaxValue);
                        }
                    }
                }
            }
            
            return buffer.CreateMessage();
        }


        public void BeforeSendReply(ref Message reply, object correlationState)
        { }

        #endregion
    }
}

Then the code for the normalize looks like this:

using System;
using System.Diagnostics;
using System.IO;
using System.Linq;
using System.Reflection;
using System.Text;
using System.Xml.Linq;
using System.Xml;
using My.Helpers.Utility;

namespace My.Helpers.Xml
{
    [Serializable]
    public class XmlParser
    {

        public static void Normalize(Stream inputStream, Stream outputStream)
        {
            try
            {
                XmlReaderSettings readerSettings = new XmlReaderSettings() { ValidationType = ValidationType.None };

                StreamReader tempReader = new StreamReader(inputStream);
                Encoding encoding = tempReader.CurrentEncoding ?? Encoding.UTF8;

                XmlReader reader = XmlReader.Create(inputStream, readerSettings);

                XmlWriterSettings writerSettings = new XmlWriterSettings() { ConformanceLevel = ConformanceLevel.Auto, Encoding = encoding };
                XmlWriter writer = XmlWriter.Create(outputStream, writerSettings);

                while (reader.Read())
                {
                    switch (reader.NodeType)
                    {
                        case XmlNodeType.Element:
                            writer.WriteStartElement(reader.Prefix, reader.LocalName, reader.NamespaceURI);
                            if (reader.IsEmptyElement)
                                writer.WriteEndElement();
                            else
                            {
                                while (reader.MoveToNextAttribute())
                                {
                                    if (reader.Value.Length > 0)
                                    {
                                        writer.WriteStartAttribute(reader.Prefix, reader.LocalName, reader.NamespaceURI);
                                        writer.WriteString(NormalizeString(reader.Value));
                                        writer.WriteEndAttribute();
                                    }
                                    else
                                    {
                                        writer.WriteStartAttribute(reader.Prefix, reader.LocalName, reader.NamespaceURI);
                                        writer.WriteString(reader.Value);
                                        writer.WriteEndAttribute();
                                    }
                                }
                            }
                            break;
                        case XmlNodeType.Text:
                            string text = reader.Value;
                            if (text.Length > 0)
                            {
                                writer.WriteString(NormalizeString(reader.Value));
                            }
                            else
                                writer.WriteString(text);
                            break;

                        case XmlNodeType.CDATA:
                            writer.WriteCData(reader.Value);
                            break;
                        case XmlNodeType.EntityReference:
                            writer.WriteEntityRef(reader.Name);
                            break;
                        case XmlNodeType.XmlDeclaration:
                        case XmlNodeType.ProcessingInstruction:
                            writer.WriteProcessingInstruction(reader.Name, reader.Value);
                            break;
                        case XmlNodeType.Comment:
                            writer.WriteComment(reader.Value);
                            break;
                        case XmlNodeType.DocumentType:
                            writer.WriteDocType(
                                reader.Name,
                                reader.GetAttribute(Constants.XmlAttribute.Public),
                                reader.GetAttribute(Constants.XmlAttribute.System),
                                reader.Value);
                            break;
                        case XmlNodeType.Whitespace:
                        case XmlNodeType.SignificantWhitespace:
                            writer.WriteWhitespace(reader.Value);
                            break;
                        case XmlNodeType.EndElement:
                            writer.WriteFullEndElement();
                            break;
                    }
                }

                writer.Flush();
                outputStream.Position = 0;

            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

        #region Normalize Helper Methods

        private static string NormalizeString(string input)
        {
            StringBuilder sb = new StringBuilder();
            string[] parts = input.Split(
                new char[] {
                               Constants.Char.Space,
                               Constants.Char.NewLine,
                               Constants.Char.Tab,
                               Constants.Char.CarriageReturn,
                               Constants.Char.FormFeed,
                               Constants.Char.VerticalTab
                           },
                StringSplitOptions.RemoveEmptyEntries);
            for (int i = 0; i < parts.Length; i++)
                sb.AppendFormat(Constants.GeneralFormat.AppendSpace, parts[i]);
            return sb.ToString().Trim();
        }

        #endregion

    }

    internal class Constants
    {
        internal class Char
        {
            internal const char CarriageReturn = '\r';
            internal const char Comma = ',';
            internal const char FormFeed = '\f';
            internal const char NewLine = '\n';
            internal const char Pipe = '|';
            internal const char Space = ' ';
            internal const char Tab = '\t';
            internal const char VerticalTab = '\v';
        }

        internal class ContextProperty
        {
            internal const string SchemaStrongName = "SchemaStrongName";
        }

        internal class ErrorMessageFormat
        {
            internal const string LeadingWhiteSpaceInString = "Leading whitespace in string field {0}.";
            internal const string TrailingWhiteSpaceInString = "Trailing whitespace in string field {0}.";
            internal const string ConsecutiveSpacesInString = "Consecutive spaces in string field {0}.";
            internal const string CRLFOrTabInString = "Carriage return, line feed or tab in string field {0}.";
        }

        internal class GeneralFormat
        {
            internal const string AppendSpace = "{0} ";
        }

        internal class GuidString
        {
            internal const string StringNormalizerClassId = "233553fa-b648-40ad-af26-d749d06ce443";
        }

        internal class PropertyName
        {
            internal const string ErrorOnNonNormalString = "ErrorOnNonNormalString";
            internal const string NormalizeStrings = "NormalizeStrings";
        }

        internal class ResourceNames
        {
            internal const string StringNormalizer = "My.BizTalk.PipelineComponents.StringNormalizer";
        }

        internal class ResourceStrings
        {
            internal const string ComponentDescription = "COMPONENTDESCRIPTION";
            internal const string ComponentIcon = "COMPONENTICON";
            internal const string ComponentName = "COMPONENTNAME";
            internal const string ComponentVersion = "COMPONENTVERSION";
        }

        internal class XmlAttribute
        {
            internal const string Public = "PUBLIC";
            internal const string System = "SYSTEM";
        }

        internal class XmlNamespace
        {
            internal const string BizTalkSystemProperties = "http://schemas.microsoft.com/BizTalk/2003/system-properties";
        }
    }
}

To use the behavior in BizTalk just add the assembly to the GAC, and register it in the machine.config file with the rest of the behaviors that ship with .net. Then add the behavior in your WCF port configuration, and the issues with whitespace are solved!

DebugView Hangs BizTalk 2009 Deployment

2009-09-16T15:52:00.001-07:00

Had a very strange issue with Windows Server 2008/BTS 2009 and DebugView recently, thought I might mention it in the hope it would save someone else some time diagnosing the issue.

During an ESB project I was working on recently, I started to get issues with my virtual machine locking up while deploying a BizTalk solution locally. The only solution was to reboot the virtual, and then deploy again. However the issue would keep occurring again and again, meaning I would be rebooting my machine every hour or so. Very frustrating!

I decided that there must be some issue with my virtual so I built another image, but the problem came back again. I started digging around to see what could be cause of the issue, checking resource monitor (cpu/disk/memory), monitoring the local SQL instance, and using Process Monitor. Still no luck.

Eventually I noticed that the issue only seemed to occur when I had DebugView open (I use it monitor ESB trace statements and other trace calls from orchestrations). After shutting it down the virtual started running properly again after a few seconds…. hmmmm.

I successfully reproduced the issue several times – something that DebugView is doing interferes with the deployment process into BizTalk, and then the flow-on effect freezes the entire machine. It only seems to affect the deployment part so just shut down DebugView before you deploy. Hope this helps!

Dynamically Sending Email Attachments Using The BizTalk SMTP Adapter

2009-08-31T21:57:00.001-07:00

Recently we had a requirement to send email from BizTalk with a number of attachments. This sounds like an easy thing to do, until we realised the number of attachments required would vary at runtime. It could be anywhere from zero, to lots.

In trying to work out the best method to achieve this, I first tried manually creating a multipart MIME message that contained explicit boundaries, and the appropriate content types. It didn’t seem to work reliably so after a bit of searching I found this article which used the idea of directly adding XLANGPart to the main XLANG email message.

One quick helper class later and it was all working:

        public void AttachPartToMessage(XLANGMessage message, string partContent, string partFileName)
        {
            byte[] contentBuffer = UTF8Encoding.Default.GetBytes(partContent);
            MemoryStream partStream = new MemoryStream(contentBuffer, 0, contentBuffer.Length, true, true);

            string partName = Guid.NewGuid().ToString().Substring(0, 5);
            message.AddPart(partStream, partName);
            
            //derive the content type from the filename extension
            string contentType = GetContentType(Path.GetExtension(partFileName).Replace(".", ""));

            //set filename and content type for attachment
            XLANGPart part = message[partName];
            part.SetPartProperty(typeof(MIME.FileName), partFileName);
            part.SetPartProperty(typeof(ContentType), contentType);
        }

This can be used from the orchestration as follows (note the main XLANG message to which you are adding the parts, must be multipart)

MessageHelper.AttachPartToMessage(EmailMsg, "<test>this is attachment one</test>","Sample.xml");
MessageHelper.AttachPartToMessage(EmailMsg, "<html><body><i>Hello World<i></body></html>", "Test.html");
MessageHelper.AttachPartToMessage(EmailMsg, InboundMsg.OuterXml, "InboundMsg.xml");

The resulting message shows up properly in Outlook :-)

Cheers!

Esb Toolkit 2.0 With Custom Adapter Provider

2009-08-04T15:57:00.001-07:00

One of my favourite features of the new esb toolkit is that it is incredibly easy to extend. Already in an internal implementation I have written a custom messaging service, and implemented a custom adapter provider. Extending a messaging service is comprehensively covered here, but the documentation on the adapter provider is pretty inadequate.

Here are a couple of points that may make it easier for anyone else going down this path…

The adapter provider entry that you create in the esb config file must contain the adapterassembly attribute (unless it references an adapter that ships with BizTalk) or it will not work. The type attribute points to the actual adapter implementation, and the adapterassembly attribute points to the property schema assembly – the documentation is incorrect on this point. An example is below.

<adapterProvider name="SFTP" type="MyTestProvider.SftpProvider, MyTestProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=354cb85f9213cd3b" moniker="SFTP" adapterAssembly="MyTestProvider.Schemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=354cb85f9213cd3b" />

Consider the above example of creating an custom adapter provider for secure FTP (SFTP):

-the adapter name in BizTalk must be SFTP

- the adapter property schema namespace must be SFTP

- the adapter provider name and moniker in the esb config file must be SFTP

<adapterProvider name="SFTP" type="MyTestProvider.SftpProvider, MyTestProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=354cb85f9213cd3b" moniker="SFTP" adapterAssembly="MyTestProvider.Schemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=354cb85f9213cd3b" />

If all these things correctly align, the ESB adapter manager should correctly promote the SFTP-related context properties from your itineraries :-)

MSBuild Extension Pack 3.5.3 Released!

2009-06-15T04:20:00.001-07:00

Get it now at http://msbuildextensionpack.codeplex.com/ :-)

Guidance In Configuring Default BizTalk SQL Agent Jobs

2009-04-22T23:55:00.001-07:00

Having done some work recently setting up a number of BizTalk Hyper-V machines, I have put some guidance together on configuring the SQL Server Agent jobs that are created as part of the BizTalk install process. It’s pretty simple, but important to get these right as they can create performance issues, and run your server out of disk space!

1. Backup BizTalk Server (BizTalkMgmtDb)
There are three steps to this job: BackupFull, MarkAndBackupLog and ClearBackupHistory.

The BackupFull step contains this sql statement to configure:

exec [dbo].[sp_BackupAllFull_Schedule] ‘d’ /* Frequency */,‘BTS’ /* Name */,‘<destination path>’ /* location of backup files */

Generally most installations will keep the frequency daily and the name the same but you need to provide a full destination patch for the backup files to be stored in. Also, there are two important extra parameters that should be applied to this procedure. The first is a flag that controls if the job forces a full backup if a partial backup fails. The second extra parameter controls the time of day to run the full backup. Adding this will stop the backups occurring at midnight UTC time, which is the default. After configuration, to run at 2300 hours this step should look like:

exec [dbo].[sp_BackupAllFull_Schedule] 'd'/* Frequency */,'BTS'/* Name */,'C:\BizTalkSqlBackups\'/* location of backup files */, 0, 23

The MarkAndBackUpLog step has the following statement to configure:

exec [dbo].[sp_MarkAll] ‘BTS’ /* Log mark name */,’<destination path>’ /*location of backup files */

Simply add in your destination path for the log backups, and a extra bit parameter that tells the procedure to use local time:

exec [dbo].[sp_MarkAll] 'BTS'/* Log mark name */,'C:\BizTalkSqlBackups\'/* location of backup files */,1

The final step, Clear Backup History is configured like this by default:

exec [dbo].[sp_DeleteBackupHistory] @DaysToKeep=14

This procedure clears out the instances in the MarkLog table older than the days specified. Generally it can be left as is, but a enhancement to this procedure has been designed by Bill, to solve the issue of accumulating backups in the file system. You can download the updated stored procedure from his blog (called ‘BizTalk 2004 Stored Procedure to delete backups’), and it will take care of deleting the backup files as well.

After configuring all the steps, make sure the job is enabled in SQL Agent, and do a test run to verify everything is working correctly.

2. DTA Purge and Archive (BizTalkDTADb)
This job only contains one step requiring configuration: Archive and Purge.

The step contains this sql statement to modify:

exec dtasp_BackupAndPurgeTrackingDatabase
0, --@nLiveHours tinyint, --Any completed instance older than the live hours +live days
1, --@nLiveDays tinyint = 0, --will be deleted along with all associated data
30, --@nHardDeleteDays tinyint = 0, --all data older than this will be deleted.
null, --@nvcFolder nvarchar(1024) = null, --folder for backup files
null, --@nvcValidatingServer sysname = null,
0 --@fForceBackup int = 0 --

The window for keeping instances in the Tracking Database is really dependent on your needs. The most important parameter to set is the folder path for backup files, but note there is also an interesting parameter called @nHardDeleteDays. According to the the Professional BizTalk Server 2006 book:

“This deals with incomplete instances that are in the Tracking database. This is useful in many situations, including when you have looping orchestrations that run indefinitely over a long period of time. Left unaddressed, this could result in the DTA database growing and these instances never being purged. Hard purging allows all data older than the specified value of the parameter @nHardDeleteDays to be purged, with the exception of that data that indicates the existence of an instance. The value of this parameter should always be greater than your soft purge window.” Once this procedure is configured it should look like this:

exec dtasp_BackupAndPurgeTrackingDatabase
0, --@nLiveHours tinyint, --Any completed instance older than the live hours +live days
15, --@nLiveDays tinyint = 0, --will be deleted along with all associated data
16, --@nHardDeleteDays tinyint = 0, --all data older than this will be deleted.
'C:\BizTalkSqlBackups\', --@nvcFolder nvarchar(1024) = null, --folder for backup files
null, --@nvcValidatingServer sysname = null,
0 --@fForceBackup int = 0 --

Again, make sure this job is enabled and run it to ensure everything is working correctly. Configuring these jobs will go a long to ensure your BizTalk installation runs smoothly. Cheers!

Using TFS Assemblies on Vista 64-bit

2009-04-21T15:20:00.001-07:00

Just spent some time figuring out an issue in a Windows Forms application I am writing. It is designed to be a simple UI for generating TFS builds for BizTalk, using the MSBuild Extension Pack tasks.

In order to generate builds through the TFS API, I needed to reference some of the following assemblies:

- Microsoft.TeamFoundation
- Microsoft.TeamFoundation.Build.Client
- Microsoft.TeamFoundation.Client

After referencing these assemblies I ran the application and kept getting a runtime exception:

Could not load file or assembly 'Microsoft.TeamFoundation, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

After trying a number of steps to fix the issue it turns out that under Vista 64-bit, the application referencing these assemblies must be compiled in in ‘x86’ mode, not ‘Any CPU’. Changing the solution configuration mode to ‘Debug | x86’ solves the issue.

The error message isnt particularly helpful in this case so I am blogging it in case someone else strikes the same issue. Apparently TFS 2010 will be fully 64-bit compatible (at last!).

MSBuild Extension Pack And BizTalk

2009-04-16T14:57:00.001-07:00

I have started to contribute on the CodePlex project http://www.codeplex.com/MSBuildExtensionPack, helping out on the BizTalk tasks included in the library. The next release (3.5.3) is shaping up really well and should have great support for most of the tasks needed for deploying and administering BizTalk (including deploying to remote machines).

The 3.5.3 release should be out some time in early May, look out for it – using MSBuild and BizTalk together is about to become a lot easier :-)

BizTalk WCF Misbehaviors [Part 2]

2009-03-01T21:41:00.001-08:00

In part 1 of this posting, I showed how the default behavior of BizTalk WCF adapters were causing a problem with a specific messaging scenario, with strict addressing and security header requirements.

The good news is that BizTalk provides the ability to configure WCF Behavior Extensions directly on your send port configuration.

From the MSDN article on the subject, emphasis mine:

“One of the advantages of using Windows Communication Foundation (WCF) as a message communication mechanism is the opportunity to extend the functionality of its services by using custom code. There are different points within the flow of a WCF message to intercept the message and execute custom processing before the message reaches its final destination. WCF custom behavior extensions are one such type of interception mechanism, and can be used to extend WCF service or client functionality at different levels of granularity. In this paper we will discuss the different types of WCF behaviors and where you can interject their processing within the WCF architecture. We will discuss how the BizTalk WCF-Custom and WCF-CustomIsolated adapters enable you to use a WCF custom behavior extension.”

Sounds perfect for our requirements, namely the ability to completely control the WS-Addressing and WS-Security headers in our BizTalk send port. In order to create our custom behavior extension, we need to do five things:

1. Write a class inheriting from BehaviorExtensionElement, which holds our configuration properties and instantiates the actual endpoint behavior in the CreateBehavior method:

public sealed class MyBehaviorExtension : BehaviorExtensionElement
{
    
    [ConfigurationProperty("ServiceUsername", DefaultValue="", IsRequired = true)]
    public string ServiceUsername
    {
        get { return (string)base["ServiceUsername"]; }
        set { base["ServiceUsername"] = value; }
    }

    [ConfigurationProperty("ServicePassword", DefaultValue = "", IsRequired = true)]
    public string ServicePassword
    {
        get { return (string)base["ServicePassword"]; }
        set { base["ServicePassword"] = value; }
    }

    [ConfigurationProperty("ServiceAction", DefaultValue = "urn:#AuthenticateUser", IsRequired = true)]
    public string ServiceAction
    {
        get { return (string)base["ServiceAction"]; }
        set { base["ServiceAction"] = value; }
    }

    [ConfigurationProperty("ServiceToAddress", DefaultValue = "", IsRequired = true)]
    public string ServiceToAddress
    {
        get { return (string)base["ServiceToAddress"]; }
        set { base["ServiceToAddress"] = value; }
    }

    [ConfigurationProperty("ServiceFromAddress", DefaultValue = "", IsRequired = true)]
    public string ServiceFromAddress
    {
        get { return (string)base["ServiceFromAddress"]; }
        set { base["ServiceFromAddress"] = value; }
    }
    
    protected override object CreateBehavior()
    {
        MyBehaviorConfiguration behaviorConfiguration = 
            new MyBehaviorConfiguration(
                this.ServiceUsername, 
                this.ServicePassword, 
                this.ServiceAction, 
                this.ServiceToAddress, 
                this.ServiceFromAddress);

        return new MyEndpointBehavior(behaviorConfiguration);
    }
    
    public override Type BehaviorType
    {
        get
        {
            return typeof(MyEndpointBehavior);
        }
    }

    private ConfigurationPropertyCollection _prop = null;

    protected override ConfigurationPropertyCollection Properties
    {
        get
        {
            if (this._prop == null)
            {
                this._prop = new System.Configuration.ConfigurationPropertyCollection();
                this._prop.Add(new System.Configuration.ConfigurationProperty("ServiceUsername", typeof(string), "", System.Configuration.ConfigurationPropertyOptions.IsRequired));
                this._prop.Add(new System.Configuration.ConfigurationProperty("ServicePassword", typeof(string), "", System.Configuration.ConfigurationPropertyOptions.IsRequired));
                this._prop.Add(new System.Configuration.ConfigurationProperty("ServiceAction", typeof(string), "", System.Configuration.ConfigurationPropertyOptions.IsRequired));
                this._prop.Add(new System.Configuration.ConfigurationProperty("ServiceToAddress", typeof(string), "", System.Configuration.ConfigurationPropertyOptions.IsRequired));
                this._prop.Add(new System.Configuration.ConfigurationProperty("ServiceFromAddress", typeof(string), "", System.Configuration.ConfigurationPropertyOptions.IsRequired));
            }
            return this._prop;
        }
    }

    
}

2. Create the endpoint behavior implementing IEndpointBehavior, in order to apply our desired client behavior, via a custom client message inspector:

public class MyEndpointBehavior : IEndpointBehavior
{
    public MyEndpointBehavior(MyBehaviorConfiguration behaviorConfiguration)
    {
        this.BehaviorConfiguration = behaviorConfiguration;
    }

    public MyBehaviorConfiguration BehaviorConfiguration { get; set; }

    #region IEndpointBehavior Members

    public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
    { }

    public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
    {
        clientRuntime.MessageInspectors.Add(new CustomHeadersMessageInspector(this.BehaviorConfiguration));
    }

    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
    { }

    public void Validate(ServiceEndpoint endpoint)
    { }

    #endregion

}

3. Create the custom message inspector, implementing IClientMessageInspector:

public class CustomHeadersMessageInspector : IClientMessageInspector
{
    public CustomHeadersMessageInspector(MyBehaviorConfiguration behaviorConfiguration)
    {
        this.BehaviorConfiguration = behaviorConfiguration;
    }

    public MyBehaviorConfiguration BehaviorConfiguration { get; set; }

    #region IClientMessageInspector Members

    public void AfterReceiveReply(ref Message reply, object correlationState)
    { }

    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        request.Headers.Action = BehaviorConfiguration.ServiceAction;
        request.Headers.From = BehaviorConfiguration.ServiceFromAddress;
        request.Headers.To = BehaviorConfiguration.ServiceToAddress;
        request.Headers.Add(BuildSecurityHeaders());
        return null;
    }

    #endregion

}

4. Add the extension element into the machine.config file on your BizTalk server under the System.ServiceModel | Extensions | BehaviorExtensions element:

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
    <add name="NextGenBehaviorExtension" type="SGC.Helpers.MyWcf.MyBehaviorExtension, SGC.Helpers.MyWcf, Version=1.0.0.0, Culture=neutral,PublicKeyToken=354cb85f9213cd3b" />

5. GAC the behavior extension assembly you created, and restart BizTalk server.

Installation complete!

If you have correctly configured everything, you should see see the extension listed when you ‘Add Extension’ on the Behavior tab of your WCF-Custom port.

Here is what the extension I built looks like in BizTalk, notice the configuration options are listed in the UI. These options also get saved out into the binding file when you export bindings.

After configuring the behavior with the desired settings, my message headers now conform to what the remote service expects.

<s:Header>
  <a:Action>MyAction</a:Action>
  <a:To>MyToAddress</a:To>
  <a:From>
    <a:Address>MyFromAddress</a:Address>
  </a:From>
  <Security>
    <UsernameToken>
      <Username>MyUsername</Username>
      <Password>MyPassword</Password>
    </UsernameToken>
  </Security>
</s:Header>

Nice!

BizTalk WCF Misbehaviors [Part 1]

2009-02-10T17:02:00.001-08:00

For my first post I thought I would share some of my experiences getting a BizTalk WCF send adapter to behave with an unusually configured client endpoint.

The client had a service listening via https, and had strict requirements on what they would expect in the header of the request. Particularly they wanted WS-Addressing and WS-Security headers to look like [details obscured for obvious reasons]:

<s:Header>
  <a:Action>MyAction</a:Action>
  <a:To>MyToAddress</a:To>
  <a:From>
    <a:Address>MyFromAddress</a:Address>
  </a:From>
  <Security>
    <UsernameToken>
      <Username>MyUsername</Username>
      <Password>MyPassword</Password>
    </UsernameToken>
  </Security>
</s:Header>

The client was using the Action, To and From headers to do routing at their end, so they had to be exact. Additionally they also wanted WS-Security headers attached to the outgoing message, although their service didn’t return a compliant WS-Security response.

First up, I tried to go down the path of getting BizTalk to send the correct headers, by setting up a WCF Custom configuration with a wsHttpBinding, in order to generate the correct security headers.

Then, following the details of this MSDN article I directly set the WCF context properties in my orchestration expression shape.

After sending my message through BizTalk, I got an error message from the remote endpoint indicating the message was not correctly addressed. Clearly something wasn’t working as intended, so I needed to start looking at the WCF messages directly. The easiest way to do this is enable WCF tracing directly in BizTalk by adding this section to my BTSNTSvc.exe.config file:

<system.diagnostics>
  <sources>
    <source name ="System.ServiceModel" switchValue="Verbose">
      <listeners>
        <add name="xml" />
      </listeners>
    </source>
    <source name ="System.ServiceModel.MessageLogging"
            switchValue="Verbose, ActivityTracing">
      <listeners>
        <add name="xml" />
      </listeners>
    </source>
    <source name ="System.Runtime.Serialization" switchValue="Verbose">
      <listeners>
        <add name="xml" />
      </listeners>
    </source>
  </sources>
  <sharedListeners>
    <add name="xml" type="System.Diagnostics.XmlWriterTraceListener"
         traceOutputOptions="LogicalOperationStack"
         initializeData="C:\log\BizTalkTrace.svclog" />
  </sharedListeners>
  <trace autoflush="true" />
</system.diagnostics>
<system.serviceModel>
  <diagnostics>
    <messageLogging
         logEntireMessage="true"
         logMalformedMessages="false"
         logMessagesAtServiceLevel="true"
         logMessagesAtTransportLevel="true"/>
  </diagnostics>
</system.serviceModel>

I sent another message through BizTalk, and inspected the outgoing message headers:

<a:Action s:mustUnderstand="1">MyAction</a:Action>
<a:MessageID>urn:uuid:2a013aa6-12a8-4e67-8377-0c75847f2cb1</a:MessageID>
<a:ReplyTo>
  <a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">MySendPortPhysicalAddress</a:To>

Uh-oh! BizTalk is not respecting my WCF context properties from the orchestration.

In fact:

- the Action header has been preserved from the context property
- the To address header has been overwritten by the send port endpoint address
- the From address header is not written at all!

After a few more hours of trial and error is became clear that this approach was not going to work at all. In this context, BizTalk will not respect the context properties in the send adapter for WCF – so it was time for a new direction.

In part two, I will show how to use a great feature of WCF to solve this issue.