Managing Business Rules
Business rules are the specific rules and processes that alter, validate, or direct
messages according to the business needs in an integration solution. Consider
a simple yet typical integration scenario, in which the name and address of an
individual must be passed from a CRM system to a billing system. A business
rule applied to the name and address might state, “For each name and address
pair that moves between these systems, the address must contain a valid zip
To enforce this rule, a developer might write a C# component that accepts
the contents of the message in an XML document or a string. This component
would then check the zip code field to ensure that it exists and is not empty.
The component then would likely check whether the zip code has five charac-
ters and whether those characters are in fact numbers. The component would
then be compiled, tested, and moved to a production environment.
But what if a systems analyst wants to alter the business rule to check that
the zip code belongs to a collection of zip codes within, say, the state of Arizona?
This typically means that the systems analyst will contact another developer,
who will add another method to the code to check each zip code against a col-
lection of zip codes from Arizona. This process would repeat itself every time a
change must be made to this business rule.
As you can see, this process does not scale well. An integration solution
could have hundreds of business rules that need to change on a frequent basis.
This is why integration solution providers such as Microsoft have created rules
engines that allow system analysts, not just developers, to alter rules without