BizTalk

BizTalk 2006 Service Pack 1 Beta

Paul Petrov — Wed, 14 Oct 2009 16:10:05 GMT

BizTalk 2006 R2 Service Pack 1 Beta 1 has been released. It's available through MS Technology Adoption Program at https://connect.microsoft.com/site/sitehome.aspx?SiteID=65. List of features http://msdn.microsoft.com/en-us/library/ee532481(BTS.20).aspx.

How to save password for WCF Adapter in BizTalk binding file

Paul Petrov — Thu, 27 Aug 2009 19:31:44 GMT

Generally, it is not recommended to store passwords in the binding file and by default BizTalk administration UI clears it out when exporting binding to the xml file. But in development environment where you have automated continuous integration build and deployment not having password in the binding file will prevent application from starting and CI process fail. It can become tedious in staging deployments (TEST, UAT) as well, especially if you have multiple endpoints that use accounts with passwords. In such cases, having password for development account (hopefully not the same as production) in binding file can make life easier.

To do that, export binding file after application is fully configured. Open it and locate section(s) with configuration for the ports/locations of interest. For example for the WCF receive location it will be in:

<ReceiveLocationTransportTypeData><CustomProps>...</CustomProps></ReceiveLocationTransportTypeData>

Find emtpy password tag in this section that will look like:

<Password vt="1"/>

Change it to enclose you password value and vt attribute value to "8":

<Password vt="8">MyPassword</Password>

Save and use this binding for an automated deployment script.

Default Database Instance in WCF Adapter URI

Paul Petrov — Thu, 02 Jul 2009 16:14:39 GMT

Recently during migration BizTalk project from SQL to WCF adapter had some rather confusing moment. After deploying to test environment WCF ports started generate errors like this:

Failed to open Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestChannel, Faulted Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestChannel, Faulted System.ServiceModel.Channels.ServiceChannel, Failed to open System.ServiceModel.Channels.ServiceChannel

After few frustrating troubleshooting sessions it was found that adapter binding was missing identifier for the default database instance. Here's what we had:

	Development	Test
SQL port URI	SQL://DevServer\DevInstance\Database	SQL://TestServer/Database
WCF port URI	mssql://TestServer/DevInstance/Database	mssql://TestServer/Database

Both adapters worked in development, but in test WCF did not. What was missing is "//" between server and database part of the URI. This is not required for SQL adapter configuration but apparently is critical for the WCF adapter. So the correct URI should have been: mssql://TestServer//Database.

Microsoft ESB Guidance installation

Paul Petrov — Sat, 21 Feb 2009 00:58:50 GMT

I just installed Microsoft Enterprise Service Bus Guidance framework (November 2007 version for BizTalk 2006 R2). Although lengthy installation process is well documented in the accompanying help file I ran into multiple issues and it took a couple of days to sort everything out. I'd like to mention here major problems/solutions in case somebody decides to go through the same. First, if you install on other than default location (C:/%PROGRAM_FILES% and C:/Projects) make sure to update all scripts and command files as well as bindings. Second, I had issue with UDDI service configuration. It wouldn't install until I enabled NTLM authentication for IIS. It is done by executing IIS utility script per this MS article. But this command worked only when I dropped quotes around Negotiate,NTLM contrary to MS KB article. Also, make sure the default web site ID is "1". Some of my computers had it set to different numbers so I had to change command line appropriately. In the end command that worked looks like this:

cscript adsutil.vbs get w3svc/<Default Web Site ID>/root/NTAuthenticationProviders Negotiate,NTLM

Another problem is that assemblies in MSI packages are signed with different key comparing to source projects. So even if you install all ESB components from source you will run into this issue because some of the projects reference assemblies from packaged installation. Solution is to go through all project references, remove them and add new to ones generated from source code. The same applies to sample applications. Don't install them from MSI if you chose source code based ESB installation. Open project, update references, rebuild and deploy.

SSO Configuration Tool Updated

Paul Petrov — Fri, 05 Dec 2008 06:21:18 GMT

Uploaded new version of SSO Config Tool including fix for the browsing SSO Config Store application and some usability/UI improvements. Download source code.

Handling SOAP Exceptions in BizTalk Orchestrations with WCF Send Adapter

Paul Petrov — Mon, 23 Jun 2008 17:29:28 GMT

Below is an idea how to improve SOAP exception handling in BizTalk to WCF communication. Let’s consider approach recommended in BizTalk SDK documentation (Catch Typed Fault Exception sample):

Add custom WCF fault to the service contract and add corresponding exception handler in the BizTalk orchestration.
In BizTalk orchestration add hander that expects System.Web.Services.Protocols.SoapException to catch any general SOAP exceptions

