Scope Timeouts

I had an instance recently where a scope in an orchestration would timeout pretty much instantly despite having a timeout period of 10 seconds. This was a real head-scratcher and I couldn't see where the issue was.

After discussing with a colleague we stumbled upon a difference in the clock time between the application server (where the orchestration runs) and the biztalk message box server. The time difference was almost 10 seconds leading to the "inst ant" timeout. A quick look in the event log indicated a problem with the NTP service and the domain controller (another story!) causing the system time to drift out. Correcting the clock fixed my timeout problem.

Host Startup Failure

In my experience, the failure to start a host instance is most often caused by an error in the BizTalk config file btsntsvc.exe.config. This can be because it is not well-formed XML or the content is incorrect.
For example recently I had to investigate an issue with automated unit test failures which turned out to be caused by an incorrect config file update. A WCF client endpoint had been added outside of the element. The error I saw in the event log was:

A failure occurred when executing a Windows service request.

Service request: Start

BizTalk host name: BizTalkServerApplication
Windows service name: BTSSvc$BizTalkServerApplication

Additional error information:
Error code: 0xc0c0153a
Error source: BizTalk Server 2009
Error description: A BizTalk subservice has failed while executing a service request.

Subservice: Tracking
Service request: Start

Additional error information:
Error code: 0x80131534
Error source: System.Data
Error description: The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception.

TechEd Europe 2009

I had a great time at TechEd Europe in Berlin in November. Just wanted to say thanks to Stephen Kaufman, Paolo Salvatori, Markus Landler and everyone else on the BizTalk stand for their time and knowledge.

Orchestrations, Serialization and WaitHandles

A common pattern I use in BizTalk development is to create an orchestration with an associated C# library. The orchestration does what it does best (i.e. orchestrate the business process) and the library is where most of the underlying business logic code lives. This also allows the business logic to be called from other non-orchestration based code if required.

In a recent scenario, the library code lent itself well to a multithreaded approach, consisting of a number of small, independent tasks which could be executed in parallel. I implemented this using a ThreadPool and used ManualResetEvent instances to enable the threads to signal when complete. The WaitHandle.WaitAll allowed the main thread to wait until all the tasks were complete before continuing. This worked fine and all my unit tests ran successfully.

Then I tried calling it from an orchestration and got the dreaded serialization error advising that ManualResetEvent is not serializable. This was occurring when I hit a persistence point in the orchestration causing my instance of the library to be serialized, in this case unsuccessfully.

One possible solution to this is the use of an atomic scope to prevent persistence, allowing non-serializable classes to be used. However, this is not recommended and in my case not really practical anyway given the structure of the orchestration. After considering this and other solutions, I finally settled on creating a custom notifier class that would allow the main thread to wait until all threads signalled they are complete. This would perform the same role as ManualResetEvent/WaitHandle but would be serializable.

A simple example of this follows below. The Notifier class has just two methods: SetOne which allows each individual worker thread to signal it is complete, and Wait which enables the main thread to wait until either all worker threads are finished or a timeout period expires. This uses the static Pulse and Wait methods of the System.Threading.Monitor class to manage the signalling and waiting, providing an efficient, but serializable way to handle this pattern without resorting to a poll/sleep loop. The Notifier instance is passed to each worker thread (in much the same way as a ManualResetEvent would) allowing each thread to signal completion.

[Serializable()]
    public class Notifier
    {
        private bool m_blnAllWorkItemsCompleted = false;
        private Int32 m_i32CompletedWorkItems = 0;
        private Int32 m_i32WorkItemCount = 0;
        private object m_locker = new object();

        public Notifier(Int32 workItemCount)
        {
            m_i32WorkItemCount = workItemCount;
        }

        public void SetOne()
        {
            lock (m_locker)
            {
                // Increment the completed work item count
                m_i32CompletedWorkItems++;

                // Check if all work items are complete
                if (m_i32CompletedWorkItems == m_i32WorkItemCount)
                {
                    // All complete so send pulse notification to stop the wait
                    m_blnAllWorkItemsCompleted = true;
                    Monitor.Pulse(m_locker);
                }
            }
        }

        public bool Wait(Int32 timeout)
        {
            lock (m_locker)
            {
                // Wait until the pulse is received or the timeout period expires
                Monitor.Wait(m_locker, timeout);

                // Return an indication of whether the work was completed
                return m_blnAllWorkItemsCompleted;
            }
        }
    }

