BizTalk Server 2004/2006

BizTalk Server 2010 R2 Announced

Charles Young — Fri, 09 Dec 2011 08:37:43 GMT

Yesterday, Microsoft announced the forthcoming release of BizTalk Server 2010 R2 on the BizTalk Server blog site. This is advanced notice, given that this new version will ship six months after the release of Windows 8, expected in the second half of next year. On this basis, we can expect the new version of BizTalk Server to arrive in 2013. Given the BizTalk team’s previous record of name changes, I wonder if this will eventually be released as BizTalk Server 2013.

Microsoft has been refreshingly open in recent months about their future plans for BizTalk Server. This strategy has not been without its dangers with some commentators refusing to accept Microsoft’s statements at face value. However, yesterday’s announcement is entirely in line with everything Microsoft has been saying, both publically and privately, for some time now. Since the release of BizTalk Server 2004, Microsoft has made little change to the core technology with, of course, the exception of a much re-vamped application packaging approach in BizTalk Server 2006. Instead, Microsoft chose to put investment into a number of important ‘satellite’ technologies such as EDIFACT/X12/AS2 support, RFID Server, etc. Maintaining the stability of the core platform has allowed BizTalk Server to emerge as a mature and trusted workhorse in the enterprise integration space with widely available skills in the marketplace.

In terms of its major investments, Microsoft’s focus has long shifted to the cloud. Microsoft has candidly communicated that, given this focus, they have no current plans to add major new technologies to the BizTalk platform. In addition, they absolutely have no intention of re-engineering the core BizTalk platform. In my direct experience in recent months, this last point plays very well to prospective and existing enterprise customers. It takes us straight to the heart of what most organisations want from an integration server: a ‘known quantity’ with a good track record for dependability, scalability and stability and a significant pool of available technical resource.

The announcement of BizTalk Server 2010 R2 illustrates and illuminates Microsoft’s stated future strategy for the product. An important part of Microsoft’s platform for enterprise computing, it will continue to be enhanced and extended. It will match future developments in the Windows platform and new versions of Visual Studio. However, we should not expect to see any dramatic new developments in the world of BizTalk Server. Instead, the BizTalk platform will continue to steadily mature further as the world’s best-selling integration server.

One of the big messages of yesterday’s announcement is that BizTalk Server will increasingly support its emerging role in building hybrid solutions that encompass systems and services that reside both on-premises and in the cloud. At SolidSoft , we are increasingly focused on the design and implementation of cloud-based and hybrid integration solutions. Integration is challenging, and Azure is a young, fast evolving platform. Microsoft has discussed at length their vision of Azure within a wider ‘hybrid’ context. The availability of a tried and tested, mature, on-premises integration server is a vitally important enabler in building hybrid solutions. Better than that, the announcement makes it clear that, as well as new support for the Azure service bus, BizTalk Server 2010 R2 licensing will be revised to open up new opportunities for hosting the server in the cloud. This ties in with the push in Azure to embrace more fully the IaaS (infrastructure-as-a-service) model and, perhaps most importantly in the BizTalk space, to reduce or eliminate existing barriers between the on-premises and off-premises worlds. BizTalk Server and Azure belong together.

Announcing BizTalk Server 2010 Unleashed

Charles Young — Sun, 25 Sep 2011 21:30:24 GMT

At last, I can announce that ‘BizTalk Server 2010 Unleashed’ has been published and is available through major booksellers in both printed and electronic form. The book is not a new edition of the old ‘BizTalk Server 2004 Unleashed’ book from several years ago, although Brian Loesgen, our fearless team leader, provided continuity with that title. Instead, this is entirely new content written by a team of six authors, including myself.

BizTalk Server is such a huge subject. It proved a challenge to decide on the content when we started our collaboration a couple of years back (yes, it really was that long ago!). We quickly decided that the book would principally target the BizTalk development community and that it would provide a solid and comprehensive introduction to the chief artefacts of BizTalk Server 2010 solutions – schemas, maps, orchestrations, pipelines and adapters. Much of this content was written by Jan Eliasen and forms part 1 (“The Basics”) of the book.

On the day my complimentary copies were delivered, I was working on the implementation of a pipeline component, and had an issue to do with exposing developer-friendly info in Visual Studio. I used this as a test-run of Jan’s content, and sure enough, discovered that he had clearly addressed the issue I had, including sample code. Jan’s contribution is succinct and to the point, but is also very comprehensive (he’s even documented things like creating custom pipeline templates!). I particularly appreciate the way he included plenty of guidance on testing individual artefacts.

My contributions to part 1 is a chapter on adapters (the ‘adapter chapter’ as we fondly called it). This explores each of the ‘native’ adapters and the family of WCF adapters. There is also some content on the new SQL adapter which is part of the BizTalk Adapter Pack. In that respect, it overlaps with ‘Microsoft BizTalk 2010 Line of Business Systems Integration’ which I reviewed recently, and also in respect of the SharePoint adapter. However, ‘Microsoft BizTalk 2010 Line of Business Systems Integration’ provides a whole lot more information on a range of LoB adapters. It is written in a different style to BizTalk Server 2010 Unleashed and is highly complementary.

Although the original plan was to include content on custom adapter creation, this didn’t, in the end, get covered in any depth. One reason for this is that, going forward, most custom adapter development for both BizTalk and Azure Integration Services (still some way off) is likely to be done using the WCF LoB Adapter SDK. That suggested that we would have had to document two distinct adapter frameworks in order to do the job properly, and this proved a little too much to tackle. Room there for another book, methinks.

Part 1 accounts for about half the content of the book. Beyond this, we wanted to add value by covering more advanced topics, including the use of BizTalk Server alongside WCF and the emerging Azure platform, new features in BizTalk Server 2010 and topics that have been only partially covered elsewhere. So, for example, Anush Kumar was contributed an entire section (part 4) on RFID including the new RFID Mobile Framework. Anush is well-known in the BizTalk community due to his involvement in the development of RFID Server. Between Jon Flanders and Brian Loesgen, the book includes content on exploiting WCF extensibility in BizTalk, integrating via the Azure service bus (please note that this content was written before the advent of topics/subscriptions or Integration Services), the BAM framework and the ESB toolkit.

There is also a whole section (part 3) written by Scott Colestock that introduces the Administration Console and describes deployment approaches for BizTalk solutions.

Rules

That leaves one more subject for which I was responsible. One of the main reasons I was asked to contribute to the book was to document rules processing. Although there is some great content out there on the use of the BRE, I have long felt there is a need for a more comprehensive introduction. Due to some early confusion, I originally intended a total of seven short chapters on rules, but this content was refactored into two longer chapters. The first chapter introduces the Business Rules Framework. My idea was to emphasise the entire framework up front, rather than simply explore the rules composer and other tools. I also tried to explain the typical ‘feel’ of rules processing in the context of a BizTalk application, and the relationship between executable rules and higher-level business rules.

The second chapter investigates rule-based programming. It attempts broadly to achieve two related goals. The first is to explain rules programming to developers, to demystify the model, explain the techniques and provide insight into how to handle a number of common issues and pitfalls that rules developers face. The second is to provide a solid theoretical introduction to rules processing, including concepts that are not generally familiar to the average developer. I resisted the temptation, though, to provide an in-depth explanation of how the Rete Algorithm works, which I’m sure will be a relief :-) You can read the Wikipedia article on that.

Conclusions

So there you have it. BizTalk Server 2010 is a mature enterprise-level product which, although it has a long future ahead of it, won’t change fundamentally over time. Microsoft has publically stated that their future major investments in EAI/EDI will be made in the Azure space, although new versions of BizTalk Server will continue to benefit from general improvement and greater integration with the evolving Azure platform. So, hopefully, our content will serve for some time as a useful introduction to BizTalk Server, chiefly from a developer’s perspective.

Book Review: Microsoft BizTalk 2010 Line of Business Systems Integration

Charles Young — Mon, 19 Sep 2011 21:47:38 GMT

One benefit of my recent experience on a BA flight was that I got plenty of time to read through “Microsoft BizTalk 2010 Line of Business Systems Integration”. I’d promised the publisher weeks ago that I would take a look and publish some comments, but August has been such a busy month for me, and they have had to be patient. I should point out that, for the sake of transparency, that with another BizTalk book about to be released (next week) which I helped co-author, I have an urgent and obvious need to make good on this promise before I start to blog on other stuff.

BTS10LoBI is a really welcome addition to the corpus of BizTalk Server books and fills a conspicuous gap in the market. BizTalk Server offers a wide-ranging library of adapters. The ‘native’ (built-in) adapters understandably get a lot of attention, as do the WCF adapters, but other adapters, such as the LoB adapters and HIS adapters, are often overlooked. I came to the book with the mistaken assumption that its chief focus was on the BizTalk Adapter Pack. This is a pack of adapters built with the WCF-based LoB SDK. In fact, the book follows a much broader path. It is a book about LoB integration in a general sense, and not about one specific suite of adapters. Indeed, it is not simply about adapters. It focuses on integration with various LoB systems, and explains how adapters and other tools are used to achieve this.

