I’ll share our recent real-world experience building decision services capable to handle huge payloads with sound performance. I will describe how putting a decision service into a cloud-based environment supporting parallel execution allowed us to improve the performance 100 times!

Usually input validation is an essential part of business decision models created by OpenRules customers. They add rules that validate input decision variables for null values, empty strings, impossible values like Feb 29 during a non-leap year, and many other problem-specific input errors. These custom error reporting mechanisms usually generate lists of errors with explanations in the JSON response for RESTful decision services. However, while input errors are diagnosed by the decision service, its return code is usually 200 meaning it was a “good” request. In this post I will describe how your service may return code 400 for bad requests.

In this post I will summarize the most popular decision tables supported by OpenRules. All OpenRules tables start with a keyword in the top left corner:

• Decision or DecisionTableSequence
• DecisionTable or DecisionTableSingleHit
• DecisionTableMultiHit