class Program
{
    const Int32 THREAD_COUNT = 5;

    static void Main(string[] args)
    {
        // Create a new Notifier
        Notifier notifier = new Notifier(THREAD_COUNT);

        for (int i = 0; i < THREAD_COUNT; i++)
        {
            // Create state to pass through to the new thread
            // Includes the notifier so that the thread can signal back
            ThreadState state = new ThreadState(i, notifier);

            // Spawn a new thread to do a single split item
            ThreadPool.QueueUserWorkItem(MyThreadProc, state);
        }

        // Wait for 5 seconds for all threads to complete
        if (notifier.Wait(5000))
        {
            Console.WriteLine("All threads completed");
        }
        else
        {
            Console.WriteLine("Notifier timed out");
        }

        Console.ReadLine();
    }

    private static void MyThreadProc(object stateInfo)
    {
        // Get the state passed in from the main thread
        ThreadState myState = (ThreadState)stateInfo;
        Notifier notifier = myState.Notifier;
        Int32 i32Id = myState.Id;

        // Wait for a random period to simulate work
        Thread.Sleep(RandomNumber(500, 2000));

        // Notify that the work is complete
        Console.WriteLine(String.Format("[{0}] thread complete.", i32Id));
        notifier.SetOne();
    }

    private static int RandomNumber(int min, int max)
    {
        Random random = new Random();
        return random.Next(min, max);
    }
}

[Serializable()]
class ThreadState
{
    public int Id { get; set; }
    public Notifier Notifier { get; set; }

    public ThreadState(int id, Notifier notifier)
    {
        this.Id = id;
        this.Notifier = notifier;
    }
}

I found this article very helpful during my research for this code. Hope you find this useful too.

BizTalk 2009 IDE Issues

In my last post (too long ago but hey I’ve been busy) I stated that the BizTalk 2009 Visual Studio integration is very good. How wrong could I be! I think I may have spoken too soon.

Over the past few months I have experienced numerous problems around project references and orchestration corruption. It’s got to the point where I have to take very regular backups of any orchestration I am working on just in case. This has been the experience of several colleagues too.

Recently I have been testing a patch issued by the BizTalk product team to resolve some of these issues. This has been pretty good and after 3 weeks I had not had any problems, until last week. The same orchestration corruption reappeared though I have been unable to recreate it since.

I’m currently awaiting feedback from the product team regarding this issue. Hopefully soon we’ll all have the IDE experience that we should have had when BizTalk 2009 was released.

Changing variable type in Orchestration Designer

In general the BizTalk 2009 Visual Studio integration is very good, however it doesn't seem very receptive to change. An annoyance I found recently in the Orchestration Designer occurred when I tried to change the type of an existing orchestration variable. This caused the project to no longer compile. The solution was to delete the variable and recreate it. This only took a few seconds but should not be necessary.

Unit Testing With XLANGMessage

As a rule I generally try to pass messages from BizTalk orchestrations into .NET components using the Microsoft.XLANGs.BaseTypes.XLANGMessage object. This is an abstract base class used by the orchestration engine to represent a message and provides a performant way of marshalling message content without having to resort to using an XMLDocument. For more detail on the benefits of XLANGMessage see Jon Flanders' post on the subject.

Anyhow, whilst using XLANGMessage is a real boon for BizTalk based applications, it does raise problems when trying to write unit tests. How do I write a test for a class that uses XLANGMessage in its interface without resorting to creating an orchestration, deploying a BizTalk app, dealing with File adapters etc?

Well the solution I have adopted is to create mock XLANGMessage and XLANGPart classes that use generics to allow a specified object type to be returned when calling the RetrieveAs method. I typically use this in conjunction with a class generated from the underlying message schema using the XSD tool. I can then write simple unit test code such as:

void Test()
{
    // Create and populate a new message class instance.
    // Typically this would be done by deserializing an XML string.
    MyMessageClass msg = new MyMessageClass();

    // Create a new mock XLANGMessage to wrap the message
    MockXLANGMessage<MyMessageClass> xlang 
                = new MockXLANGMessage<MyMessageClass>(msg);

    // Call the method on the class to be tested 
    // passing in the mock XLANGMessage
    MyClassToBeTested.DoSomething(xlang);
}