This makes for a more interesting read. For example, one, possibly unintended, consequence (given that it represents collaboration between five different authors) is that it illustrates very effectively the spectrum of approaches and techniques that end up being employed in real-world integration. In some cases developers use adapters that offer focused support for metadata harvesting and other features, exploited through tools such as the ‘Consume Adapter Service’ UI. In other cases, they use native adapters with hand-crafted schemas, or they create façade services. The book covers additional scenarios where third-party LoB tools and cloud services (specifically SalesForce) are used in conjunction with BizTalk Server. Coupled with lots of practical examples, the book serves to provide insight into the ‘feel’ of real-world integration which is so often a messy and multi-faceted experience.

The book does not cover the BizTalk Adapter Pack comprehensively. There is no chapter on the Oracle adapters (not a significant issue because they are very similar to the SQL Server adapter) or the Siebel adapter. On the other hand, it provides two chapters on the SAP adapter looking at both IDOC and RFC/BAPI approaches. I particularly welcome the inclusion of chapters on integration with both Dynamics CRM 2011 and Dynamics AX 2009. I learned a lot about Dynamics CRM which I haven’t had occasion personally to integrate with in its latest version. The chapter on SalesForce mentions, but does not describe in any detail, the TwoConnect SalesForce adapter which we have used very effectively on previous projects. Rather, it concentrates on direct HTTP/SOAP interaction with SalesForce.com and, very usefully, advocates the use of Azure AppFabric for secure exchange of data across the internet.

The book provides two chapters on integration with SharePoint 2010. The first explores the use of the native adapter to communicate with form and document libraries, and provides illustrated examples of working with InfoPath forms. It would have been reasonable to stop there, but instead, the second chapter goes on to describe how to integrate more fulsomely with SharePoint via its web service interface, and specifically how to interact with SharePoint lists.

Increasingly, the BizTalk community is waking up to the implications of Windows Azure and AppFabric. This is an important step for developers to take. Future versions of BizTalk Server will essentially join and extend the on-premise AppFabric world. As Microsoft progressively melds their on/off premise worlds, BizTalk developers will increasingly have to grapple with integration of cloud based services, and integration of on-premise services via the cloud. The book is careful to address this emerging field through the inclusion of a chapter on integration via the Azure AppFabric service bus. As I mentioned above, this is applied specifically to SalesForce integration in a later chapter. The AppFabric Service Bus is a rapidly-evolving part of the Azure platform, and is set to introduce a raft on new features in the coming months which will greatly extend the possibilities. Eventually we will see cloud-based integration services appear in this space. So, the inclusion of this chapter points out the direction of major future evolution of Microsoft’s capabilities and offerings in the integration space.

The book is not shy about providing guidance on practical problems and potential areas of confusion that developers may encounter. The content is clearly based on real-world experience and benefits from ‘war stories’. The value of such content cannot be underestimated, and can save developers hours of pain and frustration when tackling new problems. All in all, I thoroughly welcome this book. My thanks to the authors, Kent Waere, Richard Seroter, Sergei Moukhnitski, Thiago Almeida and Carl Darski.

BizTalk Server 2010: Loading properties in custom pipeline components

Charles Young — Wed, 14 Sep 2011 13:48:44 GMT

Following the previous post, here is a second bit of wisdom. In the Load method of a custom pipeline component, only assign values retrieved from the property bag to your custom properties if the retrieved value is not null. Do not assign any value to a custom property if the retrieved value is null.

This is important because of the way in which pipeline property values are loaded at run time. If you assign one or more property values via the Admin Console (e.g., on a pipeline in a Receive Location), BizTalk will call the Load method twice - once to load the values assigned in the pipeline editor at design time and a second time to overlay these values with values captured via the admin console. Let's say you assign a value to custom property A at design time, but not to custom property B. After deploying your application, the admin console will display property A's value in the Configure Pipeline dialog box. Note that it will be displayed in normal text. If you enter a value for Property B, it will be displayed in bold text. Here is the important bit. At runtime, during the second invocation of the Load method, BizTalk will only retrieve bold text values (values entered directly in the admin console). Other values are will not be retrieved. Instead, the property bag returns null values. Hence, if your Load method responds to a null by assigning some other value to the property (e.g., an empty string), you will override the correct value and bad things will happen.

