BizTalk 2006 R2 SP1 WCF Extensions

A few days ago a service pack for BizTalk 2006 R2 (known as BizTalk 2006 R2 SP1) was released and¬†it includes a large number of rollup fixes accumulated from quite a few hotfixes. I ran it on my local development box and it installed fine for the most part. It did do have a hickup on HL7 though. It also includes some new product features which is a little unusual for a service pack release. Perhaps it should be called BizTalk 2006 R2.5. ūüôā
 
 
One of the major new product features in the service pack is better tooling around WCF extensions. This post is going to give an introduction on how this worked prior to the service pack, then go through a brief tutorial of how I tested the new functionality. This post is based on SP1 beta so it is subject to change.
 
Prior to SP1:
 
If you implemented a WCF extension prior to SP1 then you had to go through a considerable amount of complexity to get the extension to show up in the BizTalk WCF port configuration pages. I retraced Richard Hallgren’s steps in his post http://www.richardhallgren.com/category/wcf/ as a good example of getting an WCF extension in the form of an EndpointBehavior. The relevant steps I want to focus on are:
 
  • Develop the extension behavior
  • Add a line similar to machine.config:
    <add name="addCustomWCFProperties" type="CustomWCFProperties.Behavior.PromoteUserNameBehaviorElement, AddCustomWCFPropertiesBehavior, Version=1.0.0.0, Culture=neutral, PublicKeyToken=705e34637fdffc54" />
  • Configure the WCF port and choose the behavior.
The difficulty with this approach is that for every custom behavior (which might be used on a per port basis), you have to put stuff in machine.config. In most server environments this can require moving mountains to edit machine.config. Also, if you use behaviors on many ports it can quickly become difficult to manage. SP1 limits the scope of the config item to the executing host but it also introduces a couple challenges of its own. 
 
With SP1:
 
The current SP1 approach is to configure config options using a tab on the adapter handler properties. The directions are given for the custom send handler here:
 
Basically what is involved is importing a config file that has the custom behavior defined. The SP1 beta documentation mentions this as a custom binding but it means the custom behavior. Here is a screenshot of what the page will look like after SP1 is installed:
 
 
Then here is what the page looks like after you have imported a custom extension:
 
This current documentation does not provide a template or starting point for what the imported config file should be so there is essentially a gap. What I did was try to use the machine.config from the Pre SP1 directions because I thought this is the most direct route that people are likely to do after they run SP1. A better approach would be to use the template I have at the bottom of this post as a starting point for the config file you import.
 
Unfortunately the process is more complicated using machine.config because there are extra nodes in the machine.config that the import config button does not like.
You will get errors like:
 
—————————
Import WCF configuration
—————————
Unable to import configuration from file "C:Documents and
SettingsbencDesktopmachine.config".(System.Configuration.ConfigurationErrorsException) It is an
error to use a section registered as allowExeDefinition=’MachineOnly’ beyond machine.config.
(C:Documents and SettingsbencLocal
SettingsTempConfig73d27aa8-b21b-4d47-abeb-c81ec7a756fc.config line 202)
So if you want to go this route, follow these steps to clean the machine.config to the point that the page imports the config file properly. These steps are subject to what is in your machine.config. Also, I am not sure if any of these steps will have any undesired consequences and you should use these steps at your own risk. But these worked for me:
 
  • Copy your machine.config and work on the copy
  • Find all attribute occurences of allowExeDefinition="MachineOnly" and remove this attribute
  • Remove the commonBehaviors ConfigSection and Config elements and children
  • Remove the machineSettings ConfigSection and Config elements and children
  • Find behaviorExtensions element below <system.servicemodel><extensions> and remove all of the existing ones except for your custom ones.
Then try to import again and it should work. The screen will look exactly alike to the picture Richard Hallgren had for choosing the custom behavior, you just took a different path. The custom WCF extension behavior is the first in the list shown below:
 
 
I am guessing that the import config button is trying to merge part of the imported configuration into some master configuration and this is why it is failing. If you try to import a config file that does not cause errors and does not have any extensions, you will not get a message back that nothing was imported, the text box just stays blank.
 
You will then be able to select the custom behavior for a port running under the handler where you imported the config file.
 