This allows catching any custom WCF faults and handling them gracefully. It also handles general SOAP exceptions but the downside is that SOAP exception caught will not be original SOAP fault that came over the wire from the service. It’s going to be secondary SOAP exception thrown by the adapter. Receive pipeline will try to match incoming message type using XPath expressions defined in the send port configuration. Since custom WCF faults are embedded as content of Detail node of the soap:Fault message there will be XPath expression like this: /*[local-name()='Fault']/*[local-name()='Detail']/* | /*[local-name()='DivideResponse'], where the first part is matching any child of Detail element. In case if WCF service returns general SOAP fault it will put original exception in Detail element as ExceptionDetail node (QName: http://schemas.datacontract.org/2004/07/System.ServiceModel#ExceptionDetail). Since the schema for ExceptionDetail is unknown to pipeline it will throw SOAP exception with generic description and all original details will be lost. This secondary SOAP exception is the one that actually caught by our generic handler:

There was a failure executing the response(receive) pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Send Port: "WcfSendPort_Operator_WSHttpBinding_IOperation" URI: "http://localhost:8005/calculate" Reason: Finding the document specification by message type "http://schemas.datacontract.org/2004/07/System.ServiceModel#ExceptionDetail" failed. Verify the schema deployed properly.

One solution to this problem is to define http://schemas.datacontract.org/2004/07/System.ServiceModel#ExceptionDetail schema and include it as a fault contract for the WCF operation on the client side. That way all original SOAP fault details can be captured and propagated as ExceptionDetail fault. So that’s how I modified BizTalk orchestration in SDK sample:

Declared new schema ExceptionDetail.
Created new multi-part message type IOperation_Divide_SoapFault that has part of type ExceptionDetail
Added to Divide operation new GenericSoapFault fault of type IOperation_Divide_SoapFault
Added exception handler CatchSoapExceptionDetails for this new fault

Notice no changes required on the service side, all I had to do is on the client. But I did one thing in the service code to throw SOAP exception if numerator equal to 0 (just to be able to test such scenario):

if (numerator == 0)

throw new System.Web.Services.Protocols.SoapException("Test exception", new XmlQualifiedName("A100"));

Dropping input file with 0 as numerator (DivideGenerateSOAPExceptionInput.xml) will create following message in the Fault folder:

<?xml version="1.0" encoding="utf-8"?><MyOperationException xmlns="http://schemas.datacontract.org/2004/07/Service" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Error>&lt;ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"&gt;&lt;HelpLink i:nil="true" /&gt;&lt;InnerException i:nil="true" /&gt;&lt;Message&gt;Test exception&lt;/Message&gt;&lt;StackTrace&gt;   at Service.Operator.Divide(Int32 numerator, Int32 denominator) in C:\Projects\TestBed\Typed Fault Exception Handling\WcfService\Program.cs:line 37
   at SyncInvokeDivide(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]&amp;amp; outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc&amp;amp; rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)&lt;/StackTrace&gt;&lt;Type&gt;System.Web.Services.Protocols.SoapException&lt;/Type&gt;&lt;/ExceptionDetail&gt;</Error>
  <Operation>Divide</Operation>
</MyOperationException>

Note it contains exception detail section with original "Test exception" message.

Another approach would be to use exclusively SOAP faults for all kind of custom and system faults, reducing number of exception handlers in orchestrations to one. It can be achieved by implementing custom XML Disassembler pipeline component where incoming message would be inspected and if SOAP Fault is detected all properties can be copied to secondary SOAP fault thus preserving all original exception details.

Source code of modified SDK sample is available here.

Storing BizTalk settings in custom configuration file using Enterprise Library

Paul Petrov — Wed, 11 Jun 2008 20:12:37 GMT

Choice of configuration settings storage is an important topic when it comes to enterprise BizTalk application planning. One of the many options is to use regular .Net configuration files. Some prefer this way over the Enterprise SSO database option for reasons of simplicity and familiarity. I wanted to show how it can be done with Microsoft Enterprise Library configuration application block.

In this case Enterprise Library configuration section is placed in the BTNTSvc.exe.config file while application settings are stored in a separate configuration file. The problem here is how do we make EntLib to load required settings file at runtime. Its done by simple helper class CustomSettings that looks up registry entry for the location and name of the application configuration file and creates FileConfigurationSource with it. The registry entry can be created by MSI installation package.

The initialization method of this static helper class looks like this (thread synchronization code omited for brevity):

          RegistryKey regKey = null;

          try
          {
             regKey = Registry.LocalMachine.OpenSubKey(@"Software\MyCompany\MyApplication");
             configurationFile = Path.Combine(
             (string)regKey.GetValue("ConfigDir"),
             (string)regKey.GetValue("ConfigFile"));

              ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
              fileMap.ExeConfigFilename = configurationFile;
              configuration = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
              configurationSource = new FileConfigurationSource(configurationFile);

              //- store configPath in the settings
              configuration.AppSettings.Settings.Add(
              new KeyValueConfigurationElement("configDir", (string)regKey.GetValue("ConfigDir")));
           }
           catch (Exception ex)
           {
              Debug.WriteLine("Exception while initializing Settings:" + ex.ToString());
              throw ex;
           }
           finally
           {
              if (regKey != null) regKey.Close();
           }

Then it has method to access properties by name:

        public static string GetValue(string name)
        {
            KeyValueConfigurationElement entry = Configuration.AppSettings.Settings[name];

            if (entry == null)
                throw new ConfigurationErrorsException("Key '" + name + "' is not found in the configuration file.");

            return Configuration.AppSettings.Settings[name].Value;
        }

Which is used as in:

string propertyValue = CustomSettings.GetValue("propertyName");

MSBuild Tasks for BizTalk Continuous Integration

Paul Petrov — Tue, 10 Jun 2008 01:04:19 GMT

If you store BizTalk application settings in Enterprise SSO database and adapt continuous integration you'll find this MS Build task useful. DeploySSOConfigStore task reads settings from XML configuration file and saves them to the SSO database. The XML can be created (exported) using Richard Seroter's SSO tool which I modified to support this operation. So, if you change your configuration settings, just update XML file in the source control and build process will pick it up and propagate changes to your target environment. Using this task is very simple, it accepts just one parameter - location of the XML settings file:

    <UsingTask AssemblyFile="CustomMSBuildTasks.BizTalk.dll" TaskName="CustomMSBuildTasks.BizTalk.DeploySSOConfigStore"/>

    <Target Name="DeploySSOConfigStore" DependsOnTargets="BizTalkDeploy">
        <CustomMSBuildTasks.BizTalk.DeploySSOConfigStore XmlConfigurationUrl="$(SolutionRoot)\$(BuildBranch)\Source\BizTalkSettings\BizTalk.Configuration.xml"/>
    </Target>

I also added another useful task for publishing WCF services: PublishBizTalkWcfServices. It's very simple but does all that stuff: setting up virtual directories (if needed), publishing contracts, creating receive locations. It has comprehensive logging that helps tracking down deployment issues quickly.

    public class PublishBizTalkWcfServices : Task
    {
        private string serviceDescriptionUrl;

        /// <summary>
        /// The URL to the description file.
        /// </summary>
        [Required]
        public string ServiceDescriptionUrl
        {
            get { return serviceDescriptionUrl; }
            set { serviceDescriptionUrl = value; }
        }

        /// <summary>
        /// Publishes BizTalk schemas as WCF services.
        /// </summary>
        /// <returns></returns>
        public override bool Execute()
        {
            WcfServiceDescription description = WcfServiceDescription.LoadXml(ServiceDescriptionUrl);

            Publisher publisher = new Publisher();
            publisher.BackgroundWorker = new System.ComponentModel.BackgroundWorker();
            publisher.BackgroundWorker.WorkerReportsProgress = true;
            publisher.BackgroundWorker.ProgressChanged += new System.ComponentModel.ProgressChangedEventHandler(BackgroundWorker_ProgressChanged);

            try
            {
                PublishingResults results = publisher.Publish(description);

                Log.LogMessage(results.Message);
            }
            catch (Exception ex)
            {
                Log.LogError(ex.ToString(), null);
                return false;
            }
            return true;
        }

        public void BackgroundWorker_ProgressChanged(object sender, System.ComponentModel.ProgressChangedEventArgs e)
        {
            Log.LogMessage(e.UserState.ToString(), null);
        }
    }

Complete Visual Studio project is available here.

Improved SSO Configuration Data Store Tool

Paul Petrov — Fri, 16 May 2008 20:54:34 GMT

Richard Seroter published useful utility to store/retrieve BizTalk configuration settings in Enterprise SSO database. I added some more functionality to it.

First, I added Export/Import functions allowing to actually save values in the external XML file (Richard's implementation allowed storing only field names, calling for extra work should you delete and restore SSO aplication). I kept file format the same but added values stored as text nodes:

<sso>
  <application name="eCommerce.BizTalk.Configuration">
    <description>Configuration storage for eCommerce BizTalk applications</description>
    <appUserAccount>BizTalk Application Users</appUserAccount>
    <appAdminAccount>BizTalk Server Administrators</appAdminAccount>
    <contactInfo>http://geekswithblogs.net/paulp</contactInfo>
    <field ordinal="0" label="App1.SiteId" masked="no">2</field>
    <field ordinal="1" label="App1.UserId" masked="no">8</field>
    <field ordinal="2" label="App2.Timeout" masked="no">5000</field>
    <flags configStoreApp="yes" allowLocalAccounts="yes" enableApp="yes" />
  </application>
</sso>

New usage scenarios:

1. Saving configuration:

1.1 Create application;
1.2 Save to XML;
1.3 Manage application - Retrieve settings;
1.4 Export to XML file created in (1.2).

2. Restoring previously saved configuration:

2.1 Create application;
2.2 Manage application - Import configuration from file created in (1.4) ;
2.3 Save Changes.

Accordingly, menu items Import/Export available when the Manage Application tab is selected only.

The code can be downloaded here.

Generic BizTalk message broker source code

Paul Petrov — Mon, 04 Feb 2008 18:18:30 GMT

I uploaded source code for the generic BizTalk message broker described in this post.