Detecting Duplicates Using Oracle Business Rules
- by joeywong-Oracle
Recently I was involved with a Business Process Management
Proof of Concept (BPM PoC) where we wanted to show how customers could use
Oracle Business Rules (OBR) to easily define some rules to detect certain
conditions, such as duplicate account numbers, duplicate names, high transaction
amounts, etc, in a set of transactions.
Traditionally you would have to loop through the
transactions and compare each transaction with each other to find matching
conditions. This is not particularly nice as it relies on more traditional
approaches (coding) and is not the most efficient way.
OBR is a great place to house these types’ of rules as it
allows users/developers to externalise the rules, in a simpler manner,
externalising the rules from the message flows and allows users to change them when
required. So I went ahead looking for some examples. After quite a bit of time
spent Googling, I did not find much out in the blogosphere. In fact the best
example was actually from...... wait for it...... Oracle Documentation! (http://docs.oracle.com/cd/E28271_01/user.1111/e10228/rules_start.htm#ASRUG228)
However, if you followed the link there was not much
explanation provided with the example. So the aim of this article is to provide
a little more explanation to the example so that it can be better understood.
Note: I won’t be covering the BPM parts in great detail.
Use case:
Payment instruction file is required to be processed. Before
instruction file can be processed it needs to be approved by a business user.
Before the approval process, it would be useful to run the payment instruction
file through OBR to look for transactions of interest. The output of the OBR
can then be used to flag the transactions for the approvers to investigate.
Example BPM Process
So let’s start defining the Business Rules Dictionary. For
the input into our rules, we will be passing in an array of payments which
contain some basic information for our demo purposes.
Input to Business
Rules
And for our output we want to have an array of rule output
messages. Note that the element I am using for the output is only for one rule
message element and not an array. We will configure the Business Rules
component later to return an array instead.
Output from Business
Rules
Business Rule –
Create Dictionary
Fill in all the details and click OK. Open the Business
Rules component and select Decision Functions from the side.
Modify the Decision
Function Configuration
Select the decision function and click on the edit button
(the pencil), don’t worry that JDeveloper indicates that there is an error with
the decision function. Then click the Ouputs
tab and make sure the checkbox under the List column is checked, this is to
tell the Business Rules component that it should return an array of rule
message elements.
Updating the Decision
Service
Next we will define the actual rules. Click on Ruleset1 on the side and then the Create Rule in the IF/THEN Rule section.
Creating new rule in
ruleset
Ok, this is where some detailed explanation is required. Remember
that the input to this Business Rules dictionary is a list of payments, each of
those payments were of the complex type PaymentType. Each of those payments in
the Oracle Business Rules engine is treated as a fact in its working memory.
Implemented rule
So in the IF/THEN rule, the first task is to grab two
PaymentType facts from the working memory and assign them to temporary variable
names (payment1 and payment2 in our example).
Matching facts
Once we have them in the temporary variables, we can then
start comparing them to each other. For our demonstration we want to find
payments where the account numbers were the same but the account name was
different.
Suspicious payment
instruction
And to stop the rule from comparing the same facts to each
other, over and over again, we have to include the last test.
Stop rule from
comparing endlessly
And that’s it! No for loops, no need to keep track of what
you have or have not compared, OBR handles all that for you because everything
is done in its working memory. And once all the tests have been satisfied we
need to assert a new fact for the output.
Assert the output
fact
Save your Business Rules. Next step is to complete the data
association in the BPM process. Pay extra care to use Copy List instead of the
default Copy when doing data association at an array level.
Input and output data
association
Deploy and test.
Test data
Rule matched
Parting words:
Ideally you would then use the output of the Business Rules
component to then display/flag the transactions which triggered the rule so
that the approver can investigate.
Link: SOA Project Archive [Download]
