Embedded rules

Decision Tables and Scripting Rules are strong tools for decision making, but they can be even stronger when working together.

Leos Rehacek
Fullstack Developer
?
Learn About
Check icon A checkmark inside a circle signifying "yes" Minus icon A minus inside a circle signifying "no" PROS Icon A plus symbol representing positive aspects or benefits. CONS Icon A minus symbol representing negative aspects or drawbacks.

As a DecisionRules user, you may already know that you can create rules in the form of Decision Tables or Scripting Rules. These two features can be also combined in Rule flow, which is used for more complex rules/conditions. However, it is also possible to call the Decision Table directly from the Scripting rule!

Why is this feature useful?

Decision Tables and Scripting Rules differ in the ease of creating the conditions inside DecisionRules. Decision Tables are designed as user-friendly as possible even for non-technical people. Even though we offer a large set of different operations and operators, sometimes it can happen that it is still not enough for certain more complex use-cases.

For a better picture, imagine the case when you are letting your employees / teams / customers register to your system. But for being registered, for example for certain benefits, the user needs to accomplish some conditions. Sure, the majority of those conditions could be easily specified in Decision Tables. But sometimes there are conditions that must be evaluated within a group of users. And exactly at this moment, embedded rules in Scripting Rules are coming to the scene.

How to call a rule from Scripting Rules

This feature can be used very easily. All you need is to know the ruleID and employ the right method. The method is called solve().

As you can see, the rule is called via DR.solve(ruleId, data, version, SolverStrategy). For more details, see the tutorial in our documentation.

From the previous formula it is now visible that there are other parameters that have to be specified before running the solver. The first parameter, as was mentioned before, is the ruleId. Then obviously you need to have input data for your solver, and then specify the version of the rule you are going to use. The last parameter is the execution strategy (Standard, First match, ...) and you are good to go!

To find out more, check our documentation or log in to the app and try it out on your own.

Thank you for reading!

Enjoyed the read? Let’s take the next step together.