Tag: ESB

Known Compatibility Issue between Windows SDK 6.1, VS 2008 Team Suite affects ESB Toolkit 2.0

Overview

As part of my work installing the ESB Toolkit 2.0 on BizTalk 2009 I have been encountering some significant traps in the configuration of VS 2008 Team Suite and ESB Toolkit 2.0.  I have found that it is very important for you to install Visual C++ as part of the VS 2008 install if you want to build the ESB Toolkit locally. This is not a directly expressed dependency in the documentation so this is something to watch out for. On my VMs to preserve space I will typically avoid installing extra features (such as C++, SQL replication, or Books online) that I usually do not need on the applications I work with but I found out the hard way that you should not take the C++ shortcut with the ESB Toolkit.

Another gotcha I have encountered deals with the Windows SDK 6.1. The current version of the ESB Toolkit 2.0 install documentation will refer you the SDK 6.1 download but I think the install originally referenced Windows SDK 6.0A. For all general purposes, the SDK 6.1 is fine but you are recommended to also install a hotfix, http://support.microsoft.com/kb/974479 if you install the SDK 6.1 after having installed VS 2008 SP1.  This hotfix overcomes some of the changes brought with 6.1 that alter the behavior of the SDK 6.0A. VS 2008 itself installs the SDK 6.0A if it is functioning correctly. The problem I experienced was that VS 2008 Team Suite does not work properly after VS 2008 SP1 and this leads to many unresolvable problems.

Detail

The issues I experienced were because VS 2008 Team Suite does not correctly keep track of the installed features after VS 2008 SP1 is installed. The Team Suite installer behaves unpredictably and will not adequately keep track of the extracted files found in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC or C:\Program Files\Microsoft SDKs\Windows\v6.0A.  If I leave C++ checked during the Team Suite install I will usually always need to go back and repair the install after VS 2008 SP1 because some of the C++ components will be missing or the Windows SDK 6.0A files will be missing by the time I try to compile the ESB Toolkit.

One of the problems I experienced included the problem of the VS 2008 Team Suite installer giving the message (similar to problem identified in this thread: http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/2f3d0378-3175-49ae-acb7-012594a1bf3c):

A selected drive is no longer valid.

The install order I took when encountering this issue was:

  • BizTalk prerequisites – W2K8 R1 x64, SQL 2008 R1, SQL 2008 R1 SP1
  • VS 2008 Team Suite with C++ unchecked (SQL express was also unchecked)
  • VS 2008 SP1
  • BizTalk 2009 x64
  • Other BizTalk 2009 installs such as WCF LOB SDK, Adapter Pack, etc.
  • BizTalk 2009 ESB Toolkit Pre-Requisites such as MSChart, VS 2008 SDK
  • Windows SDK 6.1 

Conclusion

Unfortunately, I was not able to come up with a corrective solution for handling this configuration incompatibility. I tried a couple things but was unsuccessful:

  • Install the hotfix 974479 which should resolve most of the problems with the Windows 6.1 and VS 2008 SP1. I was still unable to get the VS 2008 Team Suite installer to work
  • Uninstall the hotfix 974479.
  • Uninstall Windows SDK 6.1 
  • Uninstall VS 2008 SP1

These last attempts certainly show some despiration but I found that once the Windows SDK 6.1 is installed the VS 2008 Team Suite installer seemed to me to always fail. VS 2008 SP1 is a requirement for BizTalk 2009 so I could not choose to avoid this. I recommend avoiding the Windows SDK 6.1 if possible on a computer or VM with VS 2008 Team Suite and SP1 otherwise you may not be able to compile the ESB Toolkit.

Thanks,

0

Using a Named SQL Instance with the ESB Toolkit

Introduction

Lately I have been working on building out some VMs for working with BizTalk 2009/ESBT 2.0 and for BizTalk 2010/ESBT 2.1. I am working on a project that is targeting BizTalk 2010/ESBT 2.1 but there is a feature we would like to use which is currently only compatible with BizTalk 2009/ESBT 2.0. So I am working on managing the feature migration as well as planning for how things will work with BizTalk 2010.

One of the proprietary systems I work with uses a named instance in development for the SQL database and no default SQL instance exists. To keep everything relatively simple I have been installing BizTalk on the same named SQL instance. For most of the BizTalk prerequisites and setup this is straight-forward, but once I start working on the ESB Toolkit there are so many changes to make because the ESB Toolkit samples are all based on a default SQL instance.

