OpenRules Release 9.1.0 essentially simplifies how our customers iterate over collections of business objects. Now you may describe your loops in one decision table, immediately see iteration nodes in Decision Diagrams, and analyze the content of each iteration while you are looping over collections inside OpenRules Debugger. Here is a simple loop over an array of Players that accumulates their scores to calculate Team Score:

If in the previous releases every iteration required at least two tables, in Release 9.1.0 one intuitive table is sufficient.

The DMCommunity Challenge July-2022 “Team Performance” gives BR&DM vendors a good opportunity to demonstrate how to handle nested loops. I will describe how it can be done with OpenRules Decision Manager.

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

On December 12, 2021 Apache Log4J 2.x reported that this widely used Java logging framework has been exposed to a serious security vulnerability. OpenRules Decision Manager like many other Java-based products uses Log4J. To mitigate this problem, we quickly switched to the recommended version 2.15.0 of log4j that was supposed to remove the above vulnerability. However, on December 14 the second vulnerability was discovered and Apache released the version 2.16.0 to address the problem.

Based on the seriousness of these events, we decided to create a new emergency release 8.4.3 of OpenRules Decision Manager that uses log4j version 2.16.0 (not 2.15.0). We’ve already built the first version 8.4.3 and it’s going through thorough testing. For urgent situations we made the evaluation version 8.4.3 available from here. Our team will continue to work hard to make sure that well-tested Release 8.4.3 will be available to all customers tomorrow morning. If you have any questions, please contact support@openrules.com.

AWS Lambda has recently extended the capability to track the current state of a function through its lifecycle. In this post AWS wrote: “We’re extending the General Update from September 30 2021 to December 5 2021. The End of Delayed Update date is now also changed to December 6 2021.” With this change, all users of AWS Lambda need to update their AWS SDK-based automation workflows. How would it affect OpenRules-based decision services deployed as AWS Lambdas?

OpenRules provides multiple ways to refer to decision variables inside decision tables and use their values in text expressions. In this post I will use simple examples to explain how to use different expressions inside decision tables.

OpenRules Decision Manager becomes so powerful and easy to use that it dramatically reduces the efforts needed to develop new decision models and deploy them on cloud as decision microservices. Usually everything is done in Excel with our graphical Explorer without any coding. Along with development of large decision-making applications, our team has great practical experience of rapid creation of working prototypes or Proof of Concepts (POC). After a brief meeting with a customer, we quickly (usually within 1-3 days!) put together a POC tested locally and deployed on cloud, so the customer may start testing it remotely without any installations! Continue reading →

Our customers will appreciate the new OpenRules Release 8.4.2 as it essentially improves the validation and consistency checking of their Rule Repositories. It provides much better error diagnostics in business friendly terms. In the Release 8.4.2 we actually implemented a new built-in compiler that runs during the BUILD phase (build.bat), so the majority of errors can be caught before Java code generation. We also added an ability to use CSV-files in situations when XLS-files are too big/slow to handle. We removed Maven Wrapper from all samples and made a free Apache Maven a pre-requisite. Release Notes

The DMCommunity.org Challenge Oct-2021 offers a simple decision model used by our Red Hat colleagues to demonstrate how the DMN standard deals with dates validity. OpenRules similarly follows the DMN standard as shown in the implementation below.

Last week I listened the webinar “The Art of Knowing How to Leverage Decision Intelligence” presented by Roy Schulte, Distinguished VP Analyst at Gartner. Describing the major trends in decision intelligence and why it is growing, Roy concentrated on the question “when to use machine learning, optimization or business rule engines”:

When it comes to handling large collections of data in business rules, OpenRules customers frequently use Excel-based DecisionData tables and/or decision tables of the type “BigTable“. It works fine when Excel tables contain thousands or even tens of thousands rows. However, when an Excel file contains hundreds of thousands rows Excel itself becomes much slower to search and requires much more time and memory to be downloaded in OpenRules. In this case we recommend our customers to switch from the Excel to the CSV format.

OpenRules Decision Manager provides all necessary tools to build, test, and debug your business decision models. The same people (subject matter experts) who created decision models can create test cases for these models using simple Excel tables or objects coming from the outside world (from Java, XML, or JSON). This post explains how to create and use test cases and data tables.

Modern enterprises quickly evolved from monolithic to microservices architectures and they naturally expect that rules-based decision services to be good citizens of the new CI/CD world. My DecisionCAMP-2021 presentation https://lnkd.in/g_rWAazF shares OpenRules experience of developing, integrating, and deploying operational decision microservices which satisfy the requirements of modern enterprise architectures including security, continuous integration and delivery/deployment. Using specific examples, it explains how business analysts may represent and maintain these requirements in their business decision models.
Keywords: Business Decision Models, Decision Microservice, Invocation Context, Authorized access, Security, CI/CD Watch

This is the name of the DMCommunity.org Aug-2021 Challenge that is supposed to predict survivors of the Titanic tragedy based on partially known actual results. Dr. Bob Moore has already submitted a very good analysis of this challenge and applied several ML-based approaches to solve it. It inspired me to ponder the same challenge from a bit different angle. I thought I could try two approaches: 1) using common sense or human prejudice-based rules to predict who could survive; 2) using our very simple Rule Learner to let ML algorithms to do the same. I spent almost the whole day today working on this problem, and this post describes what and how I did. It is interesting to compare the final results:

On Sep 14 I will present “Continuous Digital Decisioning or Operational Decision Microservices in the CI/CD World” at DecisionCAMP-2021. In this presentation we plan to share recent OpenRules experience of developing, integrating, and deploying operational decision microservices which satisfy the requirements of modern enterprise architectures including security, continuous integration and delivery/deployment. Here are two key slides:

Release 8.4.1 of OpenRules Decision Manager is about “Securing OpenRules Decision Services” – click on this link to see the new tutorial that describes how to secure decision services using JWT Authentication and SSL communication. Release 8.4.1 also provides business users with an additional control over input and output of their decision models allowing them to validate incoming JSON requests and choose which decision variables to exclude from the produced responses. Read Release Notes

Being at the heart of any decision model, OpenRules Glossary uses columns “Variable Name”, “Business Concept”, “Attribute”, and “Type” to define all used decision variables. It is recommended to add the optional column “Description” with plain English descriptions of these variables.

Additionally, OpenRules 8.4.1 Glossary may include optional columns “Used As” and “Default Value” that allow you to effectively control the input and output of the decision model. It can be especially important when your decision model is deployed as a RESTful web service, and you want to validate the incoming JSON structure and decide which variables should be included in the outgoing JSON structure.

As OpenRules Decision Manager experiences growing popularity, many potential customers want to develop a POC (Proof of Concept) before committing to our product. Here is our typical POC implementation roadmap:

On June 9 at the DecisionCAMP session Dr. Bob Moore presented his performance comparison results for various solutions to http://DMCommunity.org benchmark. Watch his session at YouTube https://youtu.be/yqmoAUNZA98.

For years many Rule Engine customers were satisfied with their performance as the majority of rule engines delivered in general good performance.  However, the picture changed dramatically in the last 3-4 years when the number of rules-based real-time transactions started to grow from hundreds of thousands or several millions to hundreds of millions per day. The typical execution time of 50-100 milliseconds per transaction what used to be considered as a good performance indicator is not sufficient anymore. Nowadays large customers require the performance that goes down to only a few milliseconds per transaction or in many cases under 1 millisecond. This real-world requirement along with the dramatic shift to cloud-based deployment was the main reason why two years ago we redesigned our Classic OpenRules product and built its new implementation known today as “OpenRules Decision Manager“.