JBoss Drools Business Rules
JBoss Drools Business Rules
The figure shows the sample rules that I came up with. The first
three columns are the 'when' part of our business rule or the LeftHand Side (LHS). The last (fourth column) is the 'then' part, also
known as the Right-Hand Side (RHS).
For example, the first record in the table says:
When the Finance department sees that we've sold more than
30,000 Chocolate Crunchie bars, then they should Order more
chocolate.
In general, these business systems do three things:
1. Capture information, for example, via a web interface
(presentation layer).
2. Apply business knowledge to this information (business layer).
3. Store or forward this information (service or data layer).
There is no clearly delineated place to put the business logic, A
rule engine can solve these problemsat least to some extent.
A rule engine allows us to 'run' these business rules into the rest of
our bigger computer system so that we can get our values from a
web page, save the results into a database, or anything else we
need to do with our information.
Rule engine - a place in which we can evaluate our business rules.
Rule engines allow you to say "what to do", not "how to do it".
Logic at Rules Engine and data at Database
Speed and scalability - Rule engines work based on the Rete
algorithm proven to be faster and more scalable than most
traditional hand coded 'ifthen' solutions..
Auditing Rules System provide an explanation facility allowing
you to audit how and why a particular decision was made.
Example: When Mail Subject contains JBoss Rules -> Move
Message to Folder Rules
BRMS (Guvnor)
BRMS is a web page allows you to enter your knowledge as
business rules via a web page.
This web-based application can also be used to manage other
things such as deployment, testing, and processes.
BRMS Provides:
Team editing
Version management of rules and related assets
Asset management
A deployment mechanism
Security (Login)
Import and export of data
Parts of the solution
Rules editor
This is the choice of BRMS, IDE, Decision Table, or plain text file. All
produce a similar underlying rule language. The mechanism for
deploying these rules (RuleAgent or some other equivalent) is
similar.
Rules compiler
To translate the near-English rules language into something the
rules engine can understandthis is what the compiler does.
Runtime
As the information flows through your system, something has to be
applied to the (compiled) rules. This is where the Drools runtime
comes in.
Fact model
We have a working system with information flowing from the Web,
modified by the rules, and then saved in the database. The
middle left
Three green '+' icons next to the When, Then, and Options
sections to add more constraints or consequences
Multiple '-' icons (next to the textboxes) allowing you to
delete existing constraints or consequences
Options that describe the rule; for example, is it part of a
process flow, is it enabled, and the date that it is effective
from
Buttons (near the bottom), used to view the source (View
source) and
validate the rule (Validate)
A space (at the bottom of the screen) to allow (optional)
information about the rule to be specified
On the righthand side of the screen, you will find the following
features:
The View Source button allows you to see (but not edit) the rule
that is created for you.
Technical rules
Note that this text-based rule follows the same "whenthen"
format.
when
$driver : Driver ( driverID : id )
$supple : SupplementalInfo ( driverId == driverID,
glassCoverage == true)
then
$driver.updateInsuranceFactor( 1.05 );
System.out.println("Driver wants glass coverage: " +
$driver.getInsuranceFactor());
In plain English:
When
There is a Driver
And that Driver has requested glass coverage
Then
Update the driver's insurance factor
Print a message saying that the driver wants coverage
Creating a new rule
This menu allows you to create new technical and business rules
It also allows you to create DSL-based rules (a way of writing nearEnglish business rules), Decision Tables (an Excel-like format for
business rules), and test scenarios (to make sure that your rules
work the way you intend them to).
Packages
Packages are like folders. They are a way of organising rules and
assets. The difference between packages and directories comes at
deployment time, when everything in one package gets deployed
at the same time. Opening the package (org | acme | insurance |
base) shows you all of the assets available in the package. Most of
these concepts (business rules, technical rules, DSL, models, rule
flows, and test scenarios) are familiar, but there are two new
items: Functions and Enumerations. We might want to call
Functions, which are useful for calculations and the like, from the
rules. Enumerations are lists of values that we can use in our rules.
select the main package (base), you will be able to see a summary
of the package details.
Deployment
It gets your rules and assets from the Guvnor editor and puts them
into the production systems.
The Deployment tab allows you to control when your rules are
released to the end users. It also allows you to view previous
deployments.
In Guvnor, select the Rules tab, click on the Create new dropdown,
and then select New DRL (technical rule). A new screen will appear.
when
eval(true)
then
System.out.println("Hello world");
end
Enter a Name, Package, Initial description and then press OK. The
scenario-editing screen will then be displayed.
This screen has three green '+' signs that we use to set up our
scenario. From top to bottom these are:
GIVEN allows us to set our inputs (that is, create a scenario in
which we know a business rule will fire)
EXPECT allows us to inspect the output after the rule has fired,
to make sure that it has worked correctly
globals allows us to pass in environmental variables that the
rule may need