BizTalk Server 2004/2006

BizTalk Server 2009 - Rule deployment issue

Charles Young — Fri, 20 Nov 2009 13:28:40 GMT

There is a small configuration issue with the Microsoft Business Rules Composer in BizTalk Server 2009. This will only affect you if you deploy the rules engine by itself without the rest of BizTalk Server. In a full installation of BizTalk Server, BTS provides a set of BTS-specific Rule Framework components in as assembly called Microsoft.BizTalk.RuleEngineExtensions. This includes a RuleSetDeploymentDriver component that manages deployment of rules via the SQL Server repository.

The BTS-specific RuleSetDeploymentDriver has a dependency on WMI (Windows Management Instrumentation). In a full BTS installation, BTS creates an instance of a CIM class called MSBTS_GroupSetting and populates various property values from the BizTalk management database. This includes the assembly and class name of a RuleSetDeploymentDriver. If you install only the rule processing components, there is no BizTalk management database, and no instance of this class is created. Unfortunately, this means that, whenever you try to deploy a rule set from the Rules Composer, you get a rude message saying:

The database "<server>:<database>" associated with the deployment driver does not match the database ":" specified during product configuration

The message is entirely correct. Microsoft's BTS-specific RuleSetDeploymentDriver component performs this check presumably to ensure that registry settings for the rule repository database name and server name are identical to those configured in the BizTalk management database. This ensures that the Rule Engine Update Service is using the same BTS-specific RuleSetDeploymentDriver component.

When you install only the rule processing components, the registry is unfortunately configured as if a full BizTalk installation had been done. The Rule Composer tries to use the BTS-specific RuleSetDeploymentDriver component to deploy rule sets and fails because no instance of MSBTS_GroupSetting has been created in the CIM store.

Fortunately, this is a simple problem to fix. Microsoft provides a non BTS-specific RuleSetDeploymentDriver component for the rule repository database. All you need to do is change the registry settings to use this instead.

Open the Registry Editor (regedit) and locate the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0

If you have installed the rule processing components on a 64-bit version of Windows, they key will be at:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\BusinessRules\3.0

You should find the DeploymentDriverAssembly and DeploymentDriverClass values under the key. These should be changed to the following values, respectively:

Microsoft.RuleEngine, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.RuleEngine.RuleSetDeploymentDriver

That's it. The Rule Composer should now be able to deploy rule sets.

BizTalk Server 2006 R2 - Service Pack 1 announced

Charles Young — Fri, 09 Oct 2009 18:36:14 GMT

Microsoft today announced Service Pack 1 for BizTalk Server 2006 R2. Note that this is for the previous version of BizTalk Server, not the current version (BizTalk Server 2009). No doubt a service pack for BTS 2009 will follow in due course.

The service pack is currently at beta. It has only been announced, not released. You can download the beta if you log onto the Connect site.

See http://blogs.msdn.com/biztalkcrt/archive/2009/10/09/announcing-biztalk-2006-r2-sp1.aspx

There are a couple of new features. See http://msdn.microsoft.com/en-us/library/ee532481(BTS.20).aspx.

For a list of bug fixes, see http://support.microsoft.com/kb/974563.

BizTalk Server: ESB Toolkit 2.0 Released. UDDI issues fixed?

Charles Young — Tue, 09 Jun 2009 12:42:33 GMT

Yesterday, Microsoft released the final version of ESB Toolkit 2.0 (the word 'Guidance' has been dropped) which you can download from http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=bc86cf1e-ef29-4b19-95f7-388f64555090#tm. I have had half an hour today to look at the documentation. A preliminary read seems to suggest that, between the release of the CTP and the final release, Microsoft scrapped the old UDDI resolver and have introduced a completely new version that complies with the UDDI standards and which addresses the issues raised in a blog article which I published earlier this year. See http://geekswithblogs.net/cyoung/archive/2008/11/12/126975.aspx. However, please be aware that I need time to properly digest the functionality changes, and won't be able to do that for another week or so. I will report back when I have had more time to investigate.

Biztalk 24x7 - new version goes live

Charles Young — Thu, 21 May 2009 21:55:02 GMT