I have found that it is actually possible to import the same config file multiple times across multiple handlers so this means it is possible to have one WCF extension configured for multiple BizTalk hosts.
 
Once you get through the wizard you can then export the WCFExtensions config file which gives you a template for the future that I have included here (not sure why the ESB line exported here):
 
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <enterpriseLibrary.ConfigurationSource selectedSource="ESB File Configuration Source" />
  <system.serviceModel>
    <behaviors>
    </behaviors>
    <extensions>
      <behaviorExtensions>
        <add name="addCustomWCFProperties"
type="CustomWCFProperties.Behavior.PromoteUserNameBehaviorElement, AddCustomWCFPropertiesBehavior,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=705e34637fdffc54" />
      </behaviorExtensions>
    </extensions>
  </system.serviceModel>
</configuration>
 
Here is a link to my exported .config file (shown above)¬†that I used to successfully import Richard Hallgren’s
 
Hopefully the documentation will improve in the final version of BizTalk 2006 R2 SP1.
 
Thanks,

VS 2010 Beta 2 Out Publicly

I have been working with VS 2010 quite a bit since the CTP about five months ago. The most recent release is Beta 2 and it was dropped onto MSDN for subscribers back on Monday. Today it rolls out for public consumption:
 
 
I am still working on getting a version of VS 2010 Beta 2 completely installed. I have had 2 failed installs at this point. Here are a few gotchas to watch out for:
 
  • Start with a fresh VPC or system – make sure no previous version of VS 2010 existed on the computer previously
  • Be sure to budget enough time for the install to run – perhaps 4-6 hours. I did a save state on my VPC in the middle and this caused the install to fail in the middle.
  • If any of the features fail, they do not show up in the Add/Remove programs checklist – you would need to start a fresh install.
  • Uninstall is not working completely so this does not provide an option to back out if you get an error or have to stop in the middle.

I have reported a couple bugs already, and if you find any, be sure to report them at:

https://connect.microsoft.com/VisualStudio/content/content.aspx?ContentID=14631

Thanks,

More BizTalk 2009 Install Guide Info Updates

I checked in the Windows Server 2008 English BizTalk 2009 pre-requisites redistributable and it DOES now include the ADOMD v10 install. Yahoo!
 
So after exploring the new information available on BizTalk 2009, I noticed that the whole SQL Server Notification Services documentation story has been updated dramatically. I had posted a few days ago about how the link from the 2009 Beta install guide for SSNS went to a version from SQL 2005 RC1 did not provide enough files and resulted in lots of errors. Now the documentation sends you to a Microsoft support site where you can download the missing SQL dependency files (SMO among them): http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=953752. This should be a huge improvement Рthis should enable BAM Alerts to work without needing to install a secondary SQL 2005 instance. The result of my configuration research shows there is more than one supportable configuration for using SSNS Рeither as a scaled down version or on a separate SQL 2005 instance.
 
For the last couple of months I have been playing with BizTalk 2006 R2¬†on Windows Server 2008 and SQL 2008 to get a better understanding of software compatability between these products. I had posted on the gap of information about what server roles and features would be necessary to use BizTalk in a Windows Server 2008 environment. Fortunately, the recently released BizTalk 2009 install guide for Windows Server 2008 does mention the required roles and features for Windows Server 2008 under the section describing what should be installed with IIS.¬†The install guides have now been split up by OS, but there is unfortunately not one for installing onto Windows 7 – perhaps we will have to wait for this to be released later. ūüôā
 
It looks like the updated documentation does not include any mention of the two separate BizTalk 2009 RFID install images – one bundled with the BizTalk server software, and one as a separate ISO. The separate ISO has a lot more samples on it so be sure to get the separate ISO too. Both are available on MSDN.

BizTalk 2009 RTW (Release to World)

I just found out that the BizTalk 2009 release has been extended to the general public: http://seroter.wordpress.com/2009/04/27/quick-thoughts-on-formal-biztalk-2009-launch-today/. I have been posting on various issues with the RTM version. It looks like the 2009 install guides can now be found at

