Friday, January 21, 2011

Using Business Rules Engine (I)

Making business rules without messages


The most common way of using business rules is by evaluating a XML message with XPath and return an XML message with more info. The problem is that most of the examples are orchestration dependents: by demanding a compiled DLL with the schemas to be used, they limit the possibilities.
In a project with many orchestrations an easy solution is to make a solution with the schemas, compile, define the rules based on that DLL, and then apply them in the remaining solutions. If it is a small project where schema and orchestration could be on the same DLL, a first compilation is needed for BRE to access the schema. Only then the orchestration can add the rule.

But, what if the message is not important in any direction? What if you just want to use the same rule in all orchestrations without referring each and every DLL?
Scenario: ten distinct schemas. One flow in and one flow out for each. The same tracking rules apply on each direction, depending only on the schema. Here I found a great way of corrupting the principles of the rules.
I recommend this blog because it was the first were I could find any comprehensible info about BRE.

Basic: Policies have versions, on each version one or more rules. By activating different versions different rules can be in use. A rule is divided in condition and actions. A straight-forward "If-Then".

BRE Policy, Versions, Rules


Usually each orchestration has its own rule and each rule is for an orchestration, a direct match.
The trick is to make a single rule, the if always true, and the orchestration will receive information that can be used or not.

The advantage of business rules engine is the low processing time and the changeable ease (copy version, edit, publish and deploy). There are no big processing advantages in using rules this way, but the changing method is still easy and no deployments required.

Making the if always true


Like always, just use the condition 1==1 or something that obvious.
On the actions list, we’ll use an ArrayList to return a list of words.
  • Go to facts explorer window
  • Select .NET classes
  • Right-click and browse .NET Assemblies
  • Select the mscorlib library
  • Press OK

    BRE Search Library


    The library will become available.

    BRE ArrayList Add


    Find ArrayList and the Add() method, and drag it to actions pane as many time as you’ll need.
    Fill in with the key strings and publish the version.

    BRE Actions


    Add to the orchestration variables list one of type ArrayList.
    Go to Orchestration View and right click Variables folder for New Variable
    At new variable define name (in this example rulesArray) and type (<.NET Class…>, mscorlib, ArrayList)
    Create another variable, of type Boolean called generateAck.
    Add Call Rules component and use that variable as destination for the output.

    BRE Cal Rules


    And then at a Expression editor, search for the value and do as you please. In this example, only for the flows listed we’ll generate Ack. The fixed value is the message type that the orchestration mandatorily knows.

    Expression Editor


    For instance we are searching for Purchase Orders, abbreviated PO. Since the rulesArray includes that value, ANY orchestration that has Purchase Orders will set generateAcks as true and therefore record Acks, if the proper code is made.
  • No comments: