RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Programming with the Microsoft Business Rules Framework : Page 9

Learn how to decouple the business rules within your application to yield high organizational visibility and accountability.

Understanding Forward Chaining
I have (hopefully) kept things relatively simple, and by now you should have a good understanding of the Microsoft Business Rules Framework and BRE fundamentals. One topic I have not talked about in detail is forward chaining.

The Rule Engine class takes a policy (rule set) as an argument and determines which rules are applicable given the facts, translates the rules from BRL to in-memory object graphs, and executes the appropriate rules.

Suppose your company introduces a new business rule that ensures that the combination of the preferred member discount and any current sales discounts do not cause the final price to fall below margin. This is important, because it ensures that the preferred membership program doesn’t inadvertently cost the company money.

Such a business rule might be: "If the discount percentage on an order would cause the unit price to fall below margin, adjust the discount percentage accordingly."

While that may initially sound complex, it is really very simple. This rule needs to be considered only when a discount percentage is present. Non-preferred customers rarely have discounts unless they use a discount code.

The Customer Discounts Policy would prioritize the existing rules such that the 10 percent discount rule fires first. Only after the Discount Percentage fact slot gets updated would the margin protection rule be considered. When a customer receives no discount, the Discount Percentage remains null; however, if the fact changes as a result of a preceding rule, new rules must be considered. In other words, the BRE would complete two cycles. The second cycle would fire as a result of the Discount Percentage fact being changed, and thus cause a forward chaining of execution.

Play by the Rules
You've seen an overview of rule-based engine technology using Microsoft’s Business Rules Engine implementation, which is based on the Microsoft Business Rules Framework.

You saw how development can use an emergent approach by building the customer check-out functionality in the sample application using Visual Studio 2008 and test-first development. You worked with the Business Rules Composer to create a policy and a rule, and tested the policy before deploying it to the Rule Repository.

You then leveraged the .NET Microsoft BRE API to integrate the policy you created and verified the correct behavior by running the unit test within Visual Studio.

While one of the strengths of implementing a rule-based engine is the ease of working with and deploying rules, it is very important to understand that a rule-based engine such as Microsoft BRE does not eliminate the need for strong application lifecycle management policies. While team and organizational productivity will increase significantly by leveraging the BRE, the fact that business rules can be updated with ease can also be a dangerous thing.

Organizations that effectively leverage a rule-based engine like Microsoft BRE have likely evolved to a higher level of thinking that makes rule management service-oriented. The decoupling and isolation of rules and policies from constituent applications fixes many old problems—but also introduces new challenges around change management, because a change in one rule can have widespread organizational impact, depending on the number of applications that integrate with the given policy. For this reason, it is critical to maintain development, integration, and testing environments for integrating rule changes—nothing changes here.

As an added bonus, if you and your team practice test-driven development, regression testing a policy change should be as simple as running corresponding batteries of unit tests manually or in the next automated build. While not a silver bullet, this is definitely one step forward in increasing business and IT alignment because the rules are centralized, transparent, and support flexible applications that are not only ready for change, but built for it!

One final word of advice: It is very important to understand that despite the compelling productivity improvements that Microsoft BRE can bring, I do not recommend embarking on a project whose sole purpose is to integrate a rule-based engine within the enterprise. Such a project is doomed to fail; technology projects for technology’s sake rarely provide convincing evidence of value in and of themselves. The key with any software or IT project is to focus on delivering business value. Services, SOA, and high-performing rule engines such as Microsoft BRE are merely one vehicle for doing so. Don’t confuse the two.

The CHAOS report finds that 7 percent of features in an application are always used, and 13 percent of features are used often, and. My advice to you is to work with the business members of your team to identify that sweet spot, and then start simply, with a business process or business rule or two. By taking a middle-out approach, you'll quickly and easily find the processes to which applying business rule flexibility will add significant business value. Think big, start small, prove your business case, and the rest will follow.

Rick G. Garibay is a software architect and seasoned application/system developer with a primary focus on middle-tier components and services.With over seven years experience delivering solutions in various industry sectors, including financial services, automotive retail and environmental health, safety and crisis management, Rick holds various Microsoft credentials including MCAD .NET and is an active speaker and member of the greater Phoenix .NET community.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date