The Business Rule Composer, illustrated in Figure 1,
is the environment used by business rule authors to create, update,
version, publish, and deploy vocabularies and policies. Policy authors
may also test their policies using the testing tool in the Business Rule
Composer and review the execution output as well as error messages in
the Output window. As mentioned earlier, creating the required
vocabularies is necessary before the rule creation, as the vocabulary
needs to be published before it can be used in a rule. However, if you
like to create your rules top down, you can get around this by simply
creating all the business rules with fake arguments using the taxonomy
of your domain, then start creating the vocabulary following that
nomenclature. The drawback here of course is that you will not be able
to save your policy unless you add and publish the vocabulary and update
the rules with the right facts.
|
Multiple users of the Business Rule Composer can
connect to the shared rule store at the same time. However, the Business
Rule Composer does not prevent users from overwriting each other's
work. Potentially, a user could see a policy or a vocabulary that is out
of sync because another user may have modified the policy or
vocabulary.
|
|
1. Creating Vocabularies
Even if building a vocabulary is not your immediate
concern, you should know how to work with the Facts Explorer, as most of
the tasks there apply to rule development. You can use the XML Schemas,
Databases, and .NET Classes tabs to construct names and drag them into
conditions and actions in the Rule Editor (Woodgate, 2005). Although you
can add facts directly from the XML Schemas, Databases, or .NET Classes
tabs to your rules, it is not advisable to do so. This greatly impedes
the readability of the business rules and thus their future portability.
One of the main advantages of using a Business Rule Engine is
to abstract and package the business rules that are valuable assets to
the IT organization in a highly manageable and portable format.
Introducing facts from different data sources directly into the business
rules creates a dependency between the business rules and those data
sources and hinders the readability of those rules. It is therefore
advisable to create a vocabulary to represent the facts in a
nomenclature relevant to the business rules' domain. While defining
different vocabulary items, the user has the choice to select the item
type as illustrated in Figure 2.
To create a vocabulary item based on a .NET class
member, the .NET assembly containing that class has to be deployed to
the Global Assembly Cache (GAC). The assembly needs to be deployed to
the GAC to ensure that the rule engine can always get to the class
definition at runtime.
|
If you are not able to pass the required messages to a
business policy execution from within an orchestration, ensure that the
XML document type specified while creating the vocabulary item is
valid. The Business Rule Composer is in the habit of simply adding the
document type instead of the fully qualified type name prefixed with all
the namespaces if any.
|
|
2. Creating Rules
Creating a policy to encapsulate related rules is the
first task in rule creation. If you are updating the rules in the
policy or adding onto the existing rules of an already published version
of the policy instead of simply creating a new version and starting
from scratch, copy the latest version of the policy you need to update
and paste it as a new policy version. To create policy rules, you can
drag and drop predicates and vocabulary items from the Facts Explorer
into the IF pane to create conditions and drag and drop functions and
vocabulary items into the THEN pane to create actions. If required,
different priorities can be assigned to different rules to affect the
order of their actions' execution upon their successful evaluation.
Applications executing deployed policies will execute the latest version
of the policy by default. However, they may explicitly execute a
particular version of the policy instead.
|
If you redefine a particular vocabulary item
in a new version of a policy, the rules will not pick up the latest
version. Rules are explicitly bound to the vocabulary item that was
dragged and dropped on the action or condition. This means that if you
update your vocabulary, you need to manually update the rules to use the
new version of the vocabulary. |
