Architecture

OpenRules’s main objective is to help customers to represent, maintain, and effectively execute complex business logic. Its architectural approach is to be a “good citizen” of any modern software environment on-cloud or on-premise. The following architectural diagram explains how OpenRules Decision Manager helps enterprises to design, deploy, and execute operational decision services:

Decision Model Design. Business analysts (subject matter experts with no programming experience) use OpenRules to create, test, and maintain business decision models. They use their favorite tool (Excel or Google Sheets) as a  rule editor to represent their business logic in inter-related decision tables placed in Excel files distributed between different folders – see examples of business decision models here. They also create test cases directly in Excel.  When business analysts click on the provided batch file “run.bat”, OpenRules internally converts an Excel-based model into highly efficient Java code and applies a highly powerful Decision Engine to execute it against the provided test cases. It produces the decisions with detailed explanations in HTML.

Deployment and Execution. Tested business decision models can be easily integrated in any Java application using a simple Java API, used on any server like Apache Tomcat or IBM WebSphere, or being deployed on cloud as a decision microservice utilizing any serverless architecture provided by  major cloud vendors such as Amazon, Google, Microsoft, or IBM. See different deployment options here.

After putting your business decision models in production with flexible pricing options,  your business analysts continue to maintain their original decision model mainly in Excel, and automatically re-deploy them whenever necessary.

Architecture Diagram for “Pay-As-You-Go” Service. When you subscribe to our AWS SaaS Subscription, you still may deploy your business decision model the way you prefer: as AWS Lambda Function, RESTful Web Service, Docker Container, or locally using Java API. Every time when your application executes an OpenRules-based decision service this execution will be reported to AWS Metering Service for the correct billing at the end of each month. Here is the high-level architectural diagram:

A more detailed diagram of the OpenRules Tracker for AWS Marketplace can be found here.

Note. When you purchase an Yearly Subscription, your development software and run-time services would not talk to AWS Metering service – it might essentially minimize the networking overhead.