The Business Rule Engine, aka BRE, has been extensively used by organizations since its introduction on the BizTalk Server 2004.

As a mechanism for composing and executing business rules, the BRE was conceived to allow Business Analysts to author and manage their own rules without extensive technical background.

Regardless of who is creating and maintaining the rules, logic is being generated and should be submitted to tests as rigorous as the ones applied to any algorithm. The mechanic is the same, inputs are known, and for each rule an universe of output can be assumed.

It is possible to create unit tests by hand using the BRE Library (Microsoft.RuleEngine), however, this process can become time consuming depending on the number of rules you have to test and maintain.

Alternatively, creating a new BizUnit step that could unit test BRE rules and also take advantage of all the existent BizUnit Steps to validade the results sounded as a plausible solution for me.

The idea is pretty simple: Submit a document as a fact to the BRE and validate the results.

Right, but I have several rules that accept different kinds of facts other than documents as input, for example .Net Types, how would this BizUnit Step fill this requirement?

BizUnit Context Loaders could be used to handle those cases, basically the BRE BizUnit step would search for additional facts in the BizUnit Context, which would allow complete customization of incoming facts.

Unit Testing BizTalk ESB Toolkit 2.0 BRE Resolution Rules

The BizTalk ESB Toolkit 2.0 allows using the BRE as a dynamic mechanism of itinerary, mapping and endpoint resolution. I believe this will leverage even more the BRE popularity and increase drastically the need of having effective testing tools.

The Toolkit executes the mentioned resolution by evaluating the properties of a known data structure, technically named as “Resolution”. This data structured is firstly handed to the chosen “Resolvers” which execute their logic and fill the “Resolution” object properties as result of the resolution process.

If I am using the BRE as a “Resolver”, and I intend to create several rules to execute the dynamic resolution logic, how could I create a unit test to verify if the resolution is being executed correctly based on the inputs provided?

First, I need to be able to not only send a document as an input fact to the BRE but also the mentioned “Resolution” data structure, and secondly, the resultant data structure has to be validated to identify if the properties were properly filled as expected.

Thats where the ESBToolkitResolutionContextLoader and ESBToolkitResolutionValidationStep come in, they both fill the gap to accomplish ESB BRE Resolution unit tests using BizUnit steps.

The ESBToolkitResolutionContextLoader is responsible to load the “Resolution” data structure into the BizUnit Context, whereas ESBToolkitResolutionValidationStep will validate the same structure after the resolution process.

Notice that although these two steps are being mentioned in a BRE Resolution context, they are completely disconnected from BRE and could be reused to evaluate results of any other ESB Resolver (say that somebody creates a UDDI Resolver BizUnit Step for example).

Wrapping Up

All the mentioned BizUnit steps can be found in Codeplex, I also included some documentation that will help you to get acquainted with the configuration settings of each step. The BREExecuteStep is the core step that can be reused for various scenarios, the ESB Resolver additional steps are only an example of extensibility.

Bellow are some examples just to give an idea about how unit tests could be configured:

With Validation Step

With Validation Step and Context Loader

Before discussing which project development methodology to use we should fully understand the very particular nature of projects that we are talking about which is: Software Development. If the organization honestly understands that building software is different than constructing cars, buildings, etc… and that the process is more related to artistic development than any other thing, then we can start to move to a fairer discussion.

The other very important factor to be understood is that any project is developed on top of three main pillars: Time, Budget and Scope. It is possible is to either completely prioritize one of pillars over the others or two of them in a reasonable dose. What is impossible to do is to heroically be effective with all of them. In other others: quick, cheap and complete is not feasible.

Interesting to mention that Quality is not an adjustable variable, which means that when you are deciding “when you need to deliver”, “what budget you will account to deliver” and “what you will ultimately deliver”, you have to assume that the outcome has to have a fixed and acceptable quality that cannot be changed.

Again, this is software development, changing quality will only give temporary “benefits” that on the long run will not pay off, therefore, decreasing quality is not an option. That being said, if you need to adjust something you should adjust your expectation in those mentioned constraints, which can be expressed as: You should always deliver something with quality, in certain situations it can become more expensive than planned, it might take more time than planned, or it might have less features than planned.

The point is to deliver something that is working with quality (and quality does not mean fancy).

Agile defends the idea of just spending enough time on analysis and planning to be able to make progress (which does not necessarily mean that at the end, Agile Projects will have less documentation or planning). Anything beyond “enough” is treated as overhead as the scenario will most likely change.

Notice, I didn’t cite requirements will change, I mentioned the scenario will most likely change. What I mean by scenario is : requirements, estimates, priorities, constraints, or anything that might impact how and what results will be achieved.

Although we have learned that the scenario will change 99.9% of the times, I carefully used the term most likely to keep credibility of some conservative readers.

Even If one believes that a project can be finalized with zero changes in its scenario (since its conception), she has to agree that there is still a probability of change. With that in mind, executing project phases sequentially (rather than iteratively) with rare/occasional opportunities of going back for revision, seem not to be a wise approach, and implies taking a lot of risks that some like to overlook to make the scenario easier.

