Wade Wegner

As I was putting together the demonstration for the talk I’m giving tomorrow on BizTalk Server R2 and the WCF Adapters I had to do a few things to get some basic examples working, as this was a brand new virtual environment.  I thought I’d document some of the actions I had to take.

1. Registering the “WCF-BasicHttp” adapter.

After creating and deploying an orchestration for use with the “WCF-BasicHttp” adapter, I received the following error:

The Messaging Engine failed to register the adapter for “WCF-BasicHttp” for the receive location “/SampleWCFDemo/SampleWCFDemo_Process_ProcessPort.svc”. Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases.

I had to take two steps to resolve the problem.  First, create a new application pool and set the identity to the service account used by the isolated host instance.  Second, give the service account used by the isolated host instance read/write access to the C:\Windows\Temp\ directory.

2. Can’t find the “SvcUtil.exe” console application.

Turns out that I had forgotten to install the Windows SDK and .NET Framework 3.0 Runtime Components.  See my previous post on how to setup a BizTalk Server 2006 R2 development environment for more information.

3. “SvcUtil.exe” failed when generating the service metadata.

When I ran the command “C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\SvcUtil.exe”
http://localhost/SampleWCFDemo/SampleWCFDemo_Process_ProcessPort.svc?wsdl I ended up getting the following error:

Error: Cannot obtain Metadata from http://localhost/SampleWCFDemo/SampleWCFDemo_Process_ProcessPort.svc?wsdl

If this is a Windows (R) Communication Foundation service to which you have access, please check that you have enabled metadata publishing at the specified address.  For help enabling metadata publishing, please refer to the MSDN documentation at http://go.microsoft.com/fwlink/?LinkId=65455.

WS-Metadata Exchange Error
    URI: http://localhost/SampleWCFDemo/SampleWCFDemo_Process_ProcessPort.svc?wsdl
    Metadata contains a reference that cannot be resolved: ‘http://localhost/SampleWCFDemo/SampleWCFDemo_Process_ProcessPort.svc?wsdl’.
    Content Type application/soap+xml; charset=utf-8 was not supported by service http://localhost/SampleWCFDemo/SampleWCFDemo_Process_ProcessPort.svc?wsdl .  The client and service bindings may be mismatched.
    The remote server returned an error: (415) Cannot process the message because the content type ‘application/soap+xml; charset=utf-8′ was not the expected type ‘text/xml; charset=utf-8′..

HTTP GET Error
    URI: http://localhost/SampleWCFDemo/SampleWCFDemo_Process_ProcessPort.svc?wsdl

Additionally, when I loaded the WSDL in Internet Explorer, I got the message:

Metadata publishing for this service is currently disabled.

Turns out that I had to change the service behavior to allow the metadata to be published.  You can do this by modifying the Web.Config file of the service so that “httpHelpPageEnabled” is set to true:

<behavior name=”ServiceBehaviorConfiguration”>
    <serviceMetadata httpGetEnabled=”true” httpsGetEnabled=”false” />
</behavior>

Changing the value from “false” to “true” resolves the problem.

…

Those were the three issues that came up tonight.  I’m sure there will be more, and I’ll post the resolutions when I can.

I hope this helps!

In preparation for the talk I am giving tomorrow on BizTalk Server R2 and the WCF Adapters, I thought I would post some notes on how to setup and configure a BizTalk Server 2006 R2 development environment.
The installation is really quite straightforward.  Start with a relatively clean machine (I suggest you use a virtual machine, as these are all beta bits).  My (virtual) machine had the following installed before I started the R2 installation:

• Windows Server 2003 R2 Standard Edition with Service Pack 2
• IIS 6.0
• Microsoft .NET 1.0, 1.1, 2.0, 3.0
• Microsoft Visual Studio 2005 Team Developer Edition with Service Pack SP1
• SQL Server 2005 with Service Pack SP2