The following code is bad:

object retrievedPropertyVal;
propertyBag.Read("MyProperty", out retrievedPropertyVal, 0);

    if (retrievedPropertyVal != null)
    {
        myProperty = (string)retrievedPropertyVal;
    }
    else
    {
        myProperty = string.Empty;
    }

Remove the 'else' block to comply with the inner logic of BizTalk's approach.

Biztalk Server 2010: Pipeline component fails with "Value does not fall within the expected range."

Charles Young — Wed, 14 Sep 2011 12:36:02 GMT

Here is a small snippet of BizTalk Server wisdom which I will post for posterity. Say you are creating a custom pipeline component with custom properties. You create private fields and a public properties and write all the code to load and save corresponding property bag values from and too your properties. At some point, when you deploy the BizTalk application and test it, you get an exception from within your pipeline stating, unhelpfully, that "Value does not fall within the expected range." Or maybe, while using the Visual Studio IDE, you notice that values you type into custom properties in the Property List are lost when you reload the pipeline editor.

What is going on? Well, the issue is probably due to having failed to initialise your custom property fields. If they are reference types and have a null value, the PipelineOM PropertyBag class will throw an exception when reading property values. The Read method can distinguish between nulls and, say, empty strings, due to the way data is serialised to XML (e.g., in the BTP file). Here is a property initialised to an empty string:

Here is the same property set to null:

The first is OK. The second causes an error and leads to the symptoms described above.

ALLWAYS initialise property backing fields in custom pipeline components. NEVER set properties to null programmatically.

Tellago releases a RESTful API for BizTalk Server business rules

Charles Young — Wed, 09 Feb 2011 15:35:02 GMT

Jesus Rodriguez has blogged recently on Tellago Devlabs' release of an open source RESTful API for BizTalk Server Business Rules. This is an excellent addition to the BizTalk ecosystem and I congratulate Tellago on their work.

See http://weblogs.asp.net/gsusx/archive/2011/02/08/tellago-devlabs-a-restful-api-for-biztalk-server-business-rules.aspx

The Microsoft BRE was originally designed to be used as an embedded library in .NET applications. This is reflected in the implementation of the Rules Engine Update (REU) Service which is a TCP/IP service that is hosted by a Windows service running locally on each BizTalk box. The job of the REU is to distribute rules, managed and held in a central database repository, across the various servers in a BizTalk group. The engine is therefore distributed on each box, rather than exploited behind a central rules service.

This model is all very well, but proves quite restrictive in enterprise environments. The problem is that the BRE can only run legally on licensed BizTalk boxes. Increasingly we need to deliver rules capabilities across a more widely distributed environment. For example, in the project I am working on currently, we need to surface decisioning capabilities for use within WF workflow services running under AppFabric on non-BTS boxes. The BRE does not, currently, offer any centralised rule service facilities out of the box, and hence you have to roll your own (and then run your rules services on BTS boxes which has raised a few eyebrows on my current project, as all other WCF services run on a dedicated server farm ).

Tellago's API addresses this by providing a RESTful API for querying the rules repository and executing rule sets against XML passed in the request payload. As Jesus points out in his post, using a RESTful approach hugely increases the reach of BRE-based decisioning, allowing simple invocation from code written in dynamic languages, mobile devices, etc.