That’s why I think the real problem with software development is often related to the initial expectations. If the expectations are set incorrectly no matter what methodology you use, the project will be seen as a failure. Of course there is no silver bullet, both Waterfall and Agile can fail or succeed, my personal opinion is that Agile is most suited for software development as we agree that this nature of projects happens in a volatile scenario.

So, what happens with fixed budget, time and scope projects? This nature of projects has to have enormous initial effort just to find the right and practicable measure for the fixed portions of it. Important detail: Make sure you understand that by the time you start moving a finger toward to the goals of a project , the project itself has already started. If you want to measure effectiveness, make sure you count the time and effort spent on this complex process.

Certainty brings peace of mind, and that’s why fixed budget, time and scope are so compelling right? The only problem is trying to find certainty for the uncertain.

Some of you must be thinking: “This is all beautiful in theory, but my reality is different… I HAVE to deal with projects that will require precision in many decisions and changes are not easily acceptable.”

Even for these scenarios I see Agile providing benefits that waterfall could not give, just because of its core iterative and incremental nature.

The only scenario that I see Waterfall being extremely more advantageous than Agile, is for the projects that the outcomes will be developed in a complete static scenario and the same will be evaluated by something like a robot where no matter how many times you show something, the opinion or the output will be identical.

I think the secret is adaptation, for the situations you can’t avoid working with strict constraints, I believe Agile methodologies can be adapted.

If you need to deliver something, in a fixed time and budget , you have no time to loose and no money to waist. In other words: “You better completely and precisely understand the requirements written on that RFP (Request for Proposals) otherwise you are going to get burnt.” The best way to make sure that you are achieving the expected results without spending time and money with unneeded efforts is to make the stakeholders aware of every significant piece of software built as soon as possible so the unavoidable mistakes of any project are always corrected before is too late.

I see iterations, incremental releases and constant reviews as essential tools to support this scenario and meet the requirements effectively. Agile methodologies leverage all of these factors naturally and natively, and that’s where I think they have so much to contribute to any project, even the ones with so many restrictions.

There are three main steps needed to install a WCF LOB Adapter in a target machine:

1 – Copy adapter assemblies to the target machine.

2 – Install the adapter assemblies on the Global Assembly Cache.

3 – Register the adapter settings on the machine.config file.

In order to automate the mentioned steps you can either create a Visual Studio Installation Package or a Msbuild script. The first two steps are trivial and natively provided by the two mentioned approaches.

The last one deserves a bit more attention as custom logic needs to be built and performed. Initially, we need to understand what settings or xml elements/attributes are required to be created on the machine.config file, so the adapter is properly registered.

After understanding the requirements and implementing such logic, we need to either to have an Installation Package Custom Action or a Custom MSBuild Task to perform the steps.

If you choose the Installation Package as your deployment implementation, (Sonu’s Tech Blog, 2007) explains how to author the needed custom action.

On the other hand, if you would like to use MSBuild, the custom tasks: RegisterWCFLOBAdapter and UnregisterWCFLOBAdapter can be used in a MSbuild deployment script to perform the installation/uninstallation procedure.

The RegisterWCFLOBAdapter task can be used to register a WCF LOB Adapter through a MSBuild script as follows:

WCF LOB Adapter Full Installation Example:

The UnregisterWCFLOBAdapter task can be used to unregister a WCF LOB Adapter through a MSBuild script as follows:

WCF LOB Adapter Full Uninstallation Example:

This post tackles different methods that can be used to successfully unit test a BizTalk Solution. The mentioned approaches utilize a set of different tools to facilitate and organize how unit tests are created, maintained and executed.

Although BizTalk Software Factory is not a pre-requisite to fully understand the presented content, a brief overview is suggested as we will be ultimately using its solution structure and support classes to create our unit tests.

Testing XML Schemas

In order to successfully test XML Schemas we need to first comprehend the real purpose of a XML Schema, (Sperberg-McQueen & Thompson, 2000) define XML Schemas as:

Based on this definition, when testing XML schemas the focus should be on the validation of the targeted structure, content and semantic. It is worth it to spend time elaborating acceptable and unacceptable sample xml messages in order to verify if the constraints implied by the target XML schema are being correctly applied.

The set of unit tests should validate the compliance of each XML document instance with the XML Schema being tested. Unit tests being executed against acceptable XML Instances should pass the XML Schema validation, whereas Unit Tests for unacceptable XML Instances should expect validation errors as a condition for a successful test.

The steps needed to test a XML Schema are as straightforward as creating a simple Unit Test logic to load a XML Instance document and validate it against the XML Schema being tested.

Testing XML Schemas with NUnit

The Biztalk Software Factory facilitates the work needed to create the infrastructure required to unit test a Biztalk Solution. A Biztalk Software Factory based solution should have a [ProjectName].UnitTests project including helper classes to support tests created on this project.

As the name suggests, the XmlSchemaValidator class (located in the XmlSchemaValidator.cs file), can be used to validate xml document instances against XML Schemas. The code below exemplifies the usage of XmlSchemaValidator:

Testing BizTalk Maps

BizTalk Maps are used to transform documents from a source schema into a new document of a target schema. We can use two approaches to verify if the transformation is being performed correctly:

1.Validate the map output document against the target schema.


2.Validate the map output document against the desired output xml instance.

Testing BizTalk Maps with NUnit

The code below exemplifies how to test BizTalk Maps against a desired output xml instance:

Testing BizTalk Maps against a target schema:

Testing BizTalk Pipelines

Testing Pipelines is not different from testing any other component, the tricky part is the mechanism used to mimic the BizTalk Runtime Engine so the pipeline can be instantiated and executed. That’s exactly where Winterdom Pipeline Testing Framework enters in scene; see (Restrepo, 2007) for more details.

Winterdom Pipeline Testing Framework will provide support to execute pipelines as well as validate output messages in order to verify if any desired processing was made accordingly. If needed, pipeline components can also be tested independently, which allows us creating even richer pipeline unit tests.

As an example, it is possible to have an unit test dedicated to each of the pipeline components of a given pipeline and finally a unit test for the whole pipeline.

Adding message context properties, altering message content, and changing state of external systems are just a few examples of actions that might be taken in a Pipeline. Therefore, depending on the pipeline in question, applying effective testing might be a simple or complex task.

The unit test should validate if all the intended processing and modifications were made correctly, and as stated before, sometimes changes are not only restricted to the output message.

Testing BizTalk Pipeline Components with NUnit

The code below exemplifies how to test an entire pipeline using the Winterdom Pipeline Testing Framework:

Wrapping Up

After having some practice with BizTalk unit tests, you will notice that many of them will actually validate the proper execution of components and artifacts altogether. Although assuring that each piece works as designed separately will not guarantee any success when testing in a composed scenario, enormous amount of time will be saved when troubleshooting.

Another important point to be mentioned is that with Unit Tests the overall implementation quality tends to be increased as testing is being introduced on the early stages of your development process.

On Part II, some techniques will be shown explaining how to unit test BizTalk Business Rules and Orchestrations.

Reflector

You can use Reflector to disassemble .Net assemblies. Basically it will translate CLR Intermediate Language code contained in the .Net Assembly back to C#. This is also a great way to learn more about the .Net Base Class Library. However, be aware that there are some tools, such as Obfuscator, which protect assemblies from such reverse engineer.

SOAP UI

If you develop, debug, test or do anything related with Web Services or SOAP messaging then this tool will make you happy. If you were only interested to pick one tool of this list, I would suggest you to get this one. Until this day I still wonder how can be possible such powerful tool be offered for free, of course their priced version provides even more, but I am really satisfied with the free version. With this tool you will be able to inspect messages, invoke, load test web services, and take advantage of several other nice features.

Fiddler

Web debugging tool that you can use to troubleshoot HTTP traffic. Saved me a few times when working with REST services and ASP .Net applications.

Notepad++

If you need a lightweight and still powerful editor , Notepad++ is perfect. I use it mostly to edit xml files and develop XSLT docs. There are innumerous Plugins that will make this editor even more useful, my favorite is XML Tools, which allows xml validation, transformation, Xpath queries evaluation, and other cool features.

CLR Profiler

Having problems with .Net application performance? Have no idea why exceptions like StackOverflowException and OutOfMemoryException are being thrown? CLR Profiler is a good start to diagnose the problem. This user friendly tool displays interesting charts about the health of your application. Memory consumption per object type, allocation and call graphs are just basic examples of reports that this powerful tool will provide.

Windows Debugger (WinDbg)

If CLR Profiler is not enough and you need to go deeper , I would advise you to use Windows Debugger. However, if you have no previous experience this tool it might take some time to get acquainted with its endless list of features and commands. The best resource that I could find on the internet about how to use this tool and the troubleshooting art is this blog: If broken it is, fix it you should (http://blogs.msdn.com/tess/). Miss Tess Ferrandez will teach you how to brush the bits, really cool stuff.

Debug View

This tool monitors the OS debug output, if you simply open this application you will notice that several running processes are already writing debugging content on the window. Basically if you are developing a managed application, anything that you write via System.Diagnostics.Debug .Write (or the variations of this method) will be shown on DebugView.
Now use your imagination, you can use this resource to identify what is happening inside a BizTalk Orchestration, custom pipeline component, WCF LOB Adapter, Managed SQL Stored Procedure and etc.

Process Explorer

Another tool from our Sysinternals’ friends, after using this tool for the first time, I could not get used to the Task Manager anymore. Really , there is no way to compare, I even think that this tool should be incorporated to the next Windows releases as it has so much to offer.

XmlPad

If you don’t want to spend money with XmlSpy but still don’t feel quite comfortable with Notepad++ to work with XML documents, then XmlPad might be a good alternative for you. Of course, XmlPad is not as light as Notepad++ however, it will make you forget about XML Spy if you don’t really need super advanced features.

QuickCounters

Not a tool per se, however I though interesting including it on this list as this .Net Library comes with a Windows App that can be used to monitor custom performance counters. If the native Windows Performance Counters don’t meet your requirements and you would like to easily create custom counters from your managed apps then check this link out.