Dynamic Rule Management with Large Rule Base

[Nont Banditwong]

Hi Drools group,

I'm working on a project that requires using Drools with a complex rule set that could potentially exceed 200,000 rules. I'm planning to create these rules dynamically through the Rule Unit API, specifically using SyntheticRuleUnit. I understand from previous threads in this group that the invalidateRuleUnits method in RuleUnitProviderImpl can be used to trigger a rebuild of the rule base.

However, calling invalidateRuleUnits will cause a complete rebuild of all rules, leading to application downtime during the rebuild process. To avoid this, I have the following questions:

1. Is it possible to add, remove, or modify individual rules without rebuilding the entire rule base?
2. Is it possible to pre-build a new version of the rule base before calling invalidateRuleUnits and then switch to the new version, similar to a blue/green deployment? I want to avoid re-deploying the application whenever rules are added, removed, or modified. Ideally, I'd like this to happen at runtime without interrupting the application's operation.

Thank you for your time and insights.

Best regards,

Nont

[Toshiya Kobayashi]

Hi,

> 1. Is it possible to add, remove, or modify individual rules without rebuilding the entire rule base?

It's not possible with RuleUnit.

It's possible with traditional KieContainer and KieScanner.

> 2. Is it possible to pre-build a new version of the rule base before calling invalidateRuleUnits and then switch to the new version, similar to a blue/green deployment? I want to avoid re-deploying the application whenever rules are added, removed, or modified. Ideally, I'd like this to happen at runtime without interrupting the application's operation.

It's not possible with RuleUnit.

It's possible with traditional KieContainer by having different versions for their releaseId (but cannot do 1 and 2 at the same time).

----

RuleUnit is designed for microservice architecture, hence it has immutability nature. I think a blue/green deployment should be achieved at the container level. For example, you would build a container image `1.0.0` of your app with rules. Then you add/remove/modify the rules and build another container image `1.1.0`. Then you can do blue/green deployment with the support of your container environment (e.g. k8s).

Regards,
Toshiya

2025年1月27日月曜日 14:36:33 UTC+9 nont...@gmail.com:

[Nont Banditwong]

Hi Toshiya,

Thank you for your answer!

Would you happen to have an example of using KieContainer and KieScanner to add, remove, or modify individual rules without rebuilding the entire rule base ?

Any examples or pointers would be greatly appreciated.

Thanks,

Nont

[Toshiya Kobayashi]

Hi,

Here is an example.

https://github.com/tkobayas/kiegroup-examples/tree/master/Ex-KieFileSystem-scanner-10.0.0

You will see the rules are updated ("Hello World 2").

Cheers,
Toshiya

2025年1月28日火曜日 19:02:57 UTC+9 nont...@gmail.com:

[Toshiya Kobayashi]

The example is a kind of mixture of 1 and 2.

buildAndInstallRules() builds version 1.0.0 and 1.1.0. This part builds the whole resouces each time, not incremental.

```
buildAndInstallRules(releaseId100, new File("work/Sample1.drl"));
...
buildAndInstallRules(releaseId110, new File("work/Sample1.drl"), new File("work/Sample2.drl"));
```

When KieScanner detects the new version, it updates KieBase with only the diff.

In this test, the ksession is running in a separate thread, so not blocked by the new version build (= similar to blue/green deployment).

If you want to externalize the CPU consumption by buildAndInstallRules() from the same JVM, you can replace it with a kjar maven project like https://github.com/tkobayas/kiegroup-examples/tree/master/Ex-basic-kjar-em-10.0.0

Toshiya

2025年1月29日水曜日 12:38:32 UTC+9 Toshiya Kobayashi:

[Nont Banditwong]

Hi Toshiya,

Thank you for your helpful response. 

I appreciate your time and expertise on this matter.

Thanks, Nont