The following example is a workflow scenario in IBM BAMOE that demonstrates how you can use process definitions to orchestrate your IBM BAMOE decision services. The example of a traffic violations project describes how to use decisions within the processes and how to integrate decisions in an embedded way using the business rule tasks, which must be deployed with a process in the same application.

Note
 IBM BAMOE fully supports Straight-Through-Processing (STP) where processes are integrating decisions without any safe points and without persistence. For more IBM BAMOE examples that use process capabilities, see the references below. Stateful processing is provided as a technology preview (Stateful processs overview) in the 9.1.0 and 9.1.1.

The following diagram illustrates how decisions are integrated with processes:

Image of embedded method to integrate a process with decisions in IBM BAMOE
Figure 1. Embedded method to integrate a process with decisions in IBM BAMOE

To view the complete project, see the process-decisions-quarkus example application for Quarkus.

The example of a traffic violations project describes how to use decisions within processes. Those decisions are then integrated using an embedded form using the business rule tasks. The tasks must be deployed with a process in the same application.

In Kogito, the decisions can be expressed in different domains or assets, such as DMN and DRL. All the assets, including BPMN, DMN, and DRL must be placed in the resources folder.

When the example application is running, there also must be different running processes, such as a process using a business rule task, containing the URL as http://localhost:8080/traffic.

Traffic violations example for embedded method

The traffic violations project is based on the evaluation process of traffic violations. In the traffic violations example, first, the information of the driver is fetched, and based on the fetched information, it is determined whether the driver has a valid driving license using a RuleUnit in a DRL. After the validation of the driving license, the violation evaluation is executed, which is defined as a DMN decision, and the output provides information on whether the driver is suspended or not.

Image of traffic violations example
Figure 2. Traffic violations example

Processes in traffic violation example

In the traffic violations project, the interactions with the defined decisions are executed using the decision engine. Also, the information that is required to execute the decision evaluation must be defined in the Data Assignments property of the business rule task.

Note
 The ID property of a process is used in the REST endpoint generation, which refers to the path that is used to interact with the process.

Also, the classes in the process are used to define the Plain Old Java Objects (POJOs) that enable the interaction between the process and decisions. The process classes include Violation, Driver, Fine.

Decisions in traffic violation example

The traffic violations process contains license validation as a decision that is created using DRL. The license validation consists of rules that are evaluated to verify whether the license is expired or not. The result of the license validation is added to the driver variable. The rule units are declared in the LicenseValidationService.drl file and the rule unit data is added to the LicenseValidationService class.

Example LicenseValidationService.drl file:

unit LicenseValidationService

rule "Is driver license valid"
when
    $driver: /driver[licenseExpiration.after(currentTime)]
then
    $driver.setValidLicense(true);
end

rule "Is driver license expired"
when
    $driver: /driver[licenseExpiration.before(currentTime)]
then
    $driver.setValidLicense(false);
end

query "validation"
  $driver : /driver
end

Example LicenseValidationService class:

public class LicenseValidationService implements RuleUnitData {
    private SingletonStore<Driver> driver;

    public LicenseValidationService() {
        this(DataSource.createSingleton());
    }

    public LicenseValidationService(SingletonStore<Driver> driver) {
        this.driver = driver;
    }

    public void setDriver(SingletonStore<Driver> driver) {
        this.driver = driver;
    }

    public SingletonStore<Driver> getDriver() {
        return driver;
    }

    public Date getCurrentTime() {
        return new Date();
    }
}

After the license validation task, the traffic violations process contains traffic violation as a decision that is created using DMN. The traffic violation decision verifies whether the driver is suspended or not based on the points in the driver’s license.

The traffic violation decision is declared in the TrafficViolation.dmn file.

Image of traffic TrafficViolation.dmn file
Figure 3. Example TrafficViolation.dmn file

Data mapping between a process and decisions

To map the data between a process and decisions, you can align all the attribute names in a Java class, which are used as process variables. If the names of the attributes contain spaces or the names of the attributes are not following Java conventions, then you can use Jackson annotations. The Jackson annotations align the process variables with the data types of the DMN model. For example, in the traffic violations project, the Violation class is mapped with the speedLimit attribute using the @JsonProperty annotation. Therefore, the speedLimit attribute can be integrated with the Violation data type defined in the DMN model.

Violation class defined in the Traffic Violations example:

public class Violation {

    @JsonProperty("Code")
    private String code;

    @JsonProperty("Date")
    private Date date;

    @JsonProperty("Type")
    private String type;

    @JsonProperty("Speed Limit")
    private BigDecimal speedLimit;

    @JsonProperty("Actual Speed")
    private BigDecimal actualSpeed;

    //Getters / Setters
}
Image of violation data type in DMN
Figure 4. Violation data type in DMN

When the driver information is fetched, an external call to a service task is performed to retrieve the driver information from the database. In this case, the service task implementation is performed using the DriverService class. In the Data Assignments, driverId is defined as an input variable and driver is defined as an output variable, consisting of the driver information.

Fetching the driver information leads to the license validation task, which represents the task of calling a DRL service.

Image of license validation task (DRL)
Figure 5. License validation task (DRL)

The properties that are required to be set for the DRL service task include Rule Language, which must be set as DRL and the Rule Flow Group. You can set the value of Rule Flow Group using the following format:

unit: + [the FQCN of the Rule Unit Data class]

For example:

unit:org.kie.kogito.traffic.LicenseValidationService

In this case, the driver variable contains the license validation information.

Image of license validation task data assignments
Figure 6. License validation task data assignments

Similar to the license validation task, the traffic violation task represents the task of calling a DMN service.

Image of traffic violation task (DMN)
Figure 7. Traffic violation task (DMN)

The properties that are required to be set for the DMN service task include Rule Language, which must be set as DMN. Also, you must set the values for Namespace and DMN Model Name` properties as defined in the DMN model, such as TrafficViolation.dmn. For example, you can set the following values:

  • Rule Language: DMN

  • Namespace: https://github.com/kiegroup/drools/kie-dmn/_A4BCA8B8-CF08-433F-93B2-A2598F19ECFF

  • DMN Model Name: Traffic Violation

The input for the traffic violation task includes Driver and Violation variables, and the output includes Suspended and Fine in the Data Assignment property.

Image of Traffic Violation Task data assignment
Figure 8. Traffic Violation Task data assignment

In both cases, whether the driver is suspended or not, the related information is logged in the console.

Running your project

You can start the Quarkus server with the following command in the project root:

mvn quarkus:dev

Then you can check the application Swagger UI at http://localhost:8080/q/swagger-ui/#/

Other examples

For more IBM BAMOE examples that use decisions orchestrated by processes, see the following example applications which are included in the examples package:

  • process-business-rules-quarkus: An example project that shows the use of business rules and processes

  • process-decisions-rest-quarkus: An example project that shows the usage of decisions within processes. The project focuses on how to integrate decisions in a remote way using REST APIs where they can be deployed and decoupled from the process service.

  • process-decisions-rules-quarkus: An example project that shows the usage of decisions within processes. The project focuses on integrating decisions in an embedded way using Business Rule Tasks where they must be deployed together with the process. process-error-handling: A usage scenario of the Error Handling Strategy