Additionally, you need to install the Windows SDK and .NET Framework 3.0 Runtime Components.  This gives you the documentation, samples, header files, libraries, and tools you need to develop applications that run on Windows.  You can download this from: http://www.microsoft.com/downloads/details.aspx?FamilyId=C2B1E300-F358-4523-B479-F53D234CDCCF&displaylang=en.  Note: it takes awhile, so be patient.  Also, I removed the documentation and samples, which makes the download and installation a lot faster.
From here you just need to download the R2 bits.  To find out how you can obtain BizTalk Server 2006 R2 (beta 2), take a look at this article: http://support.microsoft.com/kb/936046.  Or, if you want me to save you the work and take you directly to the bits, you can go here: https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=65&DownloadID=6014.
The BizTalk 2006 R2 Beta 2 release includes the following components:

• BizTalk core engine
• EDI
• RFID
• LOB Adapters
• BizTalk Accelerators (HL7, SWIFT, RosettaNet)

The components are available by downloading and installing the following files:

• BTS06R2_Beta2.exe
• BTS06R2_Beta2_Accelerators.zip
• BizTalk LOB Adapters Sp1 Beta2.exe
• CustomSOAPHeaderPipeline.zip

Note: if you only want the R2 functionality (e.g. WCF, etc) you only need BTS06R2_Beta2.exe.
After I downloaded all the files, I first extracted the contents of BTS06R2_Beta2.exe to a temporary folder (choose a folder you can remember, like C:\Temp\BTS06R2_Beta2).  Next, I ran Setup.exe from that folder.  Click Next until you get to the Component Installation screen.  You’ll see that there are a few differences from the standard BizTalk components.  Here’s a peak:
 
I decided to leave the default settings.  Feel free to do what you want.  Continue to click Next until you get to the Summary screen.  Review your selections and click Install (you may also want to set your auto-login credentials to save time).
After it installs you have to run the BizTalk Configuration Tool.  The configuration is roughly the same as it is for BizTalk Server 2006:

I don’t plan on using many of the features at the moment (e.g. BAM, HWS, etc.) so I only installed the following features:

And that’s it!  At this point, you will have BizTalk 2006 R2 (beta 2) installed and functioning.  Open up the BizTalk Server 2006 Administration Console and take a look at the adapters now available to you:

Specifically, you now can use the following adapters:

• WCF-BasicHttp
• WCF-Custom
• WCF-CustomIsolated
• WCF-NetMsmq
• WCF-NetNamedPipe
• WCF-NetTcp
• WCF-WSHttp

I hope this helps you explore the new functionality available to you in BizTalk Server 2006 R2.  Enjoy!

I was able to use the XML sample documents that come with eConnect (C:\Program Files\Microsoft Great Plains\eConnect9\XML Sample Documents\Incoming) to write some test data into my GP database using the eConnect 9.0 adapters for BizTalk Server 2006.  I setup a test environment using the TWO database for Great Plains, and through the adapter was able to insert data.  Feeling that I had made some good progress, I shutdown my machine (they are all virtualized environments) and went home for the night.

When I started everything up the next day I tried to reproduce this behavior so that I could move on with my integration.  However, every time I tried to write the document into GP through the adapter, I got the following error:

Event Type:    Error
Event Source:  BizTalk DW Reporting
Event ID:      1000
Description:   Faulting application btsntsvc.exe, version 3.5.1602.0, stamp 4410e6b9, faulting module kernel32.dll, version 5.2.3790.4062, stamp 46264680, debug? 0, fault address 0x0000bee7.

This had me stumped for a little while.  I decided to use a useful tool I received from Microsoft called the Direct Document Sender.NET (I’ve attached the file at the bottom of this post) to try and diagnose the problem.  This tool allows you to post an XML document directly to eConnect so that you can test out the functionality without any 3rd party application (e.g. BizTalk Server).

Using this application, I tried to post the XML file again.  This time I received a much more useful error:

System.Runtime.InteropServices.COMException (0x8000401A): The server process could not be started because the configured identity is incorrect.  Check the username and password.

