Rule Unit DSL vs RUle Unit DRL
Manivyas Aedulapuram
We have a web UI where teams define rules at runtime. Rule definitions are stored as JSON in a database. On application startup and cache refresh, we load these JSON rules and need to construct RuleUnit instances.
The question is which path to take:
Path A: JSON -> DRL template/generation -> compile -> RuleUnit instance
Path B: JSON -> SyntheticRuleUnitBuilder (Rule Unit DSL) -> RuleUnit instance
Path B is a much better fit for our use case since we skip DRL generation and compilation entirely. But SyntheticRuleUnitBuilder has no official documentation — only test files in the repo. Is this API stable and production-ready?
Regarding the tier-based conflict resolution question — our rules produce outcomes at different severity levels (e.g., DECLINE vs REVIEW). When multiple rules match, the most severe outcome must win.
With traditional KIE we'd use agenda-groups for this. With Rule Unit, we'd handle it in Java after collecting all matches. Just want to confirm there's no built-in equivalent in Rule Unit before we commit to the custom Java approach.
Alex Porcelli
modern, but not as mature as agenda-groups.
> You received this message because you are subscribed to the Google Groups "Drools Usage" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to drools-usage...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/drools-usage/c4119922-abad-4038-9976-7b045b3fe9bbn%40googlegroups.com.
Manivyas Aedulapuram
Thanks Alex, appreciate the direct recommendation.
Some context on our use case that might change the advice:
- Rules are defined at runtime by ops teams via a web UI and stored as JSON in a database. No DRL files on disk — we'd have to generate DRL strings from JSON on every cache refresh.
- Java 21 with virtual threads.
- We need all matched rules per request for telemetry, not just the one that fires.
Our concern with the DRL path is owning the JSON → DRL generation layer (escaping, type handling, debugging generated strings) and KieBuilder.buildAll() being all-or-nothing if one generated DRL is malformed.
With SyntheticRuleUnitBuilder, we skip DRL entirely and each JSON rule becomes a Java predicate, bad rules fail individually, and all matches are collected in one pass. We'd handle conflict resolution in Java (~15 lines) instead of agenda-groups.
Given these constraints, would you still recommend agenda-groups which needs legacy drools Implementation? Or is there a way to use agenda-groups programmatically without DRL generation?
Manivyas Aedulapuram
[edit]
Thanks Alex, appreciate the direct recommendation.
Some context on our use case that might change the advice:
1.Rules are defined at runtime by ops teams via a web UI and stored as JSON in a database. No DRL files on disk — we'd have to generate DRL strings from JSON on every cache refresh.
2.Java 21 with virtual threads.
3.We need all matched rules per request for telemetry, not just the one that fires.[optional, but good to have]
Our concern with the DRL path is owning the JSON → DRL generation layer (escaping, type handling, debugging generated strings) and KieBuilder.buildAll() being all-or-nothing if one generated DRL is malformed.
With SyntheticRuleUnitBuilder, we skip DRL entirely and each JSON rule becomes a Java predicate, bad rules fail individually, and all matches are collected in one pass. We'd handle conflict resolution in Java (~15 lines) instead of agenda-groups.
Given these constraints, would you still recommend agenda-groups which needs legacy drools Implementation? Or is there a way to use agenda-groups programmatically without DRL generation?
Manivyas Aedulapuram
Thank you,
A Manivyas
Alex Porcelli
agenda-groups."
But given your use case, the use of SyntheticRuleUnitBuilder makes
sense. However, it's indeed an internal component that it might change
in the future... but for your case, might be worth the risk.
On Sun, Aug 23, 2026 at 11:14 AM 'Manivyas Aedulapuram' via Drools
Daniel Clark
If this use of the SyntheticRuleUnitBuilder is the best fit for your use case, then chances are it will be useful for somebody else - if not now then in the future. I think your concern about the interface being currently only used for internal purposes is valid.
To view this discussion visit https://groups.google.com/d/msgid/drools-usage/CA%2BNJsVjzXy36%2BNhJjucV4-NdaNgh1-emzz02BzngibMNeszdTQ%40mail.gmail.com.
Manivyas Aedulapuram
Quick follow-up — would using the Executable Model API (PatternDSL) directly be a supported middle ground? We'd get agenda-groups natively while still defining rules as Java lambdas without DRL generation. Is that API stable for external use?
Toshiya Kobayashi
SyntheticRuleUnitBuilder is a relatively new API and is not yet mature. However, it would be great if you could use it if it fits your use case. Feedback is very welcome, as Daniel mentioned. I filed a GitHub issue to add documentation for it: [https://github.com/apache/incubator-kie/issues/6910].
Regarding "the most severe outcome must win," I think handling it in Java after collecting all matches is a natural approach, rather than trying to achieve it with agenda groups.
PatternDSL is not designed for general use by external users, but yes, you can indeed construct rules programmatically with it, just as the Rule Unit DSL does. The PatternDSL API is stable for internal use, but using it directly from application code would be a very advanced use case. I would recommend SyntheticRuleUnitBuilder combined with the custom Java approach.
Toshiya
Manivyas Aedulapuram
Thanks for the clarification and for filing the documentation issue.
In my service service where rules are defined at runtime on UI and stored in a database. At cache refresh, we convert each rule to a Java predicate and register it with SyntheticRuleUnitBuilder using .filter() for LHS conditions and .execute() to collect matches.
A quick question on LHS and RHS Compatibility:: is there any performance difference between a single compound .filter() predicate (all conditions ANDed) versus multiple chained .filter() calls, in terms of PHREAK node optimization?
Toshiya Kobayashi
Toshiya