It seems that the documentation is quite poor in this regard so I wanted to make a list of the things I have had to change to get a named instance to work properly. I did see Andy Morrison’s article mentioning bits of my content at http://geekswithblogs.net/andym/archive/2010/02/02/137753.aspx but it does not mention all of the relevant items specifically for a named instance. Some of the items listed below are steps done before the ESB Toolkit itself but I am including them here for completeness.

Pre-Requisite Setup

  • Install SQL using a named instance
  • Configure BizTalk using the named instance. Most of the steps in the wizard will work automatically(if SQL is local) but the BAM Tools lines for BAM Analysis and BAM Star Schema databases will still require you to manually enter the named instance information.
  • The UDDI configuration wizard will pick up the named instance automatically (if SQL is local) so no extra work here.

ESB Toolkit Setup

  • During the ESB Toolkit Configuration Tool you will need to specify the name of the named instance. If SQL is local you can use “.\<instance name>”.

ESB Toolkit Management Portal Setup

  • Edit the web.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.Portal
  • Edit the App.Config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.UDDI.PublisherService
  • Edit the web.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.Exceptions.Service\ESB.Exceptions.Service
  • Edit the App.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.Exceptions.Service\ESB.Exceptions.Service.Implementation
  • Edit the web.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.BAM.Service\ESB.BAM.Service
  • Edit the App.config in c:\Projects\Microsoft.Practices.ESB\Samples\Management Portal\ESB.BAM.Service\ESB.BAM.Service.Implementation
  • Edit the App.config in C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.AlertService
  • Open the ESB.Portal solution in C:\Projects\Microsoft.Practices.ESB\Source\Samples\Management Portal\ESB.Portal and do a find on “data source=” to find a few other locations where the default SQL instance is used with Entity Data Models and other files
  • Open the ESBFunctions.ps1 file in C:\Projects\Microsoft.Practices.ESB\Source\Install\Scripts and search for “sqlcmd” to find places where SQL is being called using the default instance. I did a find/replace on “sqlcmd” and replaced it with “sqlcmd -S .\<instance name>” because my named instance was local. You can enter something different if your named instance is remote.

As you can see, there are so many different places that must be changed in order to use the ESB Toolkit with a named SQL instance. This list holds true for both BizTalk 2009 and BizTalk 2010.

Thanks,

1

ESB Toolkit 2.0 Configuration Tips

I have been working more and more with the ESB Toolkit 2.0 but occasionally run into issues where samples do not work or there are other miscellaneous errors. Here are a couple of my tips for common errors I have encountered while using the toolkit. All of these suggestions have been things I have done for a single BizTalk server installation. Through the forums some people have mentioned you should do different things for a multi-server BizTalk install.
 
I. Bad Request 400 Errors
 
I received this error quite a bit when first configuring the ESB Toolkit 2.0 on the ESB Portal page. This error is really not descriptive of the root problem. To resolve this issue I did the following steps:
  1. On the default web site or the one which hosts your ESB Portal, enable windows authentication.
  2. Stop iis, w3wp.exe (World-wide web service)
  3. Run the following commands to enable credential negotiation:
    cd “c:\inetpub\adminscripts”
    cscript.exe adsutil.vbs set w3svc/NTAuthenticationProviders “Negotiate,NTLM”
  4. Restart iis, w3wp.exe.
  5. To check this, open c:\windows\system32\inetsrv\metabase.xml and then search for NTAuth to see if it is just “NTLM” (which is the wrong value) or “Negotiate,NTLM” which is the correct value.
  6. To get the portal to work again, uninstall the management portal using the powershell script and then reinstall it. The script is found at C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\ESBSource\Source\Samples\Management Portal\Install\Scripts\Management_Install.cmd
Also, I found that if you install the UDDI components from BizTalk 2009 this will remove the credential negotiation from the IIS setting set above so you will need to redo the steps above after the UDDI install is run.
 
II. The BizTalk 2009 UDDI tools fail to connect to the UDDI registry. Here is one of the errors I was getting:
 
