Article

Automating rule-based services with Java and Kogito

June 24, 2021
Automation Java Kubernetes OpenShift Quarkus
Karina Varela
Principal Technical Marketing Manager
Featured image for Red Hat Process Automation.

Business automation today is a constant and critical task for organizations that seek to formalize policies and ensure that they can be executed, maintained, monitored, and applied during daily operations. This article demonstrates how to use the Kogito engine to automate business rules by implementing them in the Drools Rules Language (DRL).

DRL is common in Drools-based projects. To start using it with Kogito, you need to understand the concept of rule units. You'll learn how to work with rule units in practice by writing a Java service that automates a piece of business logic with rule units and minimal coding. These capabilities are now part of Red Hat Process Automation Manager 7.11.x, released on June 17.

Note: See How to deliver decision services with Kogito for more about creating a decision service with Decision Model and Notation (DMN) in Kogito and Quarkus.

Automating business rules with Kogito

Bringing all the maturity of Drools, Kogito is an open source project with a lightweight, fast, and cloud-native runtime engine. Developers using Kogito can expect runtime environment improvements and new a tooling set to use along with IDEs like VS Code. Starting with Process Automation Manager version 7.11.x, it is possible to use a supported version of Kogito based on version 1.5.x . You can choose between running decision services with two runtimes: The Red Hat build of Quarkus 1.11.x or Spring Boot 2.3.4.

In Kogito, you can define business rules using Drools Rules Language or decision tables written in the XLS format. If you are familiar with decision tables, you shouldn't notice many differences when using them with Kogito. To use DRL-based rules, however, you need to get used to the concept of rule units.

A rule unit aggregates a set of rules along with a description of the working memory that these rules will act upon, also called data sources. Kogito uses rule units to generate an executable model based on the rules, with a faster startup time. Kogito Codegen also takes advantage of Drools Rules Language queries to discover possible APIs to expose via REST, based on queries defined in the rule unit.

Using rule units in Kogito

We'll get started with Kogito and rule units through a simple example that defines a person and whether that person is an adult.

Start with a POJO (plain old Java object) named Person with the following attributes:

package org.acme.domain;

public class Person {

    private String name;

    private int age;

    private boolean adult;

       // (getters and setters omitted)
}

Next, we can define the rule unit, which we call PersonUnit. It extends the RuleUnitData class org.kie.kogito.rules:


package org.acme;

import org.acme.domain.Person;

import org.kie.kogito.rules.DataSource;

import org.kie.kogito.rules.DataStore;

import org.kie.kogito.rules.RuleUnitData;

public class PersonUnit implements RuleUnitData {

    private DataStore<Person> persons = DataSource.createStore();

    private int adultAge;

    public PersonUnit() {

    }

    //getters and setters omitted

}

Our DRL rule implementation is linked to the rule unit we have just defined by the declaration unit PersonUnit. To write the Is Adult rule, we use OOPath, a version of the standard XPath language that is designed for use with objects. It provides a succinct and readable way to work with DRL.


package org.acme;

unit PersonUnit; //This links this rule back to our RuleUnit

import org.acme.domain.Person;

rule "Is Adult"

when

  $p: /persons[age >= 18]; //Tests the age of any Person object in the datastore persons declared in the rule unit

then

  $p.setAdult(true);

end
query "adult" // Allows Kogito code-gen to expose a domain-driven api to search for adults.

  $p: /persons;

end

As this example shows, Kogito helps business automation developers create lightweight rules services quickly with Quarkus or Spring Boot, package the services traditionally or using native compilation, and even deploy them as functions with KNative on top of Kubernetes and Red Hat OpenShift. For resource planning, Process Automation Manager fully supports OptaPlanner version 8, the most recent version of this machine learning constraint-solver technology.

Related tools and support

If you are interested in trying out Kogito and rule units, check out these places where you can get started:

Note: Also see my previous article, which has more information about using Kogito decision services with Decision Model and Notation (DMN) and creating a decision service with Kogito and Quarkus.

Conclusion

Kogito brings back the joy for business automation developers, who can now quickly develop lightweight rules services, package them traditionally or using native compilation, and even deploy them as functions with KNative on top of Kubernetes and OpenShift. Try it out today, share your feedback, and contribute. The architectural possibilities are endless and flexible to suit on-premises or cloud environments.

Comments