We developed our own SOAP-based general-purpose rules service to handle scenarios such as the one we face on my current project. SOAP is arguably better suited to enterprise service bus environments (please don't 'flame' me - I refuse to engage in the RESTFul vs. SOAP war). For example, on my current project we use claims based authorisation across the entire service bus and use WIF and WS-Federation for this purpose. We have extended this to the rules service. I can't release the code for commercial reasons :-( but this approach allows us to legally extend the reach of BRE far beyond the confines of the BizTalk boxes on which it runs and to provide general purpose decisioning capabilities on the bus.

So, well done Tellago. I haven't had a chance to play with the API yet, but am looking forward to doing so.

BizTalk Server 2010 Developer Edition - Installation Issue

Charles Young — Sun, 26 Sep 2010 12:58:03 GMT

I installed the new BizTalk Server 2010 Developer Edition, released a couple of days ago, on a Windows Server 2008 R2 virtual image. The installation went very smoothly, but I did notice one problem. Initially I attempted to upgrade the beta version of BizTalk Server. Brian Loesgen reports that this worked OK for him. However, I couldn't do this. The installer reported that upgrade from the Enterprise Edition to the Developer Edition is not supported. I attempted to uninstall the beta, but got an error message which left my installation in an invalid state.

Fair enough. You have to expect this sort of problem when using betas. That’s one good reason for using virtualisation.

I installed the RTM Developer Edition on a fresh image, and as I say, everything went very smoothly. However, I tried re-running the BizTalk installer and, to my dismay, got a rude message saying:

Cannot uninstall or modify the Dev. edition of BTS 2010

Setup has detected that the Enterprise Edition of BizTalk Server 2010 was installed. Upgrading from the Enterprise Edition to the Developer Edition is not supported.

Please uninstall the Enterprise Edition and then run Setup again.

This is simply not true. This was a completely fresh build of Windows Server on which I have only installed the Developer Edition. I have not tried uninstalling BizTalk to see what happens.

So, be careful with the Developer Edition. My experience is that there is a problem with the installer.

[UPDATE 28/09/2010] Rahul, from MS, is looking into the issue. Meanwhile, early indications are that others are not experiencing the same problem. Thiago Almeida kindly experimented, and was able re-run setup. He is using Windows 7 Enterprise whereas I am using Windows Server 2008 R2. Also, he built a 32-bit installation using WinVPC wheras I built a 64-bit installation using VirtualBox (WinVPC can't run 64-bit images). Meanwhile, over on Connect, Johan Hedberg, reports that things worked OK for him on a 64-bit Windows 7 machine. He uninstalled the beta and then installed the RTM of the Dev edition, and can re-run setup OK. Jan Eliasen has also reported that things work OK on a 64-bit VMWare image running the same combination of software I am using.

BizTalk Server 2010 RTM

Charles Young — Thu, 23 Sep 2010 21:12:20 GMT

The BizTalk Server team announced today that BizTalk Server 2010 has RTMd. That's a relief, as my reputation was on the line regarding RTM before the end of the month. Just this Tuesday I confidently told a prospective customer to expect an imminent announcement.

I've been playing with BTS 2010 for a little while now. It has been my constant companion while writing several chapters for the forthcoming BizTalk Server 2010 Unleashed. It looks great. As well as bringing BTS up to date with Visual Studio 2010 and SQL Server 2008 R2, it introduces some welcome improvements. First and foremost, for developers, is a re-worked mapper. A decade ago, the mapper was the 'killer app' (as Clemens Vasters put it at the time) that sold BTS 2000 licences. A lot has changed since then, but the mapper, although much copied over the years, remains a vital part of BizTalk tooling. The new version is head and shoulders over the previous version and, frankly, over much of the competition as well. In the last few days, I've constructed a couple of medium-complexity maps in BTS 2009. I really, really wished I was using BTS 2010. Even though the maps were not by any means the biggest and ugliest I have worked on, things would still have been much easier with the new version. Better still, you can use the new mapper in conjunction with WCF/WF workflow services in .NET 4 (under the beta, you had to have AppFabric installed - I haven't tested this yet on the RTM version). It's a great indication of how, as time goes on, BizTalk Server is supporting and extending WCF/WF to an ever-greater degree. There is much more water to flow under this particular bridge.

One more point about the mapper. It seems the hilariously named 'Suggestive Match' feature in the beta (wink, wink) has been renamed 'Predictive Match'. They are a bunch of killjoys over there in Redmond, but I suppose double entrendres have no place in enterprise-level platforms.

The Trading Partner Management features have had a welcome makeover. Some of us older folk remember how BTS began life as the Commerce Interchange Pipeline (CIP) in Microsoft Site Server (ah, what a trip down memory lane!). BizTalk Server was originally conceived principally as a B2B product and has always had some TPM features. Over the years these have languished. BTS has excellent support for EDI standards (EDIFACT, X12 and AS2), but the TPM was relatively poor. That has changed in BTS 2010 with the introduction of a completely reworked model with new support for agreement templating and onboarding as well as new models for centralised management of identities, message types, validation, etc.

There are new features to please the operations guys who have to maintain BTS, including a new improved SCOM management pack, new rapid tuning features and data compression for backups. RFID Server has also been extended with a number of new event handlers and other features.

Looking through the official announcement, I am clearly going to have to revisit some of the adapter content I've recently been writing for BizTalk Server 2010 Unleashed. When looking at the beta, I discovered the SSL extensions to the existing FTP adapter, but MS keep on talking about a new FTPS adapter as if it is a separate item. This is currently confusing me. They also talk about new features of the File adapter which I didn't discover in the beta. [UPDATE 26/09/2010] The list of new features in the BizTalk Server Team blog is confusing. There is no new separate FTPS adapter, but simply a set of extensions to the existing FTP adapter, including SSL support. Also, I misinterpreted the list of features assuming that they referred to extensions to the File adapter. Not so. They are new features of the FTP adapter which I had actually discovered previously! The beta documentation clearly stated that the old SQL Server adapter has been removed from the product, but it was still there in the beta. I will be interested to see if it is in the RTM version. If it is, I understand that it will not be supported. [UPDATE 26/09/20010] The SQL Server adapter is still included in the product, BUT is no longer supported, except in certain cases. It appears that the help documentation has been tidied up in order to clarify the situation. Here is what it says:

"BizTalk Server no longer supports the SQL Adapter. We recommend you use Microsoft BizTalk Adapter for SQL Server to achieve the same functionality.

However, BizTalk Server supports the SQL Adapter with the components shipped with BizTalk Server, like EDI Control message SQL receive pipeline, or AS2 resend control message receive pipeline."

The old SOAP adapter, I believe, retains its deprecated status but is still supported. [UPDATE 26/09/20010] Yes, this is the case. This caused me some pain earlier this year when we discovered that a customer, new to BizTalk Server, needed to integrate with a central system via web services written in an older version of Apache Axis. Axis used to use RPC/Encoded as the default SOAP style, and I had to explain to the customer that, having spent all that money on a bright shiny new integration server, the only way it could support this part of the SOAP specification was through a deprecated adapter. The WCF adapters have no support for RPC. Also, publishing ASMX web services via BizTalk with RPC support is not handled well. You have to make changes to the code generated by the publishing wizard to get everything working as required. <rant>For BizTalk Server to fail to provide good support for a major, if unfashionable, part of the SOAP spec, and to only support RPC via a deprecated adapter verges on the incredible. In the rush to adopt pristine-pure WCF, there is always the fear that Microsoft could lose sight of the whole purpose of BizTalk Server and the value proposition it offers to companies. It is an integration server. It is there to cope with mess and confusion, mediocre and bad practice, delinquent systems and ancient protocols. Supporting things like RPC is what makes the cost of the license worthwhile.</rant>

I can't yet comment on the stability of the development tools in BTS 2010. I haven't experienced any major problems with the BTS 2010 beta, but I've yet to do any serious development in the new version. BTS 2009 dev tools were delivered in a poor, sometimes barely usable, state although subsequent hotfixes improved things significantly. The biggest issue in BTS 2009 remains the poor handling of references amongst multiple BizTalk projects. There were other problems as well. On my current project, I've been struggling just today with very peculiar and wrong behaviour when deploying a small cluster of BizTalk projects to a single application. I really hope that some headway has been made on these issues in BTS 2010 as they are an open sore in this otherwise excellent, stable and mature product.

So, welcome to BTS 2010, and congratulations to Microsoft on getting this version out of the door in the stated timeframe. Keep up the good work.

BizTalk Server: Handling decimal types with the xpath() Function

Charles Young — Tue, 23 Feb 2010 15:17:10 GMT

Last week, I spent some time looking at a problem with a customer's orchestration. In one place, the developer had made use of the infamous BizTalk xpath() function to assign a value in one message to a decimal field in another message. He got an error stating that the application is "Unable to cast object of type 'System.Double' to type 'System.Xml.XmlNodeList'". This is due to a logical error in BizTalk's code. Read more at http://geekswithblogs.net/cyoung/archive/2010/02/23/biztalk-server-handling-decimal-types-with-the-xpath-function.aspx.

MS BRE Backward Chaining - Part 3: The ‘Bound Variable' pattern

Charles Young — Mon, 18 Jan 2010 05:29:00 GMT

This is the third and final part of a three-part series, as follows:

· Part 1: Situating the Business Rules Engine

· Part 2: Backward Chaining: the 'Simple Name' pattern

· Part 3: Backward Chaining: the ‘Bound Variable' pattern

In Part 2 we looked at how developers can use procedural attachments and 'directive events' to implement a simple form of backward chaining for Microsoft's Business Rule Engine. In this third, and final, part, we will extend the code to tackle more complex backward-chaining requirements. The 'simple name' goal pattern is fairly easy to understand, but is limited. It provides a coarse-grained mechanism for switching sets of rules 'on' and 'off' in a backward-chained fashion. When this model fits the problem, it can work well. However, many real-world problems requires a greater degree of expressivity.