where the class to be tested looks like:

class MyClassToBeTested
{ 
    static void DoSomething(XLANGMessage msg)
    {
        MyMessageClass reader =
            (MyMessageClass)msg[0].RetrieveAs(typeof(MyMessageClass));
    } 
}

As you can see this is pretty simple code but works very effectively. But the real meat of this is the mock classes. So what do they look like? Here are simple versions which you can enhance to flesh them out if required. The key bit is the use of the generic class which provides the flexibility to wrap any class. This is utilised in the RetrieveAs implementation.

public class MockXLANGPart<T> : XLANGPart
{
    T m_obj;

    public MockXLANGPart(T obj)
    {
        m_obj = obj;
    }

    public override void Dispose()
    {
    }

    public override object GetPartProperty(Type propType)
    {
        throw new NotImplementedException();
    }

    public override Type GetPartType()
    {
        throw new NotImplementedException();
    }

    public override string GetXPathValue(string xpath)
    {
        throw new NotImplementedException();
    }

    public override void LoadFrom(object source)
    {
        throw new NotImplementedException();
    }

    public override string Name
    {
        get { return "MockXLANGPart"; }
    }

    public override void PrefetchXPathValue(string xpath)
    {
        throw new NotImplementedException();
    }

    public override object RetrieveAs(Type t)
    {
        if (t == typeof(T))
        {
            return m_obj;
        }

        return null;
    }

    public override void SetPartProperty(Type propType, object value)
    {
        throw new NotImplementedException();
    }

    public override System.Xml.Schema.XmlSchema XmlSchema
    {
        get { throw new NotImplementedException(); }
    }

    public override System.Xml.Schema.XmlSchemaCollection XmlSchemaCollection
    {
        get { throw new NotImplementedException(); }
    }
}

public class MockXLANGMessage<T> : XLANGMessage
{
    List<MockXLANGPart<T>> m_parts = new List<MockXLANGPart<T>>();

    public MockXLANGMessage(T obj)
    {
        m_parts.Add(new MockXLANGPart<T>(obj));
    }

    public override void AddPart(object part, string partName)
    {
        throw new NotImplementedException();
    }

    public override void AddPart(XLANGPart part, string partName)
    {
        throw new NotImplementedException();
    }

    public override void AddPart(XLANGPart part)
    {
        throw new NotImplementedException();
    }

    public override int Count
    {
        get { return m_parts.Count; }
    }

    public override void Dispose()
    {
    }

    public override System.Collections.IEnumerator GetEnumerator()
    {
        return m_parts.GetEnumerator();
    }

    public override object GetPropertyValue(Type propType)
    {
        throw new NotImplementedException();
    }

    public override string Name
    {
        get { return "MockXLANGMessage"; }
    }

    public override void SetPropertyValue(Type propType, object value)
    {
        throw new NotImplementedException();
    }

    public override XLANGPart this[int partIndex]
    {
        get { return m_parts[partIndex]; }
    }

    public override XLANGPart this[string partName]
    {
        get { return m_parts[0]; }
    }
}

My thanks to Anil Prasad for putting me onto this technique.

Where did I leave my HAT?

Following an upgrade to BizTalk 2009 you may be left wondering where the Health and Activity Tracking (HAT) Tool has disappeared to. The Start Menu group for BizTalk 2009 no longer contains a link to HAT.

The answer lies in the BizTalk Administration Console MMC Snap-in. If you navigate to the Group Hub and select New Query you will see some new entries in the Value column such as Tracked Service Instances. This will retrieve data in the same way that the HAT queries did.

Right clicking on one of the resultset entries will offer the same options as HAT used to e.g. Message Flow, Orchestration Debugger. Navigate into one of these options presents the same interface as HAT always used to.

In fact HAT is still there under the covers, it's just been integrated into the Admin Console rather than running as a separate application. Try looking in the Task Manager list of running processes and you'll see BTSHatApp.exe.

HAT is dead...long live HAT.

How to find the BizTalk Edition installed

I recently had to find the edition of an existing BizTalk installation on a test server. Initially I thought this would be a case of looking at a few Help > About dialogs in the admin tools. However, it turns out that this is stored in the registry under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0\ProductEdition

MSBTS_SendAdapter doesn't work!

