Introducing jBPM’s Human Task recommendation API

In this post, we’ll introduce a new jBPM API which allows for predictive models to be trained with Human Tasks (HT) data and for HT to incorporate model predictions as outputs and complete HT without user interaction.

This API will allow you to add Machine Learning capabilities to your jBPM project by being able to use, for instance, models trained with historical task data to recommend the most likely output. The API also gives developers the flexibility to implement a “recommendation-only” service (which only suggests outputs) as well as automatically completing the task if the prediction’s confidence meets a user-defined prediction confidence threshold.
This API exposes the HT handling to a recommendation service.
A recommendation service is simply any third-party class which implements the org.kie.internal.task.api.prediction.PredictionService interface.

 This interface consists of three methods:

  • getIdentifier() – a method which returns a unique (String) identifier for your prediction service
  • predict(Task task, Map<String, Object> inputData) – a method that takes task information and the task’s inputs from which we will derive the model’s inputs, as a map. The method returns a PredictionOutcome instance, which we will look in closer detail later on
  • train(Task task, Map<String, Object> inputData, Map<String, Object> outputData) – this method, similarly to predict, takes task info and the task’s inputs, but now we also need to provide the task’s outputs, as a map, for training 

This class will consist of:

  • A Map<String, Object> outcome containing the prediction outputs, each entry represents an output attribute’s name and value. This map can be empty, which corresponds to the model not providing any prediction.
  • A confidence value. The meaning of this field is left to the developer (e.g. it could represent a probability between 0.0 and 1.0). It’s relevance is related to the confidenceThreshold below.
  • A confidenceThreshold – this value represents the confidence cutoff after which an action can be taken by the HT item handler.

As an example, let’s assume our confidence represents a prediction probability between 0.0 and 1.0. If the confidenceThreshold is 0.7, that would mean that for confidence > 0.7 the HT outputs would be set to the outcome and the task automatically closed. If the confidence <= 0.7, then the HT would set the prediction outcome as suggested values, but the task would not be closed and still need human interaction. If the outcome is empty, then the HT life cycle would proceed as if no prediction was made.
By defining a confidence threshold which is always higher than the confidence, developers can create a “recommendation-only” service, which will assign predicted outputs to the task, but never complete it.

The initial step is then, as defined above, the predict step. In the scenario where the prediction’s confidence is above the threshold, the task is automatically completed. If the confidence is not above the threshold, however, when the task is eventually completed both the inputs and the outputs will then be used to further train the model by calling the prediction service’s train method.

Example project

An example project is available here. This project consists of a single Human Task, which can be inspected using Business Central. The task is generic and simple enough in order to demonstrate the working of the jBPM’s recommendation API.

For the purposes of the demonstration, this task will be used to model a simple purchasing system where the purchase of a laptop of a certain brand is requested and must be, eventually, manually approved. The tasks inputs are:

  • item – a String with the brand’s name
  • price – a Float representing the laptop’s price
  • ActorId – a String representing the user requesting the purchase

The task provides as outputs:

  • approved – a Boolean specifying whether the purchase was approved or not

This repository contains two example recommendation service implementations as Maven modules and a REST client to populate the project with tasks to allow the predictive model training.

Start by downloading, or alternatively cloning, the repository:

$ git clone git@github.com:ruivieira/jbpm-recommendation-demo.git
 

For this demo, two random forest-based services, one using the SMILE library and another as a Predictive Model Markup Language (PMML) model, will be used. The services, located respectively in services/jbpm-recommendation-smile-random-forest and services/jbpm-recommendation-pmml-random-forest, can be built with (using SMILE as an example):

$ cd services/jbpm-recommendation-smile-random-forest
$ mvn clean install

The resulting JARs files can then be included in the Business Central’s kie-server.war located in standalone/deployments directory of your jBPM server installation. To do this, simply create a WEB-INF/lib, copy the compiled JARs into it and run

$ zip -r kie-server.war WEB-INF

The PMML-based service expects to find the PMML model in META-INF, so after copying the PMML file in jbpm-recommendation-pmml-random-forest/src/main/resources/models/random_forest.pmml into META-INF, it should also be included in the WAR by using

$ zip -r kie-server.war META-INF

jBPM will search for a recommendation service with an identifier specified by a Java property named org.jbpm.task.prediction.service. Since in our demo, the random forest service has the identifier SMILERandomForest, we can set this value when starting Business Central, for instance as:

$ ./standalone.sh -Dorg.jbpm.task.prediction.service=SMILERandomForest

For the purpose of this documentation we will illustrate the steps using the SMILE-based service. The PMML-based service can be used by starting Business Central and setting the property as

$ ./standalone.sh -Dorg.jbpm.task.prediction.service=PMMLRandomForest

Once Business Central has completed the startup, you can go to http://localhost:8080/business-central/ and login using the default admin credential wbadmin/wbadmin. After choosing the default workspace (or creating your own), then select “Import project” and use the project git URL:

https://github.com/ruivieira/jbpm-recommendation-demo-project.git

The repository also contains a REST client (under client) which allows to add Human Tasks in batch in order to have sufficient data points to train the model, so that we can have meaningful recommendations.

NOTE: Before running the REST client, make sure that Business Central is running and the demo project is deployed and also running.

The class org.jbpm.recommendation.demo.RESTClient performs this task and can be executed from the client directory with:

$ mvn exec:java -Dexec.mainClass="org.jbpm.recommendation.demo.RESTClient"

The prices for Lenovo and Apple laptops are drawn from Normal distributions with respective means of 1500 and 2500 (pictured below). Although the recommendation service is not aware of the deterministic rules we’ve used to set the task outcome, it will train the model based on the data it receives. The tasks’ completion will adhere to the following logic:

  • The purchase of a laptop of brand Lenovo requested by user John or Mary will be approved if the price is around $1500
  • The purchase of a laptop of brand Apple requested by user John or Mary will be approved if the price is around $2500
  • The purchase of a laptop of brand Lenovo requested by user John or Mary will be rejected if the price is around $2500 

    The client will then simulate the creation and completion of human tasks, during which the model will be trained.

    SMILE-based service

    As we’ve seen, when creating and completing a batch of tasks (as previously) we are simultaneously training the predictive model. The service implementation is based on a random forest model a popular ensemble learning method.

    When running the RESTClient, 1200 tasks will be created and completed to allow for a reasonably sized training dataset. The recommendation service initially has a confidence threshold of 1.0 and after a sufficiently large number (arbitrarily chosen as 1200) of observations are used for training, the confidence threshold drops to 0.75. This is simply to demonstrate the two possible actions, i.e. recommendation without completing and completing the task. This also allows us to avoid any cold start problems.

    After the model is trained with the task from RESTClient, we will now create a new Human Task.

    If we create a HT requesting the purchase of an “Apple” laptop from “John” with the price $2500, we should expect it to be approved.

    If fact, when claiming the task, we can see that the recommendation service recommends the purchase to be approved with a “confidence” of 91%.

    If he now create a task for the request of a “Lenovo” laptop from “Mary” with the price $1437, he would expect it to be approved. We can see that this is the case, where the form is filled in by the recommendation service with an approved status with a “confidence” of 86.5%.

    We can also see, as expected, what happens when “John” tries to order a “Lenovo” for $2700. The recommendation service fills the form as “not approved” with a “confidence” of 71%.

    In this service, the confidence threshold is set as 1.0 and as such the task was not closed automatically.

    The minimum number of data points was purposely chosen so that after running the REST client and completing a single task, the service will drop the confidence threshold to 0.75.

    If we complete one of the above tasks manually, the next task you create will be automatically completed if the confidence is above 0.75. For instance, when creating a task we are pretty sure will be approved (e.g. John purchasing a Lenovo $1500) you can verify that the task is automatically completed.

    PMML-based service

    The second example implementation is the PMML-based recommendation service. PMML is a predictive model interchange standard, which allows for a wide variety of models to be reused in different platforms and programming languages.

    The service included in this demo consists of pre-trained model (with a dataset similar to the one generated by RESTClient) which is executed by a PMML engine. For this demo, the engine used was jpmml-evaluator, the de facto reference implementation of the PMML specification.

    There are two main differences when comparing this service to the SMILE-based one:

    • The model doesn’t need the training phase. The model has been already trained and serialised into the PMML format. This means that we can start using predictions straight away from jBPM.
    • The train API method is a no-op in this case. This means that whenever the service’s train method is called, it will not be used for training in this example (only the predict method is needed for a “read-only” model), as we can see from the figure below.

    You can verify that the Business Central workflow is the same as with the SMILE service, although in this case no training is necessary.

    The above instructions on how to setup the demo project are also available in the following video (details are in the subtitles):

    In conclusion, in this post we’ve shown how to use a new API which allows for predictive models to suggest outputs and complete Human Tasks.

    We’ve also shown a project which can use different recommendation service backends simply by registering them with jBPM without any changes to the project.

    Why not create your own jBPM recommendation service using your favourite Machine Learning framework, today?

        test (ignore)

        test (ignore)
        //Auto Thumbnail Code
        function joe_auto_thumb(){
        global $post, $posts;
        $first_img = ”;
        ob_start();
        ob_end_clean();
        $output = preg_match_all(‘//i’, $post-&gt;post_content, $matches);
        $first_img = $matches [1] [0];
        if(empty($first_img)){return $first_img= “https://www.shoutmeloud.com/wp-content/uploads/2011/03/sml-125×125-default.jpg”;}
        else {return $first_img;}
        }
        add_action(‘init’, ‘ShoutMeloud_auto_thumb’);
        
        //Auto Thumbnail Code
        function joe_auto_thumb(){
        global $post, $posts;
        $first_img = ”;
        ob_start();
        ob_end_clean();
        $output = preg_match_all(‘//i’, $post->post_content, $matches);
        $first_img = $matches [1] [0];
        if(empty($first_img)){return $first_img= “https://www.shoutmeloud.com/wp-content/uploads/2011/03/sml-125×125-default.jpg”;}
        else {return $first_img;}
        }
        add_action(‘init’, ‘ShoutMeloud_auto_thumb’);
        

        Kogito, ergo Rules — Part 1: Bringing Drools Further

        The Kogito initiative is our pledge to bring our business automation suite to the cloud and the larger Kubernetes ecosystem. But what does this mean for our beloved rule engine, Drools? In this post we introduce modular rule bases using rule units: a feature that has been experimental for a while in Drools 7, but that will be instrumental for Kogito, where it will play a much bigger role. This is the first post of a series where we will give you an overview of this feature (read part 2)

        Bringing Drools Further

        Droolsis our state-of-the-art, high-performance, feature-rich open source rule engine. People love it because it is a swiss-army knife to the many problems that can be solved using rule-based artificial intelligence. But as the computer programming landscape evolves, we need to think of ways to bring further Drools as well. As you may already know, Kogito is our effort to make Drools and jBPM really cloud-native, and well-suited for serverless deployments: we are embracing the Quarkus framework and GraalVM’s native binary compilation for super-fast startup times and low memory footprint; but we are not stopping there.

        The way we want to bring further Drools evolution is twofold: on the one hand, we want to make our programming model easier to reason about, by providing better ways to define boundaries in a rule base with a better concept of module; on the other hand, the concept of modular programming dates back at least to the 1970s and to Parnas’ original seminal paper. Needless to say, if our contribution stopped there, we would be bringing nothing new to the plate. In the last few years, computing has evolved, slowly but steadily embracing the multicore and distributed revolution; yet, to this day, many general-purpose programming languages do not really make it simple to write parallel or distributed programs. rule-based programming system we have the chance to propose something different: a rule engine that is great when stand-alone, but outstanding in the cloud.

        Modular Rule Bases. As you already know, Drools provides a convenient way to partition set of rules into knowledge bases. Such knowledge bases can be composed together, yielding larger sets of rules. When a knowledge base is instantiated (the so-called session), rules are put together in the same execution environment (the production memory), and values (the facts) are all inserted together in the same working memory.

        This model is very simple and powerful but in some senses it is also very limited. It is very simple, because, as a user of the rule base, you just worry about your data: the values are inserted into the working memory, and the engine does its magic. It is very powerful, because, as a rule author, you can rely upon the rules you have written to realize complex flows of reasoning, without worrying about how and when they will trigger.

        At the same time, such an execution model lacks all of the principles, that over the years we have been learning are good programming practice. For instance, there is no proper notion of a module: it is not possible to perfectly isolate one rule from another, or to properly partition the working memory. As the rule base scales up in complexity, it may become harder to understand which rules trigger and why. In some senses, it is as if you were programming in an odd world where proper encapsulation of state does not exist, as if years of programming language evolution had not happened.

        Object-Oriented Programming. The term object-oriented programming has been overloaded over the years to mean a lot of different things; it has to do both with inheritance, with encapsulation of state, with code reuse, with polymorphism. All these terms get often confused, but they are not really related: you can reuse code without inheritance, you can encapsulate state without objects, you can write polymorphic code without classes. Very recent, imperative programming languages such as Go and Rust do not come with proper classes, yet they support a form of object-orientation; there is even a beautiful 2015 talk from C++’s dad, Bjarne Stroustrup, showing how his child supports object-orientation without inheritance.

        Alan Kay, who fathered the term in his Smalltalk days at Xerox, in his inspiring lecture at OOPSLA 1997 said «I made up the term “object-oriented”, and I can tell you I did not have C++ in mind». In fact, the idea of objects that Alan Kay pioneered was more similar to the concept of actors and microservices. In proper object-oriented programming, objects encapsulate their internal state and expose their behavior by exchanging messages (usually called methods) with the external world.

        Today actor systems have seen a renaissance, message buses are very central to what today we call reactive programming, microservices are almost given for granted. So, we wondered, what would it mean for Drools to become a first-class citizen of this new programming landscape?

        Kogito, ergo Cloud

        In the next post we will see our take on rule-based, modular programming, using rule units. Rule units will provide an alternative to plain knowledge base composition and an extended model of execution. We believe that rule units will make room for a wider spectrum of use cases, including parallel and distributedarchitectures. Stay tuned to read how they fit in the Kogito story, and the exciting possibilities that they may open for the future of our automation platform.




        Recent Drools DMN open source engine performance improvements

        We are always looking to improve the performance of the Drools DMN open source engine. We have recently reviewed a DMN use-case where the actual input population of Input Data nodes varied to some degree; this highlighted a suboptimal behavior of the engine, which we improved in recent releases. I would like to share our findings!

        Benchmark development


        As we started running a supporting benchmark for this use-case, especially when investigating the scenario of large DMN models with sparse-populated input data nodes, we noticed some strange results: the flamegraph data highlighted a substantial performance hit when logging messages, consuming very significant time in comparison to the application logic itself.

        This flamegraph highlight specifically that a large portion of time is consumed by stacktrace synthesis, artificially induced by the logging framework. The correction, in this case, was to tune the logging configuration to avoid this problem; specifically, we disabled a feature of the logging framework which is very convenient during debugging activities, enabling to quickly locate the original calling class and methods: unfortunately this feature come at the expense of synthesizing stacktraces, which originally contaminated the benchmark results. Lesson learned here: always check first if non-functional requirements are actually masking the real issue!

        This was a necessary and propaedeutic step, before proceeding to investigate the use-case in more details.

        Improving performance


        Moving on and focusing now on DMN optimizations, we specifically developed a benchmark to be general enough, but also highlighting the use-case which was presented to us. This benchmark consists of a DMN model with many (500) decision nodes to be evaluated. Another parameter controls sparseness of input data nodes valorization for evaluation; ranging from a value of 1 where all inputs are populated, to 2 where only one out of two inputs is actually populated, etc.

        This specific benchmark proved to be a very instrumental tool to highlight some potential improvements. 

        Setting the comparison baseline to Drools release 7.23.0.Final, the first optimization implemented with DROOLS-4204 focused on improving context handling while evaluating FEEL expressions and demonstrated to offer a ~3x improvement, while further optimization implemented with DROOLS-4266 focusing on specific case for decision table input clauses demonstrated an additional ~2x improvement on top of DROOLS-4204.

        We also collected these measurements in the following graphs.


        This graph highlights the compounding improvements in the case of sparseness factor equal to 1, where all inputs are populated; this was a very important result, as in fact it did represent the main, “happy path” scenario in the original use-case.

        In other words, we achieved a ~6x improvement in comparison to running the same use-case on 
        7.23.0.Final. The lesson I learned here is to always strive for these kind of compounding improvements when possible, as they really build on top of each other, for greater results!

        For completeness, we repeated the analysis with sparseness factor equals to 2 (1 every 2 inputs is actually populate) and 50 (1 every 50 inputs is actually populated) with the following measurements:


        Results show that the optimizations were also significant for sparseness factor equal to 2, but not as relevant improvements as this factor grows — which is expected, as the impact of the decision nodes evaluations on the overall logic of execution become now less relevant. 

        For completeness, analysis was also performed with another, already existing benchmark for single decision table consisting of many rules rows:

        Results show that these code changes considered as a whole, still offered a relevant improvement; although clearly not of the same magnitude as for the original use-case. This was another important check to ensure that these improvements were not overfitting on the specific use-case.

        Conclusions


        Considering Drools release 7.23.0.Final as the baseline, and a reference benchmark consisting of a DMN model with many decision nodes to be evaluated, we implemented several optimizations that once combined demonstrated to offer a total of ~6x speed-up on that specific use case!

        I hope this was an interesting post to highlight some of the dimensions were to look into to achieve better performances; let us know you thoughts and feedback.

        You can already benefit today from these Kie DMN open source engine improvements in the most recent releases of Drools! 

        Kogito, ergo Rules — Part 2: An All-Encompassing Execution Model for Rules

        This is the second post of a series of updates on the Kogito initiative and our efforts to bring Drools to the cloud. In this post we delve into the details of rule units and show you why we are excited about them.

        An All-Encompassing Execution Model for Rules

        If you’ve been carefully scrutinising the Drools manual looking for new features at every recent release, you may have noticed that the term rule unit has been sitting there for a while, as an extremely experimental feature. In short, a rule unit is both a module for rules and a unit of execution—the reason why we are not calling them modules is to avoid confusion with JVM modules. In Kogito, we are revisiting and expanding upon our original prototype.
        A rule unit collects a set of rules together with the description of the working memory such rules act upon. The description of the working memory is written as a regular Java class, with DataSource fields. Each data source represents a typed partition of the working memory, and different types of data sources exist, with different features. For instance, in the following example we used an append-only data source, called data stream.

        Rules of a given rule unit are collected in DRL files with the unit declaration

        Each rule in a unit has visibility over all the data sources that have been declared in the corresponding class. In fact, the class and the collection of DRL files of a unit form a whole: you can think of such a whole as of one single class where fields are globals that are scoped to the current unit, and methods are rules. In fact, the use of fields supersedes the use of DRL globals.
        A rule unit is submitted for execution to a scheduler. Rule units may decide to yield their execution to other rule units, effectively putting them into execution. For instance:

        But rule units may be also put in a long-running state. In this case, other rule units may be run concurrently at the same time; because DataSources can be shared across units, units can be coordinated by exchanging messages.
        Consider the following example:

        In a certain way, rule units behave as “actors” exchanging messages. However, in a very distinctive way, rule units allow for much more complex chains of executions, that are proper to rule-based reasoning. For instance, consider this example from Akka’s manual:

        As you can see, pattern matches in Akka are strictly over single messages. This is unsurprising, because actors process one message at a time. In a rule engine, we are allowed to write several rules, reacting upon the entire state of the working memory at the execution time: this significantly departs from a pure actor model design, but at the same time gives a great deal of flexibility in the way you may write the business logic of your application.

        Data Sources

        It is worth to spend a few words on data sources as well. The data source construct can be seen as both a partition and an abstraction over the traditional working memory. Different kinds of data sources will be available: full-featured data stores may support to add, remove and update values, allowing for more traditional operations over the working memory; while the more constrained append-only data streams would be easier to integrate with external data sources and data sinks, such as Camel connectors; such constraints would be also valuable to enable more advanced use cases, such as parallel, thread-safe execution and persisted shared channel (e.g.: Kafka) across nodes of an OpenShift cluster, realizing a fully distributed rule engine.
         

        Kogito: ergo Cloud

        The parallel and distributed use cases are intriguing, but we need to get there with baby steps. However, this does not mean that the first steps won’t be as exciting in their own way.

        For Kogito we want to stress the cloud-native, stateless use case, where control flow is externalized using processes and, with the power of Quarkus we can compile this into super-fast native binaries. This is why in the next few weeks we will complete and release rule units for automated REST service implementation.

        In this use case, the typed, Java-based declaration of a rule unit is automatically mapped to the signature of a REST endpoint. POSTing to the endpoint implies instantiating the unit, inserting data into the data sources, firing rules, returning the response payload. The response is computed using a user-provided query. For instance, consider this example:

        Users may post events using the auto-generated /monitoring-service endpoint.

        the reply will be the result of the query. In our case:

        Cloudy with a Chance of Rules

        We have presented our vision for the next generation of our rule engine in Kogito and beyond. The stateless use case is only the first step towards what we think will be a truly innovative take on rule engines. In the following months we will work on delivering better support for scheduling and deploying units in parallel (local) and distributed (on Openshift), so stay tuned for more. In the meantime, we do want to hear from you about the direction we are taking.

        The future of Drools is cloudy… and bright!

        jBPM monitoring using Prometheus and Grafana


        In this post, we will introduce the new Prometheus Kie Server Extension, which has been released as part of jBPM version 7.21.0.Final. This extension aims to make extremely easy for you to publish metrics about your Kie Server runtime execution. Using Prometheus and Grafana has become a standard for monitoring cloud services these days, and allowing the Kie Server to expose metrics related to processes, tasks, jobs and more, becomes a powerful integration not only for you to get a snapshot of the current status inside the server but also for combining it with information from different sources such as JVM, Linux and more. Not only in terms of infrastructure monitoring, but it is also a great tool to get insights into the execution of your business process.
        To get started with Prometheus, take a look in this overview and the full list of exporters and integrations. Grafana is also another powerful tool that allows you to create nice looking dashboards, combining data from multiple sources, to get started take a look here.
        Here is an example based on the metrics exposed from the Kie Server:


        To enable this new extension, set the Prometheus system property to org.kie.prometheus.server.ext.disabled=false. When you enable this extension, a series of metrics will be collected, including information about deployments, start time, data sets, execution errors, jobs, tasks, processes, cases, and more. For the complete list of metrics, see the Prometheus services repository on GitHub.

        After the extension is started, you can access the available metrics at ${context}/services/rest/metrics.
        For example:

        curl -u wbadmin:wbadmin http://localhost:8080/kie-server/services/rest/metrics
        To quickly demonstrate all the capabilities of this integration, we created a short video, with more details about how to get started, two example dashboards for Grafana, as well as a Docker compose configuration that you can use as a playground to explore all these tools working together.



        Docker compose example configuration is available here and to get started, simply run:

        docker-compose -f jbpm-kie-server-prometheus-grafana.yml up

        After all images start, you have the following tools available:


        To access the example dashboards, please login to Grafana using the default credentials: username admin and password admin. Then navigate to Dashboards -> Manage, in there you should have two examples: jBPM Dashboard and jBPM Kie Server Jobs.


        As you interact with your Kie Server and Business Central instances, like deploying and starting new process instances, you should notice the metrics values changing in the dashboard. Prometheus is configured to scrape data every 10 seconds.

        Hope you have fun monitoring your Kie Server!

        Webinar: Re-imagining business automation: Convergence of decisions, workflow, AI/ML, RPA — vision and futures

        WEBINAR 

        Title: Re-imagining business automation: Convergence of decisions, workflow, AI/ML, RPA—vision and futures

        Time: June 20, 2019, 5:00 p.m. BST (UTC+ 1)

        Registration https://www.redhat.com/en/events/webinar/re-imagining-business-automation-convergence-decisions-workflow-aiml-rpa%E2%80%94vision-and-futures

        drools.js: Towards a Polyglot Drools on GraalVM (with Bonus Tech-Lead Prank)

        Image courtesy of Massimiliano Dessì

        You can find the full source code for this blog post in the submarine-examples repository.

        Different programming languages are better for different purposes. Imagine how hard would it be to query a database using an imperative language: luckily, we use SQL for that. Now, imagine how useless would a rule engine be, if defining rules were not convenient! This is the reason why Drools comes with its own custom language, the DRL. The Drools Rule Language is in a so-called domain-specific language, a special-purpose programming language specifically designed to make interaction with a rule engine easier.

        In particular, a rule is made of two main parts, the condition and the consequence.

        The condition is a list of logic predicates, usually pattern matches, while the consequence is written using an imperative language, usually Java.

        An Abstract Rule Engine

        Rules are what really make a rule engine. After all, that’s what a rule engine does: processing rules. Thus, it might sound kind of logical for the engine to be a bit entangled with the language for rule definitions. Our engine is not specially tied to the DRL; but it used to.

        In the last year or so, we spent a lot of time unbundling the innards of the DRL from the guts of the Drools core. The result of this effort is what we called the Canonical Model; that is, an abstract representation of the components that make up a rule engine, including rule definitions. Incidentally, this also paved the way for supporting GraalVM and the Quarkus framework; but our goal was also different. We wanted to abstract our engine from the rule language.

        Internally, the DRL is now translated into the canonical representation; but, as we said previously, this canonical model is described using Java code. While this representation is not currently intended to be hand-coded, it is very possible to do so. The following is a simple rewriting of the previous DRL rule.

        As you can see, although the rule definition is now embedded in a Java “host” language, it still shows the main features of a DRL definition, namely, the logic condition and the imperative consequence (introduced by the on…execute pair) In other words, this is a so-called embedded or internal domain-specific language.

        A small disclaimer applies: the code above works, but our translator takes extra steps for best performance, such as introducing indexes. In fact, one of the reasons why we do not intend this API for public consumption is that, currently, a naive rewrite like this may produce inefficient rules.

        A Polyglot Automation Platform

        As part of our journey experimenting with our programming model, we wanted to see whether it was feasible to interact with our engine using different programming languages. DRL aside, the canonical model rule definition API is pure-Java.

        But GraalVM is not only a tool to generate native binaries: in fact, this is only one of the capabilities of this terrific project. GraalVM is, first and foremost, the one VM to rule them all: that is, a polyglot runtime, with first-class support for both JVM languages and many other dynamic programming languages, with a state-of-the-art JIT compiler, that easily compares or exceeds the performance of the industry standards. For instance, there is already support for R, Ruby, JavaScript and Python; and, compared to writing a JIT compiler from scratch, the Truffle framework makes it terribly easy to write your own, and fine-tuning it to perfection.

        GraalVM gave us a great occasion to show how easy could it be to make Drools polyglot, and, above all, to play an awful practical joke on our beloved, hard-working, conference-speaking, JavaScript-hating, resident Java Champion and tech lead Mario!

        Enter drools.js:

        And here’s a picture of Mario screaming in fear at the monster we have created



        Jokes aside, this experiment is a window over one of the many possible futures of our platform. The world of application development today is polyglot. We cannot ignore this, and we are trying to understand how to reach a wider audience with our technologies, be it our rule engine, or our workflow orchestration engine; in fact, we are doing the same experiments with other parts of the platform, such as jBPM.

        jBPM provides its own DSL for workflow definition. Although this is, again, work in progress, it shows a lot of promise as well. Behold: jbpm.js!

        Conclusion

        The DRL has served its purpose for a very long time, but we are already providing different ways to interact with our powerful engine, such as DMN and PMML; but power users will always want to reach for finer tuning and write their own rules.

        The canonical model API is still a work-in-progress, and, above all, an internal API that is not intended for human consumption; but, if there is enough interest, we do plan to work further to provide a more convenient embedded DSL for rule definition. Through the power of GraalVM, we will be able to realize an embedded DSL that is just as writable in Java as any other language that GraalVM supports.

        And this includes JavaScript; sorry Mario!

        Quarking Drools: How we turned a 13-year-old Java project into a first-class serverless component

        “The question of whether a computer can think is no more interesting
        than the question of whether a submarine can swim.”
        – Edsger W. Dijkstra
        Rule-based artificial intelligence (AI) is often overlooked, possibly because people think it’s only useful in heavyweight enterprise software products. However, that’s not necessarily true. Simply put, a rule engine is just a piece of software that allows you to separate domain and business-specific constraint from the main application flow. We are part of the team developing and maintaining Drools—the world’s most popular open source rule engine and part of Red Hat—and, in this article, we will describe how we are changing Drools to make it part of the cloud and serverless revolution.

        Technical overview

        Our main goal was to make the core of the rule engine lighter, isolated, easily portable across different platforms, and well-suited to run in a container. The software development landscape has changed a lot in the past 20 years. We are moving more and more toward a polyglot world, which is one reason why we are working to make our technology work across a lot of different platforms. This is also why we started looking into GraalVM, the new Oracle Labs polyglot virtual machine (VM) ecosystem, consisting of:
        • A polyglot VM runtime, alternative to the Java virtual machine (JVM) with a just-in-time (JIT) compiler that improves efficiency and speed of applications over traditional HotSpot. This is also the “proper” GraalVM.
        • A framework to write efficient dynamic programming languages (e.g., JavaScript, Python, and R) and to mix and match them (Truffle).
        • A tool to compile programs ahead-of-time (AOT) into a native executable.
        Meanwhile at Red Hat, another team was already experimenting with GraalVM and native binary generation for application development. This effort has been realized in a new project you may have heard of called Quarkus. The Quarkus project is a best-of-breed Java stack that works on good old JVM but is also especially tailored for GraalVM, native binary compilation, and cloud-native application development.
        GraalVM is an amazing tool, but it also comes with some (understandable) limitations. Thus, Quarkus is designed to integrate seamlessly with GraalVM and native image generation, as well as provide useful utilities to overcome any related limitations. In particular, Drools used to make extensive use of dynamic class generation, class-loading, and quite a bit of reflection. To produce fast, efficient, and small native executables, Graal performs aggressive inlining and dead-code elimination, and it operates under a closed-world assumption: that is, the compiler removes any references to class and methods that cannot be statically reachable in the code. In other words, unrestricted reflective calls and dynamic class loading are a no-go. Although this may at first sound like a showstopper, here we will document in detail how we modified the core of Drools to overcome such limitations, and we will explain why such limitations are not evil and can be liberating.

        The Executable Model

        In a rule engine, facts are inserted into a working memory. Rules describe actions to take when certain constraints over the facts that are inserted into the working memory become true. For instance, the sentence “when the sun goes down : turn on the lights” expresses a rule over the sun. The fact is that the sun is going down. The action is to turn on the lights. In a rule engine, we insert the “sun is going down” fact inside the working memory. When we fire the rules, the action of turning on the lights will execute.
        A rule definition has the form
        constraintsconsequence
        The constraints part, also called the left-hand side of the rule, describes the constraints that activate the rule and make it ready to fire; the consequence part, also called the right-hand side of the rule, contains the action that rule will take when the rule is fired.
        In Drools, a rule is written using the Drools Rule Language (in short, DRL), and it has the form:
        rule R1 when
           $r : Result()                               // constraints
           $p : Person( age >= 18 )     
        then
           $r.setValue( $p.getName() + " can drink");  // consequence
        end
        Constraints are written using a form of pattern-matching over the data (Java objects) that is inserted into the working memory. Actions are basically a block of Java code with a few Drools-specific extensions.
        Historically, the DRL used to be a dynamic language that was interpreted at runtime by the Drools engine. In particular, the pattern matching syntax had a major drawback: it made extensive use of reflection unless the engine detected a constraint was “hot” enough for further optimization; that is, if it had evaluated a certain number of times; in that case the engine would compile it into bytecode on-the-fly.
        About one year ago, for performance reasons, we decided to go away with runtime reflection and dynamic code generation and completed the implementation of what we called the Drools Executable Model, providing a pure Java-based representation of a rule set, together with a convenient Java DSL to programmatically define such model.
        To give an idea of how this Java API looks, like let’s consider again the simple Drools rule reported above. The rule will fire if the working memory contains any Result instance and any instance of Person where the age field is greater or equal to 18. The consequence is to set the value of the Result object to a String saying that the person can drink. The equivalent rule expressed with the executable model API looks like the following (pretty-printed for readability):
        var r = declarationOf(Result.class, "$r");
        var p = declarationOf(Person.class, "$p");
        var rule =
           rule("com.example", "R1").build(
                 pattern(r),
                 pattern(p).expr("e", p -> p.getAge() >= 18),
                 alphaIndexedBy(int.class, GREATER_OR_EQUAL, 1, this::getAge, 18),
                 reactOn("age")),
            on(p, r).execute(($p, $r) ->
                 $r.setValue($p.getName() + " can drink")));
        As you can see, this representation is more verbose and harder to understand, partly because of the Java syntax, but mostly because it explicitly contains lots of details, such as the specification of how Drools should internally index a given constraint, which was implicit in the corresponding DRL. We did this on purpose because we wanted a totally explicit rule representation that did not require any convoluted inference or reflection sorcery. However, we knew it would be crazy to ask users to be aware of all such intricate details, so we wrote a compiler to translate DRL into the equivalent Java code. We achieved this using JavaParser, a really nice open source library that allows to parse, modify, and generate any Java source code through a convenient API.
        In all honesty, when we designed and implemented the executable model, we didn’t have strictly GraalVM in mind. We simply wanted an intermediate and pure Java representation of the rule that could be efficiently interpreted and executed by the engine. Yet, by completely avoiding reflection and dynamic code generation,  the executable model was key to allowing us to support native binary generation with Graal. For instance, because the new model expresses all constraints as lambda predicates, we don’t need to optimize the constraints evaluators through bytecode generation and dynamic classloading, which are totally forbidden in native image generation.
        The design and implementation of executable model taught us an important lesson in the process of making Drools compatible with Graal: any limitation can be overcome with a sufficient amount of code generation. We will further discuss this in the next section.

        Overcoming other Graal limitations

        Having a plain Java model of a Drools rule base was a very good starting point, but more work was needed to make our project compatible with native binary generation.
        The executable model makes reflection largely unnecessary; however, our engine still needs reflection for one last feature called property reactivity. Our plans are to get rid of reflection altogether, but, because the change is nontrivial, for this time we resorted to a handy feature of the binary image compiler. This feature does support a form of reflection, provided that we can declare upfront the classes we will need to reflect upon at runtime. This can be supplied by providing a JSON descriptor file to the compiler, or, if you are using Quarkus, you can just annotate the domain classes. For instance, in the rule shown above, our domain classes would be Result and Person. Then we can write:
        [
         {
            "name" : "org.drools.simple.project.Person",
            "allPublicMethods" : true
         },
         {
            "name" : "org.drools.simple.project.Result",
            "allPublicMethods" : true
         }
        ]
        Then, we can instruct the native binary compiler with the flag
        -H:ReflectionConfigurationFiles=reflection.json
        We segregated other redundant reflection trickery to a dynamic module and implemented an alternative static version of the same components that users can choose to import into their project. This approach is especially useful for binary image generation, but it has benefits for regular use cases as well. In particular, avoiding reflection and dynamic loading can result in faster startup time and improved run-time.
        At startup time, Drools projects read an XML descriptor called the kmodule, where the user declaratively defines the configuration of the project. Usually, we parse this XML file and load it into memory, but our current XStream-based parser uses a lot of reflection; so, first, we can load the XML with an alternative strategy that avoids reflection. However, we can go further: if we can guarantee that the in-memory representation of the XML will never change across runs, and we can afford to run a quick code-generation phase before repackaging a project for deployment, then we can avoid loading the XML at each boot-up altogether. In fact, we are now able to translate the XML file into a class file that will be loaded at startup time, like any other hand-coded class. Here’s a comparison of the XML with a snippet of the generated code (again, pretty-printed for readability). The generated code is more verbose because it makes explicit all of the configuration defaults.
        <kbase name="simpleKB"
               packages="org.drools.simple.project">
          <ksession name="simpleKS" default="true"/>
        </kbase>
        var m = KieServices.get().newKieModuleModel();
        var kb = m.newKieBaseModel("simpleKB");
        kb.setEventProcessingMode(CLOUD);
        kb.addPackage("org.drools.simple.project");
        var ks = kb.newKieSessionModel("simpleKS");
        ks.setDefault(true);
        ks.setType(STATEFUL);
        ks.setClockType(ClockTypeOption.get("realtime"));
        Another issue with startup time is dynamic classpath scanning. Drools supports alternate ways to take decisions other than DRL-based rules, such as decision-tables, the Decision Model and Notation (DMN) or predictive models using the Predictive Model Markup Language (PMML). Such extensions are implemented as dynamically loadable modules, that are hooked into the core engine by scanning the classpath at boot-time. Although this is extremely flexible, it is not essential: even in this case, we can avoid runtime classpath scanning and provide static wiring of the required components either by generating code at build-time, or by providing an explicit API to end users to hook components manually. We resorted to provide a pre-built static module with a minimal core.
        private Map<Class<?>, Object> serviceMap = new HashMap<>();
        private void wireServices() {
          serviceMap.put(ServiceInterface.class,
                         Class.forName("org.drools.ServiceImpl").newInstance());
          // … more services here
        }
        Note that, although here we are using Class.forName(), the compiler is smart enough to recognize the constant and substitute it with an actual constructor. Of course, it is possible to simplify this further by generating a chain of if statements.
        Finally, we tied everything together by getting rid of the last few pre-executable model leftovers: the legacy Drools class-loader. This was the culprit behind the following apparently cryptic error message:
        Error: unsupported features in 2 methods
        Detailed message:
        Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException:
        Unsupported method java.lang.ClassLoader.defineClass(String, byte[], int, int, ProtectionDomain)
        is reachable: The declaring class of this element has been substituted, but this element is not
        present in the substitution class
        To diagnose the issue, you can add the option --report-unsupported-elements-at-runtime. The
        unsupported element is then reported at run time when it is accessed the first time.
        Trace:
               at parsing org.drools.dynamic.common.DynamicComponentsSupplier$DefaultByteArrayClassLoader.defineClass(DynamicComponentsSupplier.java:49)
        Call path from entry point to org.drools.dynamic.common.DynamicComponentsSupplier$DefaultByteArrayClassLoader.defineClass(String, byte[], ProtectionDomain):
        Really, however, the message is pretty clear: our custom class-loader is able to dynamically define a class, which is useful when you generate bytecode at run-time. But, if the codebase relies completely on the executable model, we can avoid this altogether, so we isolated the legacy class-loader into the dynamic module.
        This is the last step that was necessary to successfully generate a native image of our simple test project, and the results exceeded our expectations, thereby confirming that the time and efforts we spent in this experiment were well invested. Indeed, executing the main class of our test case with a normal JVM takes 43 milliseconds with a occupation of 73M of memory. The corresponding native image generated by Graal lasted is timed at less than 1 millisecond and uses only 21M of memory.

        Integrating with Quarkus

        Once we had a first version of Drools compatible with Graal native binary generation, the next natural step was to start leveraging the features provided by Quarkus and try to create a simple web service with it. We noticed that Quarkus offers a different and simpler mechanism to let the compiler know that we need reflection on a specific class. In fact, instead of having to declare this in a JSON file as before, you can annotate the class of your domain model as follows:
        @RegisterForReflection
        public class Person { … }
        
        
        We also decided to go one small step forward with our code generation machinery. In particular, we added one small interface to Drools code
        public interface KieRuntimeBuilder {
            KieSession newKieSession();
            KieSession newKieSession(String sessionName);
        }
        
        
        so that when the Drools compiler creates the executable model from the DRL files it also generates an implementation of this class. This implementation has the purpose of supplying a Drools session automatically configured with the rules and the parameters defined by the user.
        After that, we were ready to put both dependency injection and REST support provided by Quarkus to work, and we developed a simple web service exercising the Drools runtime.
        @Path("/candrink/{name}/{age}")
        public class CanDrinkResource {
        
            @Inject
            KieRuntimeBuilder runtimeBuilder;
        
            @GET
            @Produces(MediaType.TEXT_PLAIN)
            public String canDrink( @PathParam("name") String name,
                                    @PathParam("age") int age ) {
        
               KieSession ksession = runtimeBuilder.newKieSession();
        
               Result result = new Result();
               ksession.insert(result);
               ksession.insert(new Person( name, age ));
               ksession.fireAllRules();
        
               return result.toString();
            }
        }
        
        
        The example is straightforward enough to not require any further explanation and is fully deployable as a microservice in an OpenShift cluster. Thanks to the extremely low startup time—due to the work we did on Drools and the low overhead of Quarkus—this microservice is fast enough to be deployable in a KNative cloud. You can find the full source code on GitHub.

        Introducing Submarine

        These days, rule engines are seldom a matter of discussion. This is because they just work. A rule engine is not necessarily antithetical to a cloud environment, but work might be needed to fit the new paradigm. This was the story of our journey. We started with courage and curiosity. In the next few months, we will push this work forward to become more than a simple prototype, to realize a complete suite of business automation tools ready for the cloud. The name of the initiative is Submarine, from the famous Dijkstra quote. So, sit tight, and get ready to dive in.

        This article has been originally published on the Red Hat Developer blog here

        JHipster generator for jBPM Business Apps

        If you are a fan of JHipster you can now generate jBPM Business apps with it! We created a generator module for it which you can use as follows:

        With Yarn:

        yarn global add generator-jba

        Or with NPM:

        npm install -g generator-jba

        Once installed generate your app with:

        yo jba

        and follow the questions. If you want to generate the app with default settings, run:

        yo jba –quick=true