Saravana Kumar has just re-launched BizTalk 247.com (see http://www.biztalk247.com) with lots of new content and a new layout, look and feel. Look very quickly and you might just spot that awful photo of me on the home page! The one with the bright purple tie and a dark blue shirt. What was I thinking? Oh well, no-one said that being a BizTalk user equated to being cool. And I desperately needed a haircut.

Anyway, congratulations to Saravana. This is a really useful single stop shop for BizTalk resources. Lots of videos (including a couple with me waving my hands around like a manic thing) and links to various widgets, featured books and guides and tons of other stuff. Saravana has also worked hard to ensure that URLs to various resources on the site are short and to the point so that you easily find what you are looking for. Mind you, being a point & click man, myself, I think the site is very easy to navigate anyway.

Microsoft Presentation on CEP and BizTalk

Charles Young — Thu, 21 May 2009 14:23:57 GMT

After publishing the article on CEP on the Microsoft platform a couple of days ago ( see http://geekswithblogs.net/cyoung/archive/2009/05/18/cep_explained_for_biztalk_users.aspx), I was reminded of an excellent presentation given by my good friends John Plummer and Jeff Johnson at the Microsoft Architect Insight conference in 2008. John and Jeff both work for Microsoft in the UK. They used NEsper (the .NET port of the open source Esper event processing engine) to demonstrate how CEP might be used in conjunction with BizTalk technologies. I dug out the slides and reminded myself of their presentation. All very good stuff. the slides are at:

http://download.microsoft.com/documents/uk/msdn/events/SOL/SOL08.pptx

BizTalk Server: On app pools and isolated host instances

Charles Young — Fri, 08 May 2009 01:53:52 GMT

I dealt with an interesting, if arcane, issue today at a client's site. The client is in the process of deploying an early version of a BizTalk application to their test environment for the first time. The test environment is hosted by another company, and BizTalk Server 2006 R2 had been installed and configured by that company. They are using the 64 bit version on Windows 2003 R2 with SP2. The BizTalk application publishes a WCF endpoint, hosted in IIS6.

The hosting company has quite correctly created a set of domain accounts and groups and configured BizTalk to use these. Unfortunately, when doing the initial deployment yesterday, we didn't have, and couldn't get, the password for the configured BizTalk Isolated Host user account. We did, however, have the password for another domain account, and we were able to add that account to the BizTalk Isolated Host Users domain group. So, having done that, we configured this second account as the identity of the app pool.

To begin with, nothing worked. Every time we tried to access the WCF endpoint, IIS returned a 404 - Service unavailable message. However, at some point, the whole thing started working OK. I forget, now, the exact sequence of steps, but that is not important.

At some point yesterday, the BizTalk developer created a local account called 'BizTalk Isolated Host Users'. I can't remember, now, why we thought this would be a good idea. Our BizTalk Server is configured to use a domain group of the same name, and is not aware of the local group. The important point, though, is that this group was not deleted.

Roll forward to today. Everything was working nicely until the BizTalk developer decided, very sensibly, to tidy things up by removing the unneeded local group. Shortly after removing this group, we noticed that the dreaded 404 response had returned. The only change we had made was the removal of the local group, so we recreated it. We didn't add any accounts to it. After an IIS restart, the endpoint sprang back into life. We deleted the group, and everything stopped working. We recreated it again, checked that the endpoint was working, renamed the group and tested. Sure enough, we got a 404. We changed the name back, and the endpoint worked.

At this point, I felt very confused at several levels. We checked the configuration of BizTalk carefully, and satisfied ourselves that it had indeed been configured to use only domain accounts and groups. The only thing that was unusual about our environment was that, while the BizTalk isolated host instance we were using was configured to use one domain account for its logon credentials, the IIS app pool was configured to use another, set up with equivalent group membership and permissions.

I have always, as a natural path of least resistance, configured app pools to use the same identity as the corresponding isolated host instance. I realised that I have never consciously asked the question about what happens if you use different accounts. I phoned a colleague who has far more practical experience of deploying BizTalk than I do, and discussed this with him. He confirmed that he also always uses the same account, and like me, he had never stopped to wonder what happens if you use different accounts. So, I turned to the Internet and did some searching. Eventually, I discovered, embedded half-way through a BizTalk help page on MSDN (see http://65.55.11.235/en-us/library/aa561505.aspx), an explicit statement that the app pool should always be configured with the same account as the isolated host instance. In the grand tradition of BizTalk documentation there was, of course, absolutely no effort expended on explaining why. However, the help page also stated mysteriously that if you change the password on the account in the app pool configuration, there is no need to make a corresponding change to the credentials configured on BizTalk's isolated host instance. Bizarre. This seems to imply that the credentials you configure in BizTalk are not actually used for any kind of authentication.

We talked to the hosting company, and managed to get the password we needed. We re-configured the IIS app pool to use the same account configured for the BizTalk isolated host instance. Having deleted the local group, we restarted IIS and...success...everything worked OK.

So, the moral of the story is that you really need to ensure that your app pool identity is the same as the account you configure on the BizTalk isolated host instance. Don't worry about keeping the password up to date in BizTalk. I strongly recommend you always use this approach. If you really, really , really have to live with different accounts, create an empty local group on you BizTalk box with an identical name to the domain group you are using as BizTalk isolated host users group, and by some magic, everything will work. Avoid this weird 'work-around' at all costs in production.

Maybe this is some strange side-effect of Windows pass-through authentication (I don't really think that is the case), or maybe it is the result of some undocumented logic deep in the message agent or transport layer. I can't say. I do remember that when BTS 2004 first shipped, there was a suggestion that MS might at some point extend the isolated host feature to support additional hosts, and not just IIS. This has never happened, but it may be the explanation for what you configure an account and password on your isolated host instances even if, in the case of IIS, it is the app pool configuration which is all-important.

Biztalk Server: What's wrong with the UDDI Features of the The ESB Guidance Toolkit v1?

Charles Young — Wed, 12 Nov 2008 22:31:48 GMT

I spent some time today looking at Microsoft's Enterprise Service Bus (ESB) Guidance Toolkit, and this reminded me of an issue which we noticed a year ago, and did attempt to raise with Microsoft at the time, but which I never blogged about. It's always a little uncomfortable taking the good people at Redmond to task, but, while this is hardly the most urgent problem facing today's world, it is, nevertheless, a bit of a problem and something which should be addressed.

In the article, I discuss the problem, where the Toolkit goes wrong, how UDDI should be used, and a possible remedy. The article is at http://geekswithblogs.net/cyoung/archive/2008/11/12/126975.aspx.

Dublin and BizTalk Server - What's the difference?

Charles Young — Wed, 15 Oct 2008 05:23:07 GMT

The last couple of weeks have seen a significant increase in terms of announcements and information from Microsoft ahead of the Professional Developer’s Conference next week. It is a key time for Microsoft’s Connected Systems Division (CSD) as they go public with their plans for .NET 4, Oslo and ‘Dublin’. Microsoft’s announcement of Dublin led immediately to an interesting, if somewhat predictable, debate within the company I work for, and I think it is worth going over some of that territory here.

http://geekswithblogs.net/cyoung/archive/2008/10/15/125848.aspx

BizTalk Server 2009 Announced

Charles Young — Sat, 06 Sep 2008 02:34:38 GMT

Microsoft announced BizTalk Server 2009 today, and gave the green light to talking about the new version. It’s due for release in the first half of next year, and is shaping up nicely. Microsoft is casting BizTalk Server 2009 as a major new version in its own right, rather than just an updated 'release' of BizTalk Server 2006. This is an important move, and one I strongly welcome. There is certainly enough in BizTalk Server 2009 to warrant thinking of it as a major revision of the product, although it retains the same familiar functionality and tooling we have been using since 2006 (or even 2004).

I've been fortunate in getting my hands on the current non-public CTP in the last month or so, and putting aspects of the new version through its paces. It's not wise to go into much detail about this first CTP because some of those details will doubtless change in forthcoming betas, driven in part from the feedback Microsoft is getting. However, I will say a little about the new development and build features and expand just a little on the press releases. These are the areas I have been looking at in depth.

BizTalk Server 2009 will ship with bindings for Visual Studio 2008, and you will need to upgrade to this version of the IDE if you are still using Visual Studio 2005 (which you will be, of course, if you are a BizTalk Server 2006 user). It happens that, in previous months, I've seen more than one BizTalk shop where developers are having to run both versions of the IDE side by side in order to continue developing for BizTalk Server 2006 whilst exploiting features like WCF and WF in .NET 3.5. For many, the changes in BizTalk Server 2009 will come as a relief. This is not a cynical ploy by Microsoft to force people into upgrades for no additional benefit. The move to Visual Studio 2008 is accompanied by a very welcome move to a new project format, bringing BizTalk Server 2009 into line with mainstream .NET development. The new BizTalk project type is defined using MS-Build, just like C# or VB.NET projects. This has major implications in a number of areas. First, it means that, if you use TFS Build, you can now build BizTalk Server 2009 projects without having to write complex scripts that shell out to DevEnv. Just like C# projects, you can let TFS Build do the majority of the grunt work for you, and concentrate your attention more fully on ensuring that your automated build scripts are comprehensive and robust. This is worth the upgrade in its own right, and removes a major source of current irritation. Thanks to the rough edges in the current CTP, one of my colleagues has had the opportunity to get to grips with this side of BizTalk Server 2009 in some depth, and we can report that it is all looking very good indeed, once a few remaining gremlins have been chased out.

The other aspect of BizTalk Server 2009 which we have spent some time on is unit testing and debugging. In one sense, this is not really so much about new functionality, but more about bringing what has previously been considered 'black-belt' into the mainstream. In Biztalk Server 2006, we currently use BizUnit to drive black-box (grey-box?), end-to-end testing, but we have also created some additional code of our own to support unit testing of BizTalk maps, schemas and pipelines. Similarly, if you know the undocumented registry key in BizTalk Server 2006, you can get BizTalk to retain the generated C# code for debugging purposes, manually attaching to BtsNtSvc.exe processes in order to debug into orchestrations, etc. This has proved a life saver in certain situations. The new version of BizTalk Server is now designed to support these approaches seamlessly. Of course, it is designed to work with the integrated unit testing features of the IDE, rather than BizUnit. There are currently some outstanding questions with regard to the debugging support which I won't go into here, because they simply reflect the unfinished state of the first CTP. However, unit testing certainly works smoothly with BizTalk Server 2009 projects, and will help to raise the bar in terms of the approach that is taken to development of BizTalk solutions. Again, I will avoid going into further here because I will hit issues that are still to be fully resolved, but things are generally looking good.

I have only mentioned those areas of BizTalk Server 2009 which I have been looking at in any depth. There is a lot, lot more. One thing I will monitor closely is the inclusion of ESB Guidance 2.0. I have some problems with some aspects of ESB Guidance 1.0, like the unfortunate way in which the UDDI resolver violates the UDDI standard! However, having spent the last year doing little else but designing and implementing service bus patterns using BizTalk Server and WCF (or, in one case, WSE), I regard the inclusion of ESB Guidance 2.0 as a really intriguing, and hopefully worthwhile, aspect of the new version. It is also intriguing that Microsoft has decided to release their implementation of UDDI 3.0 as part of the BizTalk package. Let no one tell you that BizTalk has no role to play in building service buses, or that it is to be regarded as 'merely a hub-and-spoke message broker'. In my experience, the exploitation of the dynamic features of BizTalk (dynamic ports, BAM interception, the rules engine, etc.,) in a rigorous, policy-driven fashion provides good support for implementing many of the core patterns described within the world of ESB. The core design of BizTalk Server predates later ESB thinking, but is much better aligned to it that some people will admit.

Roll on 2009.

MS BRE: Using Compensation handlers

Charles Young — Wed, 23 Jan 2008 06:48:52 GMT

Being known for my interest in rules processing, I quite often get asked to help with problems with MS BRE. A couple of days ago, I was asked to help investigate an issue occurring in production for a BizTalk Server application. Occasionally, in a fairly high throughput system, BizTalk logs an error stating that a problem has been encountered while executing a rule set. That is the only information provided, with no hint of what the problem might be, and because the issue only occurs intermittently under real-world conditions in the production environment, it was not obvious how to obtain further insight without disrupting live operations.

This article investigates one way of handling this deilemma through the use of the compensation handling feature of Microsoft's Business Rules Engine. It goes on to discuss the broader use of compensation handling in rule processing.

http://geekswithblogs.net/cyoung/archive/2008/01/23/118804.aspx