Aha!  This was a much more useful error!

I opened up Component Services (Start –> Administrative Tools –> Component Services), and browsed to Computers –> My Computer –> COM+ Applications –> eConnect 9 for Great Plains.  The Microsoft Great Plains eConnect Version 9 COM Plus Package has a tab entitled Identity which allows you to define the user account under which the application runs.  Turns out that somehow my account was switched from the user I specified at installation to the interactive user system account:

And this was the root cause of my problem.  eConnect requires integrated security and uses the user specified in this identity tab to access the GP database.  Consequently, the user specified must have access to the appropriate database on the GP server and also be a part of the DYNGRP role.

So, I went ahead and added my user to the DYNGRP role, made sure it had the appropriate access, and then updated account used by the COM+ package:

Having made these changes, I tested with the Document Sender.NET application – worked the first time!  Confidently I tested with BizTalk, and sure enough everything started to work!

I’m not sure why it initially worked and then stopped working after I restarted the machines.  I’m not sure if the account credentials changed or if something else was happening the first time.  All I know is that you have to use an appropriate user that has access to the database and is a member of the appropriate role, otherwise you’ll get the errors I listed above.

I hope this helps!

DirectDoc9.zip (7.42 KB)

I got caught up yesterday with a problem I should have recognized right away, but for whatever reason I didn’t put the pieces together until it was pointed out by one of my co-workers.

I was writing a BizTalk Server 2006 orchestration that, amongst other things, sends a request to a remote server.  The remote server has an application installed that accesses these requests and initiates a few local (and unimportant) processes.  Information is passed to this application via the URL which is unique with each request and constructed by the orchestration.

Rather than use a dynamic one-way send port with the HTTP adapter, I decided to create a .NET helper project (a C# class library) and create a static method that allows me to pass in the URL and wait for a response.  The contents of the response itself is unimportant; all I require is a successful response.

I created the following class in my helper project (simplified for clarity):

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Text;

   4:  using System.Net;

   5:  namespace Messaging.Helper

   6:  {

   7:      [Serializable]

   8:      public class Statics

   9:      {

  10:          public void CallUrl(string url)

  11:          {

  12:              WebRequest request = WebRequest.Create(url);

  13:              request.Method = "GET";

  14:              request.GetResponse();

  15:          }

  16:      }

  17:  }

As you can see, the static method uses the System.Net.WebRequest class to issue a request to the specified URL.  To test this method, I created a command-line application that iterated 20 or so times and issued requests against the remote server.  The code was similar to the following (simplified for clarity):

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Text;

   4:  using System.Net;

   5:  using Messaging.Helper;

   6:  namespace Messaging.ConsoleApp

   7:  {

   8:      class Program

   9:      {

  10:          static void Main(string[] args)

  11:          {

  12:              for (int i = 0; i < 20; i++)

  13:              {

  14:                  Statics.CallUrl("http://www.someurl.com/");

  15:              }

  16:          }

  17:      }

  18:  }

I immediately noticed that this code failed after it issued two concurrent requests.  No matter how many times I ran it, it always was successful the first two times and then timed-out and threw an error message similar to the following:

System.Net.WebException was unhandled
Message="The operation has timed out"
Source="System"
StackTrace:
  at System.Net.HttpWebRequest.GetResponse()
  at ConsoleApp.Program.Helper.CallUrl() in D:\Test\ConsoleApp\Program.cs:line 41
  at ConsoleApp.Program.Main(String[] args) in D:\Test\ConsoleApp\Program.cs:line 20
  at System.AppDomain.nExecuteAssembly(Assembly assembly, String[] args)
  at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity,
     String[] args)
  at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
  at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
  at System.Threading.ExecutionContext.Run(ExecutionContext executionContext,
     ContextCallback callback, Object state)
  at System.Threading.ThreadHelper.ThreadStart()

Yes, I should have immediately picked up on the fact that it succeeded the first two times but then consistently failed on each additional request.  Instead, I tried all kinds of different scenarios (non-static methods, multi-threaded calls, etc.).  Fortunately, a co-worker stopped by and reminded me that, by design, there is a limit on the number of connections you can have to any given server.  By default, this limitation is set to two!

As soon as he said that I remembered the limitation (I guess I still have a few neurons that occasionally fire).  Immediately I created an application configuration file for my command-line application and added the following (of course, I had to look-up the exact syntax):

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <configuration>

   3:      <system.net>

   4:          <connectionManagement>

   5:              <add address="*" maxconnection="100" />

   6:          </connectionManagement>

   7:      </system.net>

   8:  </configuration>

This allows for up to 100 simultaneous connections to any server.  When I ran my command-line application again it worked perfectly — 20 requests were issued to the URL.

After poking around a little bit, I found the actual specification in the HTTP/1.1 protocol that dictates this limitation.  See Hypertext Transfer Protocol – Section 8.1.4:

"Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion."

Ah, this explains why Internet Explorer only allows me to download two files at the same time!

Now, in order to allow my BizTalk orchestration to proper issue more than two concurrent connections (remember, it too is just calling .NET code), I needed to modify the BTSNTSvc.exe.config file that services the BizTalk host instances.  This file is found in the BizTalk Server directory under Program Files:

Simply add the <system.net> … </system.net> XML to the configuration file and then restart your host instances.  This will allow you to issue more than two concurrent requests to any given web server.

I hope this helps save you some time you would have otherwise lost!

I came across a frustrating interesting problem today where the BizTalk Server 2006 Configuration wizard would fail every time I applied a new configuration.

Unlike a typical BizTalk developer environment (which usually consists of BizTalk and SQL Server on the same machine), this environment consisted of two separate machines: one BizTalk Server 2006 and one SQL Server 2005 (i.e. the BizTalk databases are stored on the SQL Server).  Additionally, this is a virtual environment and both machines were cloned from the same base Windows Server 2003 R2 template.

I was installing the following components …

• Enterprise Single Sign-On (SSO)
• Group
• BizTalk Runtime
• MSMQT

It would successfully install ENTSSO, but would fail when installing the group.  The log file reported the following error:

Failed to configure with error message [Exception of type 'System.EnterpriseServices.TransactionProxyException' was thrown.]

The following Google search suggested to me that  the underlying problem was with MSDTC (aren’t all BizTalk problems?).  I checked, and double-checked, the MSDTC properties on both servers and couldn’t find anything wrong with the configuration.  So, I had to pull out the big guns.

I downloaded DTCPing (a very handy tool for debugging DTC issues) and ran it on both machines (make sure to read the instructions on how to use DTCPing as it is not straightforward).  In the generated log file I noticed the following warning:

WARNING: the CID values for both test machines are the same while this problem won’t stop DTCping test, MSDTC will fail for this …

A Google search on this warning helped me to understand that the underlying problem is that the CID values stored for MSDTC were not changed during the cloning process.  But of course!

If you’re experiencing this problem, check the following registry key on both of your machines.  Are the keys identical?

HKEY_CLASSES_ROOT\CID

Mine were.  Here’s the steps I took successfully reinstall MSDTC so that the CID values were unique.  Run this procedure on both machines:

1. Use Add Windows Components, and remove Network DTC.
2. Go to the command line and run: MSDTC -uninstall
3. Go to the registry and delete the MSDTC keys in HKLM/Software/Microsoft/Software/MSDTC, HKLM/System/CurrentControlSet/Services/MSDTC, and HKEY_CLASSES_ROOT\CID (if they’re still there).
4. Reboot
5. Go to the command line and run: MSDTC -install
6. Use Add Windows Components, and add Network DTC.
7. Go to the command line and run: net start msdtc

After running this on both servers I was able to confirm that the CID values were unique.  And, sure enough, when I next applied my configuration to BizTalk Server 2006 everything worked perfectly.

I hope this helps!