Release 8.4.1

Aug 23, 2021. Release 8.4.1 allows you to Secure Decision Service using JWT Authentication and SSL communication. We provide a new tutorial “Securing OpenRules Decision Services” accompanied to concrete examples. Release 8.4.1 also provides business users with an additional control over input and output of their decision models allowing them to validate, include or exclude certain decision variables in the incoming/outgoing JSON structures. These features have been implemented at the requests of our large corporate customers who use OpenRules-based RESTful decision services in highly secured production environments.

Securing Access to OpenRules Decision Service with JWT Authentication

The most common way to secure access to the generated RESTful web service is to use JWT-based authentication.  JWT (JSON Web Token) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. OpenRules 8.4.1 includes a new project “VacationDaysSpringBootSecure” in the standard workspace “OpenRulesDecisionManager” that demonstrates how to secure access to a SpringBoot-based Decision Service using JWT Authentication.

Enabling HTTPS for Decision Service REST Endpoint

In the same tutorial, we will explain how to configure Spring-based OpenRules decision service to use encrypted communication between client and service with HTTPS protocol.

While these examples utilized commonly used Spring Security, OpenRules decision services can be similarly secured inside any development and deployment environment used at your organization.

Glossary Column “Used As”

OpenRules 8.4.1 allows business users to use the standard Glossary to set certain restrictions on the input and output decision variables. They may add an optional column “Used As” into the Glossary to set specify certain restrictions on the decision variables using the following properties or their combinations:

  • in – defines a variable as the decision model’s input
  • required – states that the input variable must have a value
  • out – defines the variable as the decision model’s output
  • const – defines the variable as a constant.

Here is an example:

Only decision variables “Id” and “Vacation Days” marked as “out” will be included into the response produced by this decision model. If your glossary doesn’t include the column “Used As”, then all decision variables (except those defined in the Glossary’s formulas) will be included in the output. 

Glossary Column “Default Value” 

You also can add another column “Default Value” to set default values of some decision variables when they are not defined. For instance, in this glossary

decision variable “Start Date of Service” is a required input variable of the type Date. If its actual input value is null, then the date 1/1/2017 will be used. The constants MaxAge and MinAge are specified as 120 and 16 and can be used in decision tables as regular decision variables instead of hard-coded numbers. Decision variables “Age in Years” and “Years of Service” have a special indicator “:=” in the column “Business Concept”. It means the values their values will be calculated by using formulas (Java snippets) specified in the 3rd column.

Context-Specific Columns “Used As”

Sometimes our customers want to treat the same decision variables differently in different contexts. For example, when the above decision service is invoked from “Premise” you may want to show all involved decision variables in its response . However, when it is invoked from “Cloud” you want the response to include only  Employee’s Id and the calculated vacation days and omit all other variables. It can be important for performance and/or security reasons. To achieve this, you may use two different “Used As” columns, one for “Premise” and another for “Cloud”. We also may add a special decision variable “Invocation Source” with possible values  “Premise” or “Cloud”. Here is the properly adjusted glossary:

You can see, a new decision variable “Invocation Source” belongs to the business concept “Settings” with the default value “Premise”. The column “Used As” has been replaced by two columns: “Used As for Premise” and ”Used As for Cloud”. To direct OpenRules which UsedAs-column to choose, we can use the following decision table with the predefined name “UsedAsSelector”:

Now, OpenRules will dynamically decide which Used As-column to use based on the value of the decision variable “Invocation Source”. It will select “Used As for Cloud” if Invocation Source is Cloud and “Used As for Premise” in all other cases. In this decision table you can use any decision variable instead on “Invocation Source” (or even combinations of decision variables) and use any UsedAs-list specified in the glossary. Only the name of the decision table “UsedAsSelector” is predefined.

A new decision project “VacationDaysWithAdvancedUsedAs” has been added to the standard workspace “OpenRulesSamples” to demonstrate  how the use of multiple Used As lists. Read more at this post.

New Project Properties

New properties can be added in the file “project.properties”:

  • jackson.default-property-inclusion – it can take the following values:
    • non_null – the default value meaning only variables with non-null values will be included in the decision service response
    • always meaning all variables will be always included in the decision service response independently of their values (of course, unless they are specified as ‘out‘ in the Glossary column “Used As”)
    • non_default meaning only variables with non-default values will be included in the decision service response. The default values for numbers are 0, for Booleans – false, and String – “”, and for all other types – null
    • non_empty similar to non_null but additionally it will ignore empty String variables.
  • jackson.default-object-inclusion – it can take the following values:
    • non_null – the default value meaning only objects that contain non-null properties will be included in the decision service response
    • always meaning all objects with at least one ‘out‘ property (even if it is null) will be included in the decision service response.
  • jackson.serialization.write_dates_as_timestamps – it allows you to change the default way for presentation of dates in the generated JSON files and in the decision service response:
    • true – the default value meaning all Dates will be represented as numbers of milliseconds since January 1st, 1970
    • false – all Dates will be represented using a more user-friendly Date timestamp defined by ISO 8601 such as 2021-08-22T17:05:27+00:00.
  • model.endpoint – it allows you to define custom names for your deployed decision services. You also may define this property in the Environment table.

Installation and Support

As usual, after you install a new release of OpenRules Decision Manager, the only change you need to make in your decision projects is to change OpenRules version in your pom.xml file. If you have any issues securing OpenRules decision services, direct all your technical questions to support@openrules.com.