I have recently been working on implementing the ESB Portal, and this has been my prime inspiration to start this blog. I’ll get to the reason after a bit of background.
About two years ago, when I was still pretty new to the BizTalk world, I was partnered up with some external consultants on a pretty large project when we had to decide on how to manage exception logging and notification in the integration layer. The options were researched by the external party, and it pretty much came down to using the ESB Portal or to build our own set of orchestrations/schemas/helper classes to help us handle exceptions. The recommendation given to us at the time was to do our own thing because the ESB Toolkit was an unknown quantity and had the potential to blow out the budget for the project since no one knew quite how long it would take to get it up and running.
About 3 months ago, I installed the ESB Toolkit onto my isolated development VM. The entire solution includes a BizTalk Application, supporting web services, a windows service that handles alerts, and a portal site. I found the installation to be quite easy, and I had it up and running in no time. I immediately noticed some pretty strange behaviours on the portal, but at the same time I was very impressed by it, seeing great potential to reduce effort in the handling of exceptions and in implementing retry mechanisms. I felt a tinge of regret that we didn’t implement this during that large project when we first implemented BizTalk Server 2010.
And then I tried installing the portal to our test system….and what a wake up call that was. Forget all the regret I had previously experienced because I very quickly got used to seeing the below image.
- Trust me, you get used to seeing this…and you will grow to hate it.
Unlike my dev environment, the test system is a bit more complicated
- It is a multi server environment with seperate servers for BizTalk and SQL Server
- There are multiple hosts, each running under their own credentials
- Aforementioned host accounts aren’t administrators on the BizTalk Server
- Aforementioned host accounts are in the BizTalk Application Users group rather than in the BizTalk Server Administrators group (and pretty much every other BizTalk group) as they were on my dev machine
- Aforementioned host accounts aren’t sysadmins on the SQL Server Instance
After a lot of scouring the internet, and with a little help from my friends (cue the Beatles) I finally got it up and running. And even when I had it up and running, I realized that it wasn’t secure enough and in my crusade to tighten that up I had to get used to seeing the above error message for another two days.
I now have a great template for a multi server environment, and while it includes elements from quite a few blog posts and Microsoft installation documents, it certainly doesn’t strictly follow the setup as prescribed by any of these parties.
This is why my experience with the ESB Portal has encouraged me to startup this blog; I feel like I have something new (mostly borrowed but new in that it is all in one place) to contribute which I hope will help people. I have a plan to go through quite a few blog posts covering the ESB Portal over the next few weeks and will eventually focus on BizTalk in general. Look out for more posts soon.