Need to establish Database connectivity in DRL file

Question

Need to establish Oracle database connectivity in drools to get some data as and when required while executing the rules. How do I go about that?

Answer 1

You shouldn't do this. Instead, you should query your data out of the database first, then pass it into the rules as facts in working memory.

I tried to write a detailed answer about all the reasons you shouldn't do this, but it turns out that StackOverflow has a character limit. So I'm going to give you the high level reasons.

1. Latency
2. Data consistency
3. Lack of DB access hardening
4. Extreme design constraints for rules
5. High maintenance burden
6. Potential security issues

---

Going in order ...

Latency. Database queries aren't free. Regardless of how good your connection management is, you will incur overhead every time you make a database call. If you have a solid understanding of the Drools execution lifecycle and how it executes rules, and you design your rules to explicitly only query the database in ways that will minimize the number and quantity of calls, you could consider this an OK risk. A good caching layer wouldn't be amiss. Note that having to properly design your rules this way is not trivial, and you'll incur perpetual overhead in having to make sure all of your rules remain compliant.

(Hint: this means you must never ever call the database from the 'when' clause.)

Data consistency. A database is a shared resource. If you make the same query in two different 'when' clauses, there is no guarantee that you'll get back the same result. Again, you could potentially work around this with a deep understanding of how Drools evaluates and executes rules, and designing your rules appropriately. But the same issues from 'latency' will affect you here -- namely the burden of perpetual maintenance. Further the rule design restrictions -- which are quite strict -- will likely make your other rules and use cases less efficient as well because of the contortions you need to pull to keep your database-dependent rules compatible.

Lack of hardening. The Java code you can write in a DRL function is not the same as the Java code you can write in a Java class. DRL files are parsed as strings and then interpreted and then compiled; many language features are simply not available. (Some examples: try-with-resources, annotations, etc.) This makes properly hardening your database access extremely complicated and in some cases impossible. Libraries which rely on annotations like Spring Data are not available to you for use in your DRL functions. You will need to manage your connection pooling, transaction management, connection management (close everything!), error handling, and so on manually using a subset of the Java language that is roughly equivalent to Java 5.

This is, of course, specific to writing your code to access the database as a function in your DRL. If you instead implement your database access in a service which acts like a database access layer, you can leverage the full JDK and its features and functionality in that external service which you then pass into the rules as an input. But in terms of DRL functions, this point remains a major concern.

Rule design constraints. As I mentioned previously, you need to have an in-depth understanding of how Drools evaluates and executes rules in order to write effective rules that interact with the database. If you're not aware that all left hand sides ("when" clauses) are executed first, then the "matches" ordered by salience, and then the right hand sides ("then" clauses) executed in order sequentially .... well you absolutely should not be trying to do this from the rules. Not only do you as the initial implementor need to understand the rules execution lifecycle, but everyone who comes after you who is going to be maintaining your rules needs to also understand this and continue implementing the rules based on these restrictions. This is your high maintenance burden.

As an example, here are two rules. Let's assume that "DataService" is a properly implemented data access layer with all the necessary connection and transaction management, and it is passed into working memory as a fact.

rule "Record Student Tardiness"
when
  $svc: DataService() // data access layer
  Tardy( $id: studentId )
  $student: Student($tardy: tardyCount) from $svc.getStudentById($id)
then
  $student.setTardyCount($tardy + 1)
  $svc.save($student)
end

rule "Issue Demerit for Excessive Tardiness"
when
  $svc: DataService() // data access layer
  Tardy( $id: studentId )
  $student: Student(tardyCount > 3) from $svc.getStudentById($id)
then
  AdminUtils.issueDemerit($student, "excessive tardiness")
end

If you understand how Drools executes rules, you'll quickly realize the problems with these rules. Namely:

• we call getStudentById twice (latency, consistency)
• the changes to the student's tardy count are not visible to the second rule

So if our student, Alice, has 3 tardies recorded in the database, and we pass in a new Tardy instance for her, the first rule will hit and her tardy count will increment and be saved (Alice will have 4 tardies in the database.) But the second rule will not hit! Because at the time the matches are calculated, Alice only had 3 tardies, and the "issue demerit" rule only triggers for more than 3. So while she has 4 tardies now, she didn't then.

The solution to the second problem is, of course, to call update to let Drools know to reevaluate all matches with the new data in working memory. This of course exacerbates the first issue -- now we'll be calling getStudentById four times!

Finally the last problem are potential security issues. This really depends on how you implement your queries, but you'll need to be doubly sure you're not accidentally exposing any connection configuration (URL, credentials) in your DRLs, and that you've properly sanitized all query inputs to protect yourself against SQL injection.

---

The right way to do this, of course, is not to do it at all. Call the database first, then pass it to your rules.

As an example, let's say we have a set of rules which is designed to determine if a customer purchase is "suspicious" by comparing it to trends from the previous 3 months' worth of purchases.

// Assume this class serves as our data access layer and does proper connection, 
// transaction management. It might be something like a Spring Data JPA repository,
// or something from another library; the specifics are not relevant.
private PurchaseService purchaseService; 

public boolean isSuspiciousPurchase(Purchase purchase) {
    List<Purchase> previous = purchaseService.getPurchasesForCustomerAfterDate(
        purchase.getCustomerId(),
        LocalDate.now().minusMonths(3));

    KieBase kBase = ...;
    KieSession session = kBase.newKieSession();
    session.insert(purchase);
    session.insert(previous);
    // insert other facts as needed
    session.fireAllRules();

    // ...
}

As you can see, we call the database and pass the result into working memory. Then we can write the rules such that they do work against that existing list, without needing to interact with the database at all.

If our use case requires modifying the database -- eg saving updates -- we can pass those commands back to the caller and they can be invoked after the fireAllRules is completed. Not only will that keep us from having to interact with the database in the rules, but it'll give us better control over our transaction management (you can probably group the updates into a single transaction, even if the originally came from multiple rules). And since we don't need to understand anything about how Drools evaluates and executes rules, it'll be a little more robust in case a rule with a database "update" is triggered twice.

Answer 2

You can use function like below to get details from DB. Here I have written function in DRL file but its suggested to add such code in java file and call specific method from DRL file.

function String ConnectDB(String ConnectionClass,String url,String user, String password) {
 
    Class.forName(ConnectionClass);
    java.sql.Connection con = DriverManager.getConnection(url, user, password);
    Statement st = con.createStatement();
    ResultSet rs = st.executeQuery("select * from Employee where employee_id=199");
    rs.first();
  return rs.getString("employee_name");
        
}

   
rule "DBConnection"
 when
      person:PersonPojo(name == ConnectDB("com.mysql.jdbc.Driver","jdbc:mysql://localhost:3306/root","root","redhat1!"))
 .. .. 
 then
   . . .. 
 end