Event Type: Error
Event Source: UDDIRuntime
Event Category: Config
[[Error reading configuration settings:
Unable to read the Database.WriterConnectionString or Database.NotificationConnectionString configuration setting.]]
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
This problem happened to me when trying to use some of the UDDI samples in the ESB toolkit. I could also not use the UDDI website or the UDDI management tools except the UDDI management console. The root of this problem was that there was an authentication issue. Here is what I did to resolve it:
  1. Open the UDDI management console.
  2. Right-click on the UDDI item in the treeview and click Properties…
  3. Go to the Security tab and choose “Windows integrated publisher authentication” rather than the mixed mode default setting of Windows integration and UDDI publisher authentication.
  4. Click OK. Here is a photo of the setting page:

III. The Registry tab of the ESB Management Portal gives you an error. This occurs because the UDDI built-in tModels have not been loaded yet into the UDDI registry site. To resolve this issue, do these steps:
  1. To check if the tModels exist on your UDDI server, open http://localhost/uddi, and click on the Publish tab. This will open a split frame page with a treeview on the left. If you do not see the microsoft-com:esb:runtimeresolution items, then you need to do step 2. Here is a picture of the tModels in the UDDI site:

    2. Run the following command:
           cd “c:\program files\microsoft biztalk esb toolkit 2.0\bin”
           Microsoft.Practices.ESB.UDDIPublisher.exe”

    3. This will install the ESB tmodels into UDDI. Hit refresh or do an iisreset and refresh the page to see the tModels.  

IV. The Resolver service sample does not work. Here is one of the errors I got:
 
Event Type: Error
Event Source: BizTalk ESB Toolkit 2.0
The HTTP request is unauthorized with client authentication scheme ‘Negotiate’. The authentication header received from the server was ‘NTLM,Basic realm=”localhost”‘.
Service: ResolverService
Method: Resolve
Error Id: ce981d9c-3745-45d1-bf98-f4cea7ef89b8
Error Source: mscorlib
Error TargetSite: Void HandleReturnMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessage) 
Error StackTrace:
Server stack trace:
   at System.ServiceModel.Channels.HttpChannelUtilities.ValidateAuthentication(HttpWebRequest request, HttpWebResponse response, WebException responseException, HttpChannelFactory factory)
   at System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory factory, WebException responseException)
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Microsoft.Practices.ESB.UDDI3.UDDI_Inquiry_PortType.get_bindingDetail(get_bindingDetailRequest request)
   at Microsoft.Practices.ESB.UDDI3.UDDI_Inquiry_PortTypeClient.Microsoft.Practices.ESB.UDDI3.UDDI_Inquiry_PortType.get_bindingDetail(get_bindingDetailRequest request)
   at Microsoft.Practices.ESB.UDDI3.UDDI_Inquiry_PortTypeClient.get_bindingDetail(get_bindingDetail get_bindingDetail1)
   at Microsoft.Practices.ESB.UDDI3.UddiClient.GetBinding(String bindingKey)
   at Microsoft.Practices.ESB.Resolver.UDDI3.ResolveProvider.<>c__DisplayClass4.<CreateSearch>b__0()
   at Microsoft.Practices.ESB.Resolver.UDDI3.ResolveProvider.ResolveUddi(String config, String resolver, String keyPrefix, Dictionary`2 resolutionOrig)
   at Microsoft.Practices.ESB.Resolver.UDDI3.ResolveProvider.Resolve(String config, String resolver, XmlDocument message)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve(ResolverInfo info, String message)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.ResolveFromService(String config, String message)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.ResolveEndpointWithCache(String config)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.ResolveEndpointWithCache(Dictionary`2 resolverCache, Object resolverCacheSyncRoot, String config)
   at ResolverService.Resolve(String configuration)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
To resolve this error, I did:
  1. Open ResolverService.svc’s web.config
  2. Set proxyCredentialType in config to Windows, new values shown below:

      <transport clientCredentialType=”Windows” proxyCredentialType=”Windows” />

     3. In the test client, modify the web.config transport security to use clientCredentialType of Windows and a proxyCredentialType of Windows, new values shown    below:

     <transport clientCredentialType=”Windows” proxyCredentialType=”Windows realm=”” />

This is tip is partially based on this blog post: http://www.kodyaz.com/blogs/software_development_blog/archive/2008/02/25/849.aspx 

Thanks,

2

ESB Toolkit 2.0 Limited Deployment

