Building Solutions Using the BizTalk 2004 Rules Engine

Manual processes have evolved to Automated process islands (e.g. ERPs!) as a result of evolving business processes we create connected processes (BizTalk2002 - externalising the process outside application) to one that is even more agile using BizTalk2004 (orchestration + business rules)

- Start with the premise that Processes DO CHANGE. Actually, the process tends to be the SAME. It is the policy within that PROCESS that CHANGES.

- Tracking is fundamental to the orchestration and rules.

- The Rules engine is a lightweight .NET application component that can run as an In-process within a BizTalk host.

- Developer will be able to drop a rules engine component into the BizTalk Orchestration designer.

What are rules?
- Basically they are predicates. (i.e. if then )
- Modify business policies (NOT processes) in real-time without rebuilding/redeploying.

Design goals.
- Rules engine can also be hosted in a WinForms component, or wherever!
- Security roles, define who can change these rules.

- Version management is also important; once rules are saved they are saved in SQL server. When they are published the ruleset they become immutable (i.e. they cannot be changed.)

- Rules engines can use English based vocabularies that map to .NET classes, database tables, XML Schemas.

Architecture
- Instantiates the Policy Class... queries the Rules Store... holds rules in the rules cache.

- The Rules engine uses multiple Rules stores (XML / SQL Server / OleDB)

- Forward chaining inference mechanism.... [Finds all true statement.]

- Efficient pattern matching.
- Performance and scalability optimised.

- Eager-match algorithm for smaller rules sets & Microsoft patented algorithm for large rule sets.

Design Patterns
The following design patterns describe when to call the Rules Engine: -

- To dynamically determine which orchestration to call.

- To determine the path within the orchestration. [Using inference]

- To execute logic instead of burying it in the code.

When to use what?
When should you code in the rule policy and when should you code in the orchestration?

Rules.
- When there are a large number of permutations to encode in control.
- Fact-based inference where control cannot be predefined.
- Point-in-time evaluations

Orchestration.
- Workflows that require formal Control structures, long running semantics, and messaging.
- When Control flow is well understood and performance is critical.
- Visibility and tracking are important. (Process rather than policy)