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 inter

A question came up tonight on BizTalkGurus on my favourite subject of rule engines. I don’t blog enough these days, so this gives me an excuse. Essentially, the question concerned an incorrect, but understandable, belief that MS BRE may be using remoting to execute rule sets out-of-process. This is not the case. Here is an explanation of how it all works.

I’ve been asked a few times how the performance of WF (Windows Workflow Foundation) Rules compares with that of the Microsoft Business Rules Engine (MS BRE). Having done no testing, I could only guess at the answer. I’ve now undertaken some initial performance testing to compare WF and MS BRE, and decided to publish the results.

I got an email today requesting help in deciding the appropriate selection of rule processing technology for a workflow application. I’ve got requests like this before, so I’ve decided to post a reply publically.

The compensation model in BizTalk Server 2004 provides a versatile mechanism for addressing an extensive range of business process scenarios. It is used in situations where some condition arises that invalidates the outcomes of previously completed units of work associated with the same business activity. In these scenarios, it is generally necessary to revisit the completed units of work, inspecting the state of the system as it existed at the completion of each of those stages, and taking appr

I had some discussion today with Christof Claessens about the merits of using .NET classes as orchestration message types in BizTalk Server 2006. Here are some of the reasons I came up with, and also some of the issues.

I was recently asked if I would provide some insight into solving the following problem. In the given scenario, data stored in flat files in being delivered to the BizTalk message box via a pass-through pipeline. An orchestration subscribes to these messages and creates XML output. Each time a file is processed, the developer wants to 'dump' the contents of the flat file into an element in the output. Other information, including the file name, is also included in the XML.

Richard Seroter of Microsoft has published a useful blog posting at http://blogs.msdn.com/richardbpi/archive/2005/10/27/485696.aspx in which he describes one technique for passing messages of any type through a BizTalk orchestration. Here is some further information to supplement what he has written.

Having blogged on an undocumented registry key recently, I’d thought I’d introduce you, gentle reader, to another bit of hidden functionality in BizTalk Server 2004. This time, my subject is an entire wizard which is not registered or set up when you install BizTalk development tools. It’s a simple device called, variously, the BizTalk Server Project Wizard, the BizTalk Server Scenario Wizard and event the BizTalk Project Scenario Wizard (nothing like being consistent!!).