1

I have a use case that requires me to know what fields were matched in a decision table and which fields were not matched. I know Drools uses algorithms to identify the matches efficiently and it is not a procedural approach where it checks field after the other, but I am still wondering if it is possible to identify the matching at a field level.

To illustrate on it using a simplified example, consider the following Decision Table: Sample Decision Table

Now, assume that I am using the REST API to submit my facts to obtain the decisions. If I send the following facts:

  1. Vehicle Type: Car
  2. Size: Sedan
  3. Manufacturer: Nissan
  4. Year Built: 2015

I will not find any match because there is no matching rule that covers year 2015. However, I would like to know that Drools found match(es) for Vehicle Type, Size, and Manufacturer, yet failed to find a match for the Year Built: Here is a little illustration.

What are the suggested approaches to handle this use case?

ZRISP
  • 11
  • 1
  • What an interesting problem. Off the top of my head you could use partial rule inheritance and then see which rules match; the partial matches would show that you found Car/Size/Manufacturer matches but no Car/Size/Manufacturer/Year. Not sure how you'd do that in a decision table, though. – Roddy of the Frozen Peas Jun 18 '20 at 05:44
  • you can 'mock' the year and see whether the whole rule will be triggered and judge about other fields – Mike Jun 18 '20 at 05:56
  • Thanks for the replies. Inheritance was considered, but the problems with it are rules management overhead, and more importantly, the rules turn into more like procedural. As about the "mock" year, do you mean if rules engine doesn't find any match, call it again and pass a year known to exist? as such, it is evident that year is the problem? The issue I see here is I have much more fields in the real implementation, so this could be impractical. – ZRISP Jun 18 '20 at 08:43
  • I was talking about single isolated test, not a real environment. Your table data is there to populate your model classes with setters and getters. You can mock desired getter(s) to return the data you need and override those in a table so that to trigger the rule and confirm other fields matched or reveal the opposite. – Mike Jun 18 '20 at 15:15
  • @Mike in other words, what you are proposing is 1. Call the rule, and if no match was found, then 2. Call the rule again with a value of a field I know should exist, if a match was found, then this is the unmatched field, if not, then, 3. Try the next field, and so on Is my understanding correct? – ZRISP Jun 25 '20 at 07:13
  • I'm proposing to use [mocks](https://mkyong.com/unittest/unit-test-what-is-mocking-and-why/) for testing the simpler way the better – Mike Jun 25 '20 at 09:13
  • @ZRISP, do you know you can simply create unit test for your scenario for decision table? Here is an [example](https://stackoverflow.com/questions/62097561/need-to-add-multiple-items-in-list-decision-table-drools/62123592#62123592). You can create objects (could be mocks) to fit your usecases and assert proper rules being triggered. – Mike Jun 25 '20 at 16:26

0 Answers0