The ESB Toolkit 2.0 install is still a painful process and I have often asked if there was an easier way to do it to get more out of it. Use of the ESB pipeline components is particularly helpful in some situations but it is a little annoying to go through all of the ESB Toolkit setup steps just to use the pipeline components. So I think I have found a usable workaround. On a recent project I was using one of the ESB Toolkit 2.0 pipeline components for removing a namespace from an Xml file, but I decided to try an limited deployment of the ESB Toolkit 2.0.
 
I found that it is possible to do an limited deployment of assemblies for the pipelines as long as all of the dependent assemblies can be found. I recognize this is not an ideal or officially supported configuration but I found it to be a much quicker deployment. Obviously you cannot take full advantage of the ESB Toolkit’s features if you do not install everything but if you happen to just need to use one of the pipeline components then this post should enable you to be successful quickly.
 
Here are the basic steps of what I describe as a limited ESB deployment:
  1. Build all BizTalk projects with custom pipelines using the ESB Toolkit components
  2. Copy all compiled BizTalk assemblies and referenced ESB assemblies to the BizTalk pipeline components folder (usually C:Program FilesMicrosoft BizTalk Server 2009Pipeline Components)
  3. GAC all compiled BizTalk assemblies and referenced ESB assemblies
  4. Add BizTalk assemblies and ESB pipeline component assemblies to relevant BizTalk application
To determine all of the dependent assemblies for an assembly, I open it in Reflector and then expand the references item. This shows the immediate references and lets you drill deeper from there into references of references. This is a handy way to get a quick list of dependent assemblies. To save you the time of doing this again for the ESB Toolkit, here are the referenced assemblies for the ESB Toolkit 2.0 pipeline components. You can just copy and paste these to rapidly deploy the ESB pipeline components with your BizTalk assemblies:
 
Pipeline Component assembly: Microsoft.Practices.ESB.Namespace.PipelineComponents
 
Referenced Assemblies:
Microsoft.Practices.ESB.Utilities
Microsoft.Practices.ESB.GlobalPropertyContext
Microsoft.Practices.ESB.Itinerary.Schemas
Microsoft.Practices.ESB.ExceptionHandling.Schemas.Faults
Microsoft.Practices.ESB.Exception.Management
 
By just deploying a small number of the ESB Toolkit 2.0 assemblies I was able to take advantage of the really handy functionality provided with the Toolkit without spending a considerable amount of time getting the toolkit installed and configured.
 
Thanks,
4

BizTalk 2009 Roadshow in Chicago

On December 4th I will speaking on the ESB Toolkit 2.0 under the topic "Improving Business Agility with an Enterprise Service Business" This roadshow is actually going to be happening in 20 cities across the world. The roadshow is a morning series of keynotes followed by some food.
 
 
Please join me at this free event!
 
Thanks!
1

BizTalk Server 2009 Public Beta Released Today

Today Microsoft released the public beta of the next version of BizTalk, BizTalk Server 2009 and it is available for download at the Microsoft Connect site – http://connect.microsoft.com/site/sitehome.aspx?SITEID=218. The latest version of the Microsoft ESB Guidance was also released at the same time and is available at the same CodePlex location – www.codeplex.com/esb. There are quite a few updated BizTalk features with this release and I will be showcasing some of these features in the next couple days.
 
There were a couple of installation gotchas that I noticed initially with BizTalk 2009. I worked with BizTalk 2009 during the Microsoft TAP program a few weeks ago and have already installed it once. The 2009 TAP install did not require you to run Visual Studio 2008 SP1 but the new BizTalk release does require this so be sure to do this before running the installer. The 2009 install will add the Visual Studio extensions to Visual Studio 2008 so that you can now include your .NET 3.5 projects right alongside BizTalk projects.
 
The developer tools will not be enabled as an install option without Visual Studio 2008 SP1. Since BizTalk 2009 is in beta you will want to report any issues to Microsoft as part of the feedback link on the BizTalk 2009 connect site or report it at the MSDN forums under BizTalk – http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1470&SiteID=1.
 
The ESB Guidance no longer includes JMS features so you if you have been using JMS subscriptions with the ESB Guidance, do not upgrade at this time if you want to continue using JMS.  
 
Thanks,
0

Blog at WordPress.com.

Up ↑