Even experienced users of DecisionRules often ask, “Which method should I use to invoke other rule solves from within my rules: the built-in SOLVE function or an API call using the HTTP POST functionality?”. This article will shed some light on the scenarios where each method proves advantageous.
HTTP POST requests offer a versatile method for integrating DecisionRules with external systems. This approach allows any application capable of receiving HTTP requests to interact with DecisionRules. By sending a structured JSON payload from within a rule, users can directly use DecisionRules outputs in other systems of theirs. It can also however be used to make DecisionRules solver calls when configured properly. Such a call goes over the public internet and back to DecisionRules for solving.
The SOLVE function, designed specifically for use within DecisionRules rules. It is particularly useful for creating complex rule orchestration in use cases where Rule Flow might fall short. It internally calls another DecisionRules server via the backbone to solve the specified rule. The function allows dynamic invocation of other rules, using only the target Rule Id (or Alias), the input data, and an optional options object.
Both the SOLVE function and HTTP POST requests ultimately solve the target rule and return the results to the caller rule. However, several key differences merit consideration:
As illustrated above, using the SOLVE() method is very easy while getting the HTTP_POST() method syntactically correct can be bothersome. Unlike the SOLVE() method however the HTTP_POST() method enables us to call rules located in different Spaces than the caller rule because we explicitly provide the call with headers containing the Solver API Key of the target Space. Keep in mind that this can be a security risk as maybe you don’t want your API keys to be accessible by everyone who has access to your rules.
Another major difference is that calls made using the SOLVE() approach count as only one API call as it’s considered an ‘internal’ call, whereas the HTTP_POST() call counts as ‘external’ and thus results in two API calls. This is particularly vital if you’re concerned about hitting your monthly API calls limit.
On the topic of internal and external calls, when your rule solves generate an Audit Log for a rule invoked via the SOLVE() method, the correlationId of said Audit Log will be the same as that of the caller rule. This isn’t the case for the HTTP_POST() method.
Additionally, the SOLVE function offers a convenient path option, allowing users to specify a JSON path to directly retrieve a specific part of the output data. This can simplify the process when only a subset of the rule's output is needed, making the SOLVE function even more efficient and tailored to specific needs.
In almost all cases, using the built-in SOLVE() method is preferable over the HTTP_POST() method. Unless you’re invoking rules located in different Spaces or Environments (for On-Premise solutions), you’re going to want to stick with the easier and more integrated approach of the SOLVE() function.
%20(1).svg){kind=logo}