Just a quick post as a reminder to me (and a pointer for anyone else who happens upon this blog) to save lots of time scratching my head, looking at code that should work but doesn't.

I wrote some code as part of a BizTalk deployment framework which was intended to create an adapter handler if one does not already exist for the specified adapter/host. The Receive handler version worked fine but the Send version gave some strange results.

First I queried the existence of the send handler via WMI using MSBTS_SendHandler. This always returned an empty set indicating that it doesn't (even when the handler does in fact exist). When trying to create a send handler I got an error message (will update with exact text when I get a chance to look).

Anyway, to cut a long story short it turns out that MSBTS_SendHandler2 works fine so the guidance is to use this instead. My question is though - why does MSBTS_SendHandler still exist at all? It can't be for backwards compatibility because IT DOESN'T WORK! Why not just fix MSBTS_SendHandler instead of adding MSBTS_SendHandler2? Answers on a postcard to...

Identifying a BizTalk process

When using multiple BizTalk Hosts the process relating to each host can be identified using the following command line instruction:

tasklist /SVC /FI "IMAGENAME eq btsntsvc.exe"

This will display a list of BizTalk processes with the name of the Host and the PID. Note the PID for the host you are interested in. Match the correct PID with the process listed in Task Manager or the Visual Studio  Attach To Process dialog.

Resolving Schema Type Name Clashes

A common schema related error that may occur when building BizTalk projects that include schemas is:

BEC2017: Node "<Schema>" - This schema file has a TypeName that collides with the RootNode TypeName of one of its root nodes. Make sure that they are different.

The reason for this is quite simple - when the project is compiled, a .NET class will be generated for each top level element in your schema. If you have two schemas which share the same top level element name a clash will occur.

This is quite a common scenario and it is not always practical (or even possible) to change the element names. The solution is to change the generated type name for the schema. To do so, select the schema in the Solution Explorer and press F4 to display the Properties window. Then change the Type Name property so that it is not the same as any of the top level elements.

Default content in Maps

On a couple of occasions recently I have hit upon the need to use default content in some elements of a message generated via a map. More specifically I had an orchestration which did the following:

• Defined an input and output schema that contained a standard header section
• Makes calls to external .NET components, other orchestrations and send ports
• If all works OK, a suitable response message is returned
• In the event of a failure, an exception handler is invoked which constructs a new message to send to a common error logging orchestration before creating and returning a response message to the caller

The area of interest is the message sent to the error logging orchestration. This schema contains the standard header along with error information to be logged (for which each element defined as a distinguished field) i.e.

<xsd:element name="exception_details">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element name="type" type="xsd:string" />
      <xsd:element name="description" type="xsd:string" />
      <xsd:element name="error_source" type="xsd:string" />
      <xsd:element name="details" type="xsd:string" />
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

To create an instance of this message I transform the original request (to create the standard header) and insert the error details via code in a message assignment shape.

msgException.exception_details.description = ex.Message;
msgException.exception_details.details = ex.ToString();
msgException.exception_details.error_source = "orch name";
msgException.exception_details.type = "details here";

However, in order to programmatically insert the content into these elements, the elements had to exist in the new message! If it does not I get an XPath error when trying to set the distinguished property values.

To ensure that the elements exist I used the useful but often overlooked property of the element - Value. To find this open the Map Designer, select the target element and go to the Properties window. There you will see a Value property which can be used to set a default value for the element or <empty>. In this case <empty> was most appropriate giving message content of:

<message>
    <header>
        ...header content omitted
    </header>
    <payload>
        <exception_details>
            <description/>
            <details/>
            <error_source/>
            <type/>
        </exception_details>
    </payload>
</message>

This allowed me to set the error detail programmatically as required. Voila!

How can I use Fiddler to debug BizTalk messages?

When using HTTP, SOAP or WCF send ports it can be incredibly useful to view the content of messages that are sent on the wire. This allows you to inspect the headers (SOAP or HTTP). Fiddler is a simple but fantastic tool to allow you to do this.

By default, Fiddler will not trace any messages sent to endpoints by BizTalk as it does not use WinInet. However, BizTalk send ports can be configured to use a proxy allowing Fiddler to intercept them. On the Send Port tick the Use Proxy checkbox and set the Server to 127.0.0.1 and the port to 8888. For dynamic ports, set the following properties (as applicable to the adapter being used)

