So, I haven’t really been doing much with BizTalk for a while now, spending more time on traditional development activities and working on some WCF specific solutions. However, I have recently been investigating SOA implementations in more detail, in particular the ESB (Enterprise Service Bus) along with how and why you would want one of these in your organisation.
This has led me neatly back into the BizTalk space. I had actively perused opportunities away from BizTalk, not necessarily due to the fact that I didn’t like working with the product, but more for the desire to get back into pure development like I used to. Hey, it’s nice to have a change every now and again. Now this particular task I am undertaking at the moment is purely focused on Microsoft technologies; I know there are numerous ESB offerings out there from various vendors. So this has led me to the BizTalk 2009 ESB Toolkit 2.0 from a product perspective and looking into some of the enabling future technologies such as WCF/WF 4.0 and the Microsoft Application Server Extensions codenamed “Dublin”.
Well, without going into the details of an ESB as there is a wealth of conflicting information out there already, I decided that simply reading about BizTalk 2009 ESB Toolkit would not be sufficient so with a little trepidation I decided to install BizTalk 2009 and the ESB Toolkit onto a VM for testing. I say with trepidation, as I have spent a huge amount of time in the past installing, configuring and generally thumping my head against a heavy object in frustration at the difficulties of getting BizTalk working as expected. However, being a local development install and therefore not having the security locked down that is often the biggest inhibitor to an easy deployment, I was somewhat more optimistic.
Anyway, before I decided to plough away at the install I thought it would be prudent to check whether anyone has had experienced difficulties and/or provided some steps to get going quickly; I didn’t want to spend too much time on this activity. So it was with gratitude that I came across this great post by Preetham Reddy. By following these steps I was up and running pretty pain free. I say “pretty” pain free, as I did have one issue that I thought I would make a note of here in case anyone else comes across the same problem.
Now, during the configuration steps there is a part where you need to run ESBConfigurationTool.exe to configure the settings for exception management, the ESB core components and configuration nodes. While trying to apply the configuration to any of the databases I would receive an error relating to not being able to create the database. I was logged in as an administrator and I thought this odd, so decided to simply create the databases via SQL Server Management Studio. I ran the configuration again and everything seemed to work fine.
I completed the rest of the installation and when i went to browse the ESB Management Console I was presented with the following error: “An unhandled exception has occurred”. “Great” I thought, here we go again, difficulties getting things installed and configured with BizTalk. Looking at the Windows Event Viewer I saw the following entries:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 15/10/2009 18:35:20
Event time (UTC): 15/10/2009 17:35:20
Event ID: 77d00134a17e42519d7c6a11e26ce9d2
Event sequence: 13
Event occurrence: 4
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/1/ROOT/ESB.Portal-1-129001012513866430
Trust level: Full
Application Virtual Path: /ESB.Portal
Application Path: C:\Program Files\Microsoft BizTalk ESB Toolkit 2.0\ESBSource\Source\Samples\Management Portal\ESB.Portal\
Machine name: MyMachine
Process information:
Process ID: 4584
Process name: w3wp.exe
Account name: MyMachine\Administrator
Exception information:
Exception type: WebException
Exception message: The remote server returned an error: (400) Bad Request.
Request information:
Request URL: http://localhost/ESB.Portal/Default.aspx
Request path: /ESB.Portal/Default.aspx
User host address: ::1
User: MyMachine\Administrator
Is authenticated: True
Authentication Type: NTLM
Thread account name: MyMachine\Administrator
Thread information:
Thread ID: 12
Thread account name: MyMachine\Administrator
Is impersonating: False
Stack trace: at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
Nothing particularly useful there I thought. So I eventually ended up attaching a debugger to the web application and noticed the code was having trouble retrieving data. This is when I remembered the oddity from the configuration so checked the database to see there were no tables, views, stored procedures or anything within them. So I ran through the configuration with ESBConfigurationTool.exe again, but still nothing. I then deleted the databases it had created to see if it would actually create them this time, which it did. I then went back to the ESB Management Console site and viola, there it was.
So, I am a little confused why the tool could not create the database the first time, but did the second time. Anyway, this may be useful to someone out there. My thoughts on the whole install and configure process so far is that it is too laborious and error prone, as I half-expected. I want to be able to do one-click deployment, is that too much to ask these days? Perhaps this is the remnants of it being developed externally from the product, but nevertheless it isn’t a great experience for those considering using this on an enterprise-scale project is it?
Anyway, back to my investigations