You are an experienced rule builder now!
How are conditions processed? All conditions in a rule must be met, before the action is done. That is, each condition is joined by an implied AND operator.
In what order are conditions evaluated? To learn more about the effect of filters, equivalent join conditions, and non-equivalent join conditions on the efficiency of a rule, see Order of Evaluation of Rule Conditions in TIBCO BusinessEvents® Extreme Application Architect’s Guide. Understanding these points helps you design an efficient project.
How can I learn about all these catalog
functions? TIBCO BusinessEvents® Extreme
provides hundreds of catalog functions
for use in rules and rule functions. You can use functions you already
know about by typing the beginning of the name and then using the
completion hints that appear. To learn about more functions, you can open
the Catalog Functions view and browse. To see the tooltip for a function,
hover the mouse over the function name. You can then drag a function into
the editor, as you did in the section called “Add the CreateAccount Rule”. As a reminder, here’s how to
open the Catalog Functions view: Window > Show View > Other
> TIBCO BusinessEvents® Extreme
> Catalog Functions.
![[Note]](images/note.png) | |
See Run-time Inferencing Behavior in TIBCO BusinessEvents® Extreme Application Architect’s Guide. |
Add the FraudDetection rule, typing in
the Source view or Form view, according to your preference. The source
is shown below.
Most of the code is in the conditions. The first condition checks
whether the account is Disabled already.
The first part of the second condition determines if the maximum number of debits was exceeded.
The second part of the second condition checks whether the sum of
all debits in the verification interval is greater than the specified
percentage of the account average monthly balance. The average monthly
balance, for the purposes of this tutorial, is set in the
Account instance created by the
CreateAccount rule.
Example 2.4. FraudDetection Rule Source
// $Revision: 1.1.4.6 $
/**
* @description Fraud detection ruile.
* @author appliance
*/
rule Rules.FraudDetection {
attribute {
priority = 5;
forwardChain = true;
}
declare {
Events.Debit debitevent;
Concepts.Account account;
}
when {
account.status != "Disabled";
//
// Possible fraud if number of debits > 3
//
(History.cardinalityByAccount(account.identifier, null) > 3) ||
//
// Or recent debits > 80% of average monthly balance
//
((account.recentDebitBalance != 0) &&
(((account.recentDebitBalance / account.averageMonthlyBalance) * 100) > 80));
}
then {
//
// Disable the account
//
account.status = "Disabled";
System.debugOut(
"WARNING: Fraud suspected on account "
+ account.identifier
+ ".\n\tNumber of debits within 2 minutes "
+ History.cardinalityByAccount(account.identifier, null)
+ ".\n\t% of average monthly balance debited within 2 minutes "
+ (account.recentDebitBalance / account.averageMonthlyBalance) * 100
+ ".");
}
}
Add the EnableAccount rule. This rule
allows you to change an Account status from
Disabled to Enabled at
run-time.
Example 2.5. EnableAccount Rule Source
// $Revision: 1.1.4.4 $
/**
* @description Re-enable a disabled account.
*/
rule Rules.EnableAccount {
attribute {
priority = 1;
forwardChain = true;
}
declare
{
Events.Enable enableevent;
Concepts.Account account;
}
when {
Account.lookupByIdentifier("write", enableevent.identifier) != null;
account.status == "Disabled";
}
then {
//
// Re-enable the account and reset the balance and history
//
account.status = "Enabled";
account.balance = enableevent.balance;
account.recentDebitBalance = 0;
Object results = History.lookupByAccount("read", "ascending", account.identifier, null);
Concepts.History history = Query.next(results);
while (history != null)
{
Instance.deleteInstance(history);
history = Query.next(results);
}
System.debugOut("INFO: Account "
+ enableevent.identifier
+ " re-enabled, balance set to "
+ account.balance
+ ".");
//
// All done
//
Event.consumeEvent(enableevent);
}
}
Add the DisabledAccount rule . This
rule allows just reports that an account is disabled to the
console.
Example 2.6. DisabledAccount Rule Source
// $Revision: 1.1.4.2 $
/**
* @description Reporting warning on disabled accounts
*/
rule Rules.DisabledAccount {
attribute {
priority = 9;
forwardChain = true;
}
declare {
Events.Debit debit;
Concepts.Account account;
}
when {
Account.lookupByIdentifier("none", debit.identifier) != null;
account.status == "Disabled";
}
then {
System.debugOut("WARNING: Account " + account.identifier + " disabled.");
//
// All done
//
Event.consumeEvent(debit);
}
}
Congratulations! You have now configured the project’s ontology and rules. Now you are ready to configure the Cluster Deployment Descriptor and build the archive for deployment. But before you do, it’s wise to validate and analyze the project, and look at it in the Project diagram.