// Debug via fiddler
msgSendRequest(SOAP.UseProxy) = true;
msgSendRequest(SOAP.ProxyAddress) = "127.0.0.1";
msgSendRequest(SOAP.ProxyPort) = 8888;

Note that this needs to be removed when Fiddler is not running since traffic directed to the proxy will not be received by anything.

Fix Missing Vista Segoe UI font

A bit off topic here but useful nonetheless. Recently my Vista box mislaid the default system font Segoe UI and consequently fell back to the italic version of the same font. Whilst this is not a huge issue, it just looks ugly!

Anyway after a lot of searching, the font can be replaced for free by installing Windows Live. Worked for me!

Using the SSO database for storing configuration data

Single Sign-on is something that is often overlooked as being related only to Parties and for management of credentials. However, in its raw form, SSO provides a secure data store that can be used to store any information your application needs. In fact it can be used by non-BizTalk applications and doesn't have to only be for sensitive data, though this is the most typical usage.

In order to use SSO programmatically, an API is provided for accessing data. An MMC snap-in is also supplied for administrative purposes and third-party tools also exist for this purpose. Command line based tools also exist enabling scripting support.

Adding new configuration items to SSO

Using the tools supplied out-of-the-box with BizTalk 2006 R2, it is pretty easy to create an SSO schema and populate it with some data.

Create a schema for the configuration data. This is an XML file that look like the following:

<sso>
    <application name="Application Name here">
        <description>Description here</description>
        <contact>email address here</contact>
        <appuserAccount>domain\AppUserAccount</appuserAccount>
        <appAdminAccount>domain\AppAdminAccount</appAdminAccount>
        <field ordinal="0" label="reserved" masked="no" />
        <field ordinal="1" label="field name here" masked="no" />
        <field ordinal="2" label="field name here" masked="yes" />
        <flags groupApp="no" configStoreApp="no" allowTickets="no"
           validateTickets="yes" allowLocalAccounts="no" timeoutTickets="yes"
           adminAccountSame="no" enableApp="no" />
    </application>
</sso>

You can create as many fields as needed and multiple applications too. Note that the first field should not be used for a custom setting and is reserved for internal use.

Use the ssomanage.exe command line tool (in the C:\Program Files\Common Files\Enterprise Single Sign-On\ folder) to create the SSO application based upon the schema. To do so use the -createapps option specifying the filename of the schema XML created above. The application has access control for user and administrators based upon groups. By default these are the “BizTalk Application Users” and “BizTalk Server Administrators” groups respectively.

ssomanage -createapps "MySchema.xml"

To populate the schema with some data, use the BTSScnSSOApplicationConfig.exe command line tool (supplied with source code) in the C:\Program Files\Microsoft BizTalk Server 2006\SDK\Common\SsoApplicationConfig folder. Run Setup.bat to compile the tool and the executable should be generated in the bin folder.

BTSScnSSOApplicationConfig.exe -set AppName "ConfigProperties" "paramname" "paramvalue"

To retrieve a data item

BTSScnSSOApplicationConfig.exe -get AppName "ConfigProperties" "paramname"

Retrieving SSO configuration values in code

Once the data is stored, it can be accessed using the API. BizTalk 2006 comes with a client DLL which can be used to create a configuration reader class. In most instances it is recommended to create a type safe version to convert data items from their name/value pairs into the correct data type.

• Add a reference to assembly Microsoft.BizTalk.InterOp.SSOClient.dll
• Create a Property Bag that implements from IPropertyBag

public class ConfigurationPropertyBag : IPropertyBag
{
    private HybridDictionary properties;

    internal ConfigurationPropertyBag()
    {
        properties = new HybridDictionary();
    }

    public void Read(string propName, out object ptrVar, int errLog)
    {
        ptrVar = properties[propName];
    }

    public void Write(string propName, ref object ptrVar)
    {
        properties.Add(propName, ptrVar);
    }

    public bool Contains(string key)
    {
        return properties.Contains(key);
    }

    public void Remove(string key)
    {
        properties.Remove(key);
    }

}

• Use the SSOConfigStore class to access the data using the property bag

public static class SSOConfigHelper
{

    private static string idenifierGUID = "ConfigProperties";