http://go.microsoft.com/fwlink/?LinkID=128383 Рthe link was reset and it connects successfully. Additionally, the install guides now mention ADOMD v10 so please stop using the Beta install guide Рit has now been replaced. I will be posting here soon about whether the updated prerequisites CAB includes ADOMD v10 and some other details I have been working on from the RTM version. Interestingly, the MSDN downloadable version is still from 4/6/09 (when the RTM release occurred) so it does not look like there has been an updated build; just updates of the supporting files.

If I notice anything in the install guides or the other support files, I will be sure to post about it here.

Thanks,

BizTalk 2009 RTM Install Guide Missing

For anyone that is downloading the BizTalk 2009 RTM from the MSDN downloads, you may have found that the Installation Guide.htm on the image refers to http://go.microsoft.com/fwlink/?LinkId=128383, which is the location of the BizTalk 2006 R2 guides. This link should be updated soon. As far as I know, no new installation guide has been released yet so your best guide is the 2009 Beta install guide download from https://connect.microsoft.com/site/sitehome.aspx?SiteID=218.
 
Once I hear about a new version of the install guide I will post more about this. Good luck to everyone trying out BizTalk 2009 RTM.
 
Thanks,

BizTalk 2009 RTM

Well I guess I missed the launch party РBizTalk 2009 is now available for MSDN subscribers. I reported a lot of bugs during the BizTalk 2009 Beta and TAP releases so it will be interesting to see if people encounter any of these. Thanks to my friend Thiago Almeida for pointing out the ADOMD 10 error (http://connectedthoughts.wordpress.com/2009/04/06/biztalk-2009-rtm-prerequisites/). I had seen this during the TAP version and unfortunately it looks like a final bug.
 
The following screenshot shows what you will see if you install BizTalk 2009 in an environment with SQL 2005:
 
This error is due to the installer needing the SQL 2008 version of ADOMD, v10. I have downloaded ADOMD v10 from SQL 2008 and run it on a SQL 2005 instance to get the BizTalk 2009 installer to work. Hopefully this will be resolved soon. There may be a couple of other issues out there too.
 
It is exciting to see the launch of the new product and it will be exciting to see people talking about this new version of BizTalk!
 
Thanks!

BizTalk Dream Machine

I have been playing with the new features of BizTalk 2009 and have been finding a few bugs. But some of what is available with this release is awesome. For example, due to Visual Studio 2008 integration you can reference a WCF Service library from your BizTalk project. You can also reference a project that uses LINQ so will be able to use LINQ indirectly in a BizTalk map. Another cool thing is that you can reference a WF library from your BizTalk project. This makes it possible to call a WF method directly from BizTalk and potentially move logic over to a WF process from BizTalk. I have not tried running a workflow from the BizTalk host but that will be the next thing to try. I have not seen any new BizTalk orchestration shapes for calling WF activities or workflows either.
 
The new UDDI functionality included with the BizTalk 2009 beta is a little buggy at this point but the functionality seems to be a big step forward. More details on this soon.
 
Lots of the wish list ideas I have had for where BizTalk could be going are things I am testing right now. Check back here as I find new features as part of the beta.
 
Thanks,

Major BizTalk Incompatibility – IIS 7 and WCF Publishing Wizard

On my current project the client has been dabbling with BizTalk 2006 R2 in a very unsupported configuration with Windows Server 2008, and SQL 2008. In previous posts I talked about Windows Server 2008 and some challenges installing BizTalk on this OS. Generally, Windows Server 2008 behaves well for BizTalk. SQL 2008 has behaved well and has not presented any problems for BizTalk other than the fact that it does not include Notification Services so you must install this optional component from the installer included with SQL 2005. This post describes some new difficulties I have identified when using BizTalk Server 2006 R2 with IIS 7.
 
Working in the unsupported environment has been very interesting because it has identified that there are issues with BizTalk’s WCF integration on Windows Server 2008. Windows Server 2008 includes IIS 7 which has been overhauled extensively. Several issues have been identified with IIS 7 and BizTalk Server 2006 R2:
 
– It is possible to run the BizTalk WCF Publishing Wizard through completely to create a .svc WCF endpoint and a virtual directory to host the WCF service but by default IIS 7 is not configured to support the .svc extension. In order to setup the .svc extension, use the IIS 7 directions at http://msdn.microsoft.com/en-us/library/ms752252.aspx.
 
– When running the BizTalk WCF Publishing Wizard sometimes IIS 7 will get dumped out completely. From time to time running the wizard the web.config at c:\Inetpub\wwwroot and all of the virtual directories in this folder get removed during the time that the WCF Publishing wizard is running. For this reason, I strongly recommend you backup the web.config in the web root and all virtual directories stored under the web root before running the WCF Publishing wizard on a box that includes IIS 7. If you just registered the .svc handler and IIS 7 gets dumped out you will need to create it again. Due to this issue, I also strongly recommend that if you need to work with HTTP or IIS related adapters, use Windows Server 2003 R2 with IIS 6 rather than Windows Server 2008 with IIS 7.
 
– The BizTalk WCF Publishing Wizard may require additional permissions when run on Windows Server 2008 than on Windows Server 2003 due to the secure by default nature of IIS 7. I identified issues with the NetMSMQ binding and MEX-only endpoints created with the BizTalk WCF Publishing Wizard in which permissions must be loosened while the wizard is running although they may be tightened afterwards.
 
Thanks,
 
 

Variation on WSS Adapter Error & Workaround

On my current project I was working to configure the WSS adapter for BizTalk on a separate server than BizTalk. This requires running the BizTalk installer on the SharePoint box and then running the BizTalk Configuration Wizard to setup the WSS adapter web service. I was running the configuration wizard and was just using the defaults and received the following error:
 
d:depot2300mercuryprivatekwsourcebizofficecodebizofficeconfigurationwssadacfgwssadacfg.cpp(467): FAILED hr = 80070002

This is a similar error to the one reported at https://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3350889&SiteID=17 but I identified a different workaround that did not require an updated DLL from Microsoft. Rather than use "Default Web Site" as the application where the WSS adapter web service should be installed, I used an already existing web site such as "SharePoint Р80". This enabled me to install the WSS adapter successfully.
 
While discussing this issue I wanted to mention that the WSS adapter configuration instructions at http://msdn.microsoft.com/en-us/library/aa547280.aspx mentioned that you needed to install "Windows SharePoint Services SP2" but this refers to WSS 2 SP2 and is not required if you currently have WSS 3.
 
Thanks,

BizTalk WCF Receive Adapters Wrap SOAP Body Content

On a recent project I was exposing a BizTalk orchestration as WCF for a Windows Forms client and a Windows Mobile client. For simplicity, a single BizTalk receive port was being used with multiple WCF receive locations. The BizTalk WCF publishing wizard allows this type of functionality through running of this wizard more than one time. This is by far one of the coolest WCF capabilities in BizTalk – the ability to expose multiple bindings (like you can do in WCF) for each BizTalk orchestration. For example, one BizTalk orchestration can be exposed for both a WCF-BasicHttp binding and a WCF-NetMSMQ binding through running the WCF publishing wizard twice, once choosing to publish a service endpoint for the WCF-BasicHttp binding, and then a second time as a Meta-data endpoint (MEX) for the WCF-NetMSMQ binding.
 
The message body properties for both of these receive locations was set to "Body" which is supposed to pull out the contents of the SOAP:Body from the WCF service call. When testing both of these bindings the contents of the SOAP:Body were being output but they were being wrapped in a part element like in the message given below:

<part i:type="a:string" xmlns:i="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:a="http://www.w3.org/2001/XMLSchema">Hello World!</part>
 
The application that was being implemented was one in which the body data needed to be passed along intact and not further wrapped. The MSDN documentation on the Message Body properties (http://msdn.microsoft.com/en-us/library/bb226478.aspx) did not mention that additional data would be passed along to wrap the content that was passed to the WCF receive location. The additional part element caused problems with the next system to receive the message. So I used the Path option rather than Body for the message body and used the XPath expression of /*[local-name()=’part’] to remove the additional wrapping of the data. This provided what I would expect to be included in the body part of the SOAP:Body – the data passed to the WCF operation and nothing more.
 
This tip should help you avoid one challenge of working with the new WCF features of BizTalk. Thanks!

Blog at WordPress.com.

Up ↑