    /// <summary>
    /// Read method helps get configuration data
    /// </summary>
    /// <param name="appName">The name of the affiliate application
    /// to represent the configuration container to access</param>
    /// <param name="propName">The property name to read</param>
    /// <returns>
    ///  The value of the property stored in the given affiliate
    /// application of this component.
    /// </returns>
    public static string Read(string appName, string propName)
    {
        try
        {
            SSOConfigStore ssoStore = new SSOConfigStore();
            ConfigurationPropertyBag appMgmtBag = new ConfigurationPropertyBag();
            ((ISSOConfigStore) ssoStore).GetConfigInfo(appName, idenifierGUID, SSOFlag.SSO_FLAG_RUNTIME, (IPropertyBag) appMgmtBag);
            object propertyValue = null;
            appMgmtBag.Read(propName, out propertyValue, 0);
            return (string)propertyValue;
        }
        catch (Exception e)
        {
            System.Diagnostics.Trace.WriteLine(e.Message);
            throw;
        }
    }
}

Whilst the use of these command line tools is potentially advantageous from a scripting perspective, their use on an ad-hoc basis is not ideal. An MMC snap-in now exists for managing an SSO database. Richard Seroter has written a really cool configuration tool for managing configuration data which has a handy export feature that will export the application schema as an XML file. Source code is also available.

Promoting Properties that are not in a Message

In most instances properties are promoted from message content during the disassemble stage of a pipeline. However, in some cases it is useful to promote a property that does not relate to the content of a message. For example you may want to generate a unique identifier for a transaction and promote that into context for later use. To do so:

• Create a new property schema (or open an existing one)
• Add a new Child Field Element named with the required property name
• In the properties window, set the "Property Schema Base" property to MessageContextPropertyBase. This is the key to making this work. The default value is MessageDataPropertyBase indicating that the value is coming from a message
• In the orchestration or pipeline, set the new property value programmatically

See Stephen W Thomas's blog entry for more on this.

Dynamic SOAP Adapters

Following on from my previous post concerning dynamic HTTP adapters, this time I'll extend the same concept to the SOAP adapter. Many of the techniques previously presented are still applicable but the SOAP adapter has it's own little idiosyncrasies which once explained are easy enough to overcome.

The first issue is that of a proxy. In traditional .NET applications, when using a web service it is typical to add a web reference which, under the covers will generate a proxy to the remote service based on its WSDL definition. This is also what would happen if you add a web reference in your orchestration and use a static SOAP send port. However, for a dynamic send port we don't want to create a web reference - we'll generate the proxy manually using the wsdl.exe tool as follows:

C:\>wsdl /l:CS /o:c:\temp\wsdl http://localhost/CalcWebService/CalcService.asmx?wsdl
Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved.
Writing file 'c:\temp\wsdl\CalcService.cs'.

Here we have generated a proxy class from the WSDL of the web service. Add this to a new Class Library project. Ensure the resulting assembly is strong named and add it to the GAC. Note that the WebMethod to be called should have a signature as below that will accept an XML message and return one too. If an alternative method signature is required it will be necessary to update the proxy class to act as an facade between the required signature and the web service one.

[WebMethod]
public XmlNode MyMethod(XmlNode Message)

As with the HTTP example, we'll be invoking a dynamic adapter from an orchestration, setting adapter properties to change its behaviour at runtime. Again, add a request/response send port to the orchestration port surface and mark its type as Dynamic. The only other configuration required on the port is to specify the pipelines to be used, in this case XmlTransmit and XmlReceive. Connect up the request and response operations to the relevant send and receive shapes in the orchestration. Note that the operation on the send port should have the same name as the WebMethod being called.

Prior to sending the message set the following send port properties:

// Assign message
msgSendRequest = msgReceiveRequest;

// Set base properties
MySendPort(Microsoft.XLANGs.BaseTypes.Address) =
                     "http://localhost/CalcWebService/CalcService.asmx";
MySendPort (Microsoft.XLANGs.BaseTypes.TransportType) = "SOAP";

// Set HTTP adapter specific properties
msgSendRequest(BTS.SOAPAction) = "Add";
msgSendRequest(SOAP.MethodName) = "Add";
msgSendRequest(SOAP.AssemblyName) = "CalcTest.CalcWebServiceProxy.CalcService,
    CalcWebServiceProxy, Version=1.0.0.0, Culture=neutral,
    PublicKeyToken=b713f1108bae3109";
msgSendRequest(SOAP.TypeName) = "CalcTest.CalcWebServiceProxy.CalcService";

Some important points to note here:

1. The TransportType is a means of informing BizTalk which adapter you want to use. If it is omitted the prefix of the Address (in this case http://) will be used to query an alias table to lookup the adapter to use. By default this will use the HTTP adapter, therefore we set the Microsoft.XLANGs.BaseTypes.TransportType property to "SOAP" to ensure that the SOAP adapter is targeted.
2. The BTS.SOAPAction and the SOAP.MethodName are both set to the name of the WebMethod being invoked.
3. The SOAP.AssemblyName must be populated with the details of the class name and assembly of the proxy to be used. This value takes the form Namespace.ClassName, Fully Qualified Assembly Name. Set this to the details of the proxy assembly created and GAC'd earlier.
4. The SOAP.TypeName must also be set to the full name of the proxy class i.e. Namespace.ClassName. Not sure why this is required again but if it is not set an error occurs.

OK, now you should be good to go. Build, deploy and (hopefully) watch those SOAP requests flying to and from your web service. Whilst it's a little more fiddly to setup that the HTTP equivalent, using a dynamic SOAP adapter is a really powerful technique for creating flexible and extensible BizTalk applications.

Jon Fancey has taken this a step further by creating a more generic SOAP router. Check it out.

Dynamic Send Ports

Part of the project I'm currently working on involves sending XML messages to a variety of trading partners. Each partner has several products each of which could require different port settings (URL, credentials, timeout, retry strategy). Another variable is the transport type. Currently all support plain XML over HTTP but in the future SOAP may be a requirement. As we have up to 1000 different partner/product combinations to support dynamic ports seem like a logical choice.

So how do you implement dynamic HTTP and SOAP send ports? Let's start with HTTP first as it's a little more straightforward.

Assuming that the orchestration is in place, add a request/response send port to the port surface and mark its type as Dynamic. The only other configuration required on the port is to specify the pipelines to be used and to connect up the request and response operations to the relevant send and receive shapes in the orchestration.

Prior to the send shape (I have used the message assignment shape that builds the request message) add the following code.

// Assign message
msgSendRequest = msgReceiveRequest;

// Set base properties
MySendPort(Microsoft.XLANGs.BaseTypes.Address) = "http://localhost/testpartner/test.aspx";
MySendPort(Microsoft.XLANGs.BaseTypes.TransportType) = "HTTP";

// Set HTTP adapter specific properties
msgSendRequest(HTTP.AuthenticationScheme) = "Basic";
msgSendRequest(HTTP.Username) = "mark";
msgSendRequest(HTTP.Password) = "pwd";

This code sets up the address URI and the transport type to be used. The TransportType is a means of informing BizTalk which adapter you want to use. If it is omitted the prefix of the Address (in this case http://) will be used to query an alias table to lookup the adapter to use. For some prefixes there are multiple adapters that could handle the request. For http:// it could be the HTTP, WCF-Basic or WCF-WSHttp so the TransportType property can be used to explictly choose the correct adapter. In this instance I could have omitted the TransportType since the HTTP is the default for http:// addresses.

Next I have set some properties that are specific to the HTTP adapter. In this instance I have just configured the authentication details but there are lots of other that can be used. Typically these settings could be looked up from a database or other configuration store and set dynamically based on the request.

And that's it! The request should then be routed to the URI configured in code above using the HTTP adapter. This is a very powerful technique to add flexibility to your application. I'll continue by demonstrating how to use the same technique for the SOAP adapter in a future post.

Installation Gotchas

When installing BizTalk Server 2006, the process is generally pretty smooth. I have installed it a couple of times on different machines and had no problems to speak of. However, there are a few things to look out for if you do encounter problems:

• Check the event log is not full. BizTalk Server is not shy about writing to the event log so make sure that the Application log is not full and supports overwriting of events as necessary.
• Make sure you are not logged on with a Windows account that has no password. The Master Secret Server Key is generated using the password of the logged on user as a seed.
• Do not install onto a non-NTFS formatted disk. BizTalk Server does not support FAT32.
• If using a domain account, ensure that access to the domain controller is available.
• Ensure you have enough available disk space. The System Requirements state "15 GB of available hard disk space for a complete installation including the operating system, all prerequisite software, and language packs. This does not include disk space for data storage."