presentation byBruce Silver, MethodAndStyle.comand Matteo Mortari, Red Hat At this year’s Decision Camp 2020, I had the opportunity to present with Bruce Silver a complete overview of the DMN Validation features, and some of the research areas we are working together on: I hope this can be an helpful summary of what you should look at whenRead more →
KIE
Featured Posts: Rules
Making Executable DMN Modeling More Business-Friendly
presentation by
Bruce Silver, MethodAndStyle.com
and Matteo Mortari, Red Hat
At this year’s Decision Camp 2020, I had the opportunity to present with Bruce Silver a complete overview of the DMN Validation features, and some of the research areas we are working together on:
I hope this can be an helpful summary of what you should look at when considering Validation of a DMN model and decision tables, including some of the unique features that we offer there, together with all our partners like Trisotech too, and some of the experimental features we are researching to ease the work of the Business Analyst and decision modelers.
While DMN is sometimes used simply to create “decision requirements” handed off to developers, the standard was designed for non-programmers to create executable decision models themselves. Although decision model design is nominally business-friendly, business users still struggle to create DMN models that are correct and complete. This can be partially explained by the lack of disciplined approach and application of engineering principles that come naturally to technical users, presenting an opportunity for vendors’ tools to assist them.
Decision tables are DMN’s most business-friendly feature, but business users have problems ensuring they are complete and consistent and difficulty applying the correct hit policy. Decision Table Analysis built into the DMN tool should be able to detect flaws like gaps in the rules, unintended overlaps, subsumption, and incorrect hit policy. We have developed such an algorithm and are incorporating it into multiple DMN tools.
Beyond completeness and consistency, the decision table logic must be correct, the output always matching the expected value. That is what test cases are for, but business users do not know how to use them or create test cases that fully test the logic. This again presents an opportunity for tool-based assistance.
Automated test case generation is not an easy problem. A decision table with N inputs, each of which has m possible values, requires m**N test cases for complete coverage. From the world of automated software testing, a method called Modified Condition/Decision Coverage (MC/DC) has been shown to provide excellent coverage with far fewer test cases. We have developed an algorithm for applying MC/DC to test case generation for DMN decision tables.
Keywords: DMN, Decision Tables, Hit Policy, Test Cases
Getting Started with jBPM
Being familiar your BA tool guides to better decision taking on development and architecture decisions. Let’s start by learning a little bit more about the core components and about jBPM installation. jBPM main components jBPM is mainly based on two components: Business Central and Kie Server. Reinforcing the concepts: business central is the authoring andRead more →
Being familiar your BA tool guides to better decision taking on development and architecture decisions. Let’s start by learning a little bit more about the core components and about jBPM installation.
jBPM main components
jBPM is mainly based on two components: Business Central and Kie Server. Reinforcing the concepts: business central is the authoring and monitoring environment. Kie Server is the engine, where the execution of business assets happens.
In a business automation project with jBPM, during the application design phase the architect must take into consideration the determination of the architecture regarding the business automation services:
- Will this project require the usage of Business Central to manage the engines?
- Or will we scale the engine using docker containers managed by Kubernetes in a CI/CD fashion?
- Will we deploy projects via business central, or just promote projects using an automation and integration tool?
- How should the development environment for business assets be like?
- Can we decouple business rules from the rest of the projects?
- Should we embed the engine or deploy it remotely?
There are many ways to architect business applications and address the specific needs of development, operations, and business teams. The jBPM Getting Started series will bring possible architectures in later on in a post about Advanced Architecting , including information about enterprise cloud architectures for business automation projects.
Getting familiar with jBPM
Business automation involves managing projects and business assets in a friendly way, for all the personas involved in the project. Let’s get started by performing some basic tasks using jBPM. The tool is available for download in the official site http://jbpm.org.
Cloud-ready kjars can run on Java Application Servers, Spring Boot, Thorntail, or Web Server Container (tomcat). For our first try, we will work with WildFly, an open-source Application Server (also known as JBoss in earlier versions).
The first hands-on guides you through a setup of jBPM in a local environment.
Hands On – Running on WildFly
Wildfly, also known as JBoss Enterprise Application Platform (JBoss EAP), is an open-source option of a Java EE Application Server. It is widely used in critical environments and it has been proven stable over the years. jBPM website provides a ready-to-use jBPM installed on top of WildFly.
To download and install jBPM follow these steps:
- Access the website http://jbpm.org and click on the download button to get the latest version. A download will start, and you will have a zip file with a name similar to jbpm-server-7.x.x.Final-dist.zip.
2. Extract the files from the downloaded package into a folder of your preference. WildFly is extracted and jBPM is available and configured.
- The three steps below can be executed on Linux and Unix machines to install and start jBPM.
# Create a folder dir for your instalation $ mkdir ~/learn-jbpm # Unzip the downloaded file into opt folder $ unzip jbpm-server-7.36.0.Final-dist.zip -d ~/learn-jbpm/opt/jbpm # Enter jBPM folder $ cd ~/learn-jbpm/jbpm # Start jBPM $ ./bin/standalone.sh
- The server will bootstrap and start both jBPM applications deployed within it: Business Central ( http://localhost:8080/business-central ) and Kie Server ( http://localhost:8080/kie-server/ ). The default environment makes usage of a volatile database, H2.
jBPM on WildFly: Authentication and Authorization
The default installation comes with predefined users and their respective roles. Here are some of the users which you can use in this lab. The password is equal to the username.
| Username | Roles |
| wbadmin | admin,analyst,user,process-admin,kie-server |
| krisv | admin,analyst,user,process-admin,kie-server |
| maciek | admin,analyst,user,PM,HR,kie-server |
 |
jBPM uses the Java Authentication and Authorization Service (JAAS) provided by WildFly login module. Later on upcoming blog posts we’ll understand how to integrate with authentication and authorization using Keycloak. |
WildFly users and groups are defined within application-users.properties and application-roles.properties files. Both files are located under $WILDFLY_HOME/standalone/configuration directory. In our jBPM installation, the standalone.xml file has customization that changes the used files to configure users and roles. The new files used are users.properties and roles.properties respectively. The following code sets this customization within the standalone.xml file:
<security-realm name="ApplicationRealm">
...
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="users.properties" relative-to=“jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
In this post, we will use the users.properties and roles.properties provided by the out-of-the-box authentication and authorization configuration.
In higher environments (like UAT or production), this auth strategy is not recommended. jBPM should connect to external authorization and authentication providers like LDAP or Keycloak.
The next topics provides an introduction on how to run jBPM on Spring-boot and Docker.
Hands On – Running on Spring Boot
jBPM community also provides a website that allows you to easily create business applications using Spring Boot. To try this approach, download a business application with all the required structure to be executed on-premise or in the cloud.
- Access http://start.jbpm.org and click on Generate default business application.A zip file will be downloaded with the name business-application.zip. It contains a business application configured to run on Spring Boot and using the latest release of jBPM.
- In order to view and start this application, unzip the “business-application.zip” file. Using terminal, you can do unzip it, and check the structure with the following commands:
→ unzip business-application.zip -d ~/learn-jbpm/labs/hello-sb-jbpm → tree -L 2 hello-sb-jbpm
This design of business application consists of three (or more) projects: a module for the business assets, a module for the application models, and another one for the services. It is possible to have multiple modules of each type, this decision should match the environment and application requirements.
- You may notice that only Kie Server will be available after start-up. This is because the business application does not embed Business Central into Spring Boot, but its engine can be connected to a remote Business Central for deployment and monitoring capabilities.
- In the service application, launch scripts are available to start the environment locally or in a cloud platform like OpenShift. Enter into the “business-application-service” folder, and execute the launch.sh command:
cd ~/learn-jbpm/labs/hello-sb-jbpm/business-application-service/ sh launch.sh clean install
You will notice that Maven starts downloading the project dependencies in order to build and compile the whole project. Once services are up and running you should be able to access them in: http://localhost:8090/rest/server . You can test it with the default user wbadmin and password wbadmin.
The code example below shows how the users and roles are defined within com.company.service.DefaultWebSecurityConfig class in the service project:
@Autowired
public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
auth.inMemoryAuthentication().withUser("user").password("user").roles("kie-server");
auth.inMemoryAuthentication().withUser("wbadmin").password("wbadmin").roles("admin");
auth.inMemoryAuthentication().withUser("kieserver").password("kieserver1!").roles("kie-server");
}
In a development environment when the user is not connecting to external authorization tools like Keycloak, this is where users can alter roles and groups.
Hands On – jBPM Docker Image
jBPM community also works to provide docker images into Docker Hub repository. There are currently three images:
Let’s try the jbpm-server-full image. This image provides a full authoring and execution environment running on top of WildFly. It is really simple to run a container with the latest project version:
$ docker run -p 8080:8080 -p 8001:8001 -d --name jbpm-server-full jboss/jbpm-server-full:latest
This should start a container, exposing the port 8080 to enables access to Business Central and Kie Server, and port 8001 to enable importing and exporting projects using git:
$ docker ps
This startup command does not map any volume, so be aware that work executed inside this Docker container is not persisted. It is possible to follow the server logs if necessary (change 06 with your docker container id):
$ docker logs -f jbpm-server-full
jBPM is started, and both services are running:
- Business Central: http://localhost:8080/business-central or http://localhost:8080/jbpm-console
- Kie Server: http://localhost:8080/kie-server/
To stop the docker container, use the following command. This command should stop the instance which is running jBPM server.
$ docker stop jbpm-server-full
Three possible ways to work with jBPM were presented: jBPM deployed in WildFly application server; business applications deployed within spring-boot; docker image with a ready to use jBPM deployed in a WildFly Application Server.
On the next blog post, we’ll check the main components of jBPM and how we can start using them towards a business automation project delivery.
<
p class=”has-text-align-center”>This blog post is part of the third section of the jBPM Getting started series: Automate your business with jBPM
Kogito 0.9.1 released
We are glad to announce the Kogito 0.9.1 release is now available! This goes hand in hand with the Kogito Tooling 0.3.1 release. From a feature point of view there are only minor changes compared to 0.9.0, but on top of bug fixing we have also spent quite some time on following areas: Kogito documentationRead more →
We are glad to announce the Kogito 0.9.1 release is now available! This goes hand in hand with the Kogito Tooling 0.3.1 release.
From a feature point of view there are only minor changes compared to 0.9.0, but on top of bug fixing we have also spent quite some time on following areas:
- Kogito documentation is now available
- Kogito website was updated with updated getting started and community sections
- Kogito examples were updated and improved
This is a milestone for us as we wanted to bring an end-to-end story and focus on our documentation and getting started experience to help you with your first steps on Kogito. Take a look and let us know if you have further questions or recommendations!
New to Kogito?
Check out our website https://kogito.kie.org/
Click on the “Get Started” button.
All artefacts are available now:
- Kogito runtime artefacts are available on Maven Central
- Kogito examples can be found here
- Kogito images are available on quay
- Kogito operator is available in the OperatorHub in OpenShift
- Kogito tooling 0.3.1 artefacts are available here
As announced last week we’ve also introduced a chat channel where you can reach the core team or interface with the community, so hope to see you all there !
Detailed release notes for 0.9.1 in JIRA can be found here.
Kogito, ergo Rules: From Knowledge To Service, Effortless
Welcome to another episode of this blog series on the Kogito initiative and our efforts to bring Drools to the cloud. The goal of these posts is to gather early user feedback on the features we are delivering to Kogito. In this post we present two new ways to realize a complete intelligent service: self-containedRead more →
Welcome to another episode of this blog series on the Kogito initiative and our efforts to bring Drools to the cloud. The goal of these posts is to gather early user feedback on the features we are delivering to Kogito.
In this post we present two new ways to realize a complete intelligent service:
- self-contained rule services
- integrated intelligent workflows with rule tasks
Units of Execution in Kogito
As you may already know, in Kogito we are making front-and-center the new Unit concept.
“Unit of execution” is the term that we use to indicate an executable piece of knowledge. A unit may be a process, a set of rules, a decision, etc… In the case of a set of rules, we call it a rule unit. If you opt-in to use units, in Kogito we will take care of all the boilerplate that is required to generate a REST endpoint automatically.
A rule unit is constituted primarily by
1) a data definition;
2) the set of rules and queries that implement the behavior of the unit (the rules of the rule engine);
3) optionally, event listeners may be attached for a number of purposes.
2) the set of rules and queries that implement the behavior of the unit (the rules of the rule engine);
3) optionally, event listeners may be attached for a number of purposes.
In this post we’ll focus on data definitions, rules and queries.
Data definitions are given by declaring a Java class that may contain data sources. Each data source represents a partition of the working memory that your rules will pattern match against or insert to.
For instance, suppose you want to declare an alerting service that receives events and produces alerts depending on some conditions. We declare
Event and Alert objects as follows:package com.acme;
public class Event {
String type;
int value;
// getters and setters
}
public class Alert {
String severity;
String message;
// getters and setters
}
The
AlertingService unit type declaration is a class that implements the interface RuleUnitData.package com.acme;
public class AlertingService implements RuleUnitData {
private final DataStream<Event> eventData = DataSource.createStream();
private final DataStream<Alert> alertData = DataSource.createStream();
// getters and setters
}
Rules are defined in DRL files as usual, except that you have now to indicate their unit at the top of the file. For instance you may declare the data definition for
AlertingService as follows: package com.acme;
unit AlertingService;
rule IncomingEvent when
// matches when a temperature higher than 30 °C is registered (OOPath syntax)
$e : /eventData [ type == "temperature", value >= 30 ]
then
System.out.println("incoming event: "+ $e.getMessage());
alertData.append( new Alert( "warning", "Temperature is too high" ) );
end
As you can see, rules may match against or insert to the given data sources.
Queries are defined in DRL files like rules, and belong to a unit, too. If you declare at least one query, you will get a REST endpoint automatically generated for free. For instance:
query Warnings
alerts: /alertData [ severity == "warning" ]
end
will generate the REST endpoint
/warnings that you will be able to invoke by POST-ing to it as follows: $ curl -X POST
-H 'Accept: application/json'
-H 'Content-Type: application/json'
-d '{ "eventData": [ { "type": "temperature", "value" : 40 } ] }'
http://localhost:8080/warnings
This will generate the response:
[ { "severity": "warning", "message" : "Temperature is too high" } ]
The Java-based data definition is very familiar to programmers, but, from early user feedback, we decided to provide two alternative methods to declare a rule unit. We are publishing this blog post to gather more user feedback!
Type Declaration
The type declaration is the DRL feature to declare Java-compatible types, in a Java-agnostic way. In the 7 series, users may declare types with the syntax:
package com.acme;
declare Event
type: String
value: int
end
declare Alert
severity: String
message: String
end
This makes the DRL completely self-contained: entities and rules may be all defined using DRL. However, they have few limitations; for instance, they do not support implementing interfaces and they do not support generic type fields. In other words, the following declaration, in the 7 series, is syntactically invalid:
package com.acme;
declare AlertingService extends RuleUnitData
eventData: DataStream<Event>
alertData: DataStream<Alert>
end
In version 0.8.0, we are lifting these limitations: we allow limited inheritance for interfaces (only one is allowed for now) and generic type declaration for fields. With these new features, the following piece of code becomes valid DRL.
Long story short: you are now able to declare a full microservice
from a single DRL.
from a single DRL.
Bootstrap your Kogito service with the archetype:
mvn archetype:generate
-DarchetypeGroupId=org.kie.kogito
-DarchetypeArtifactId=kogito-quarkus-archetype
-DarchetypeVersion=0.8.0
-DgroupId=com.acme
-DartifactId=sample-kogito
At the moment, no Quarkus version bundles Kogito 0.8.0; otherwise, you would be able to use
mvn io.quarkus:quarkus-maven-plugin:create instead.Now, clear the contents of
src/main and then, drop this DRL to src/main/resources/com/acme folder instead:package com.acme;
unit AlertingService;
import org.kie.kogito.rules.DataStream;
import org.kie.kogito.rules.RuleUnitData;
declare Event
type: String
value: int
end
declare Alert
severity: String
message: String
end
declare AlertingService extends RuleUnitData
eventData: DataStream<Event>
alertData: DataStream<Alert>
end
rule IncomingEvent when
// matches when a temperature higher than 30 °C is registered (OOPath syntax)
$e : /eventData [ type == "temperature", value >= 30 ]
then
System.out.println("incoming event: "+ $e.getMessage());
alertData.append( new Alert( "warning", "Temperature is too high: " + $e ) );
end
query Warnings
alerts: /alertData [ severity == "warning" ]
end
Now fire up the Quarkus service in developer mode with:
$ mvn compile quarkus:dev
There you go, you are now ready to
curl your service: $ curl -X POST
-H 'Accept: application/json'
-H 'Content-Type: application/json'
-d '{ "eventData": [ { "type": "temperature", "value" : 40 } ] }'
http://localhost:8080/warnings
Workflow Integration
Another way to expose a rule-based service is through a workflow.
A workflow (sometimes called a “business process”) describes a sequence of steps in a diagram and it usually declares variables: data holders for values that are manipulated in the execution. The data type of one such variable may be anything: you may use Java classes, but, in this example, we will use again our declared data types.
package com.acme;
declare Event
type: String
value: int
end
declare Alert
severity: String
message: String
end
Let us call this workflow
com.acme.AlertingWorkflow, and declare the variables eventData and alertData:
A workflow that includes a rule task may skip the rule unit data declaration altogether: in this case the rule unit is inferred directly from the structure of the process: each variable will be inserted into data source of the same name.
The name of the unit is declared by the process, using the syntax
unit:com.acme.AlertingService. You are still free to explicitly declare the unit com.acme.AlertingService; in that case, the process will pick up the declaration that you have hand-coded.Note: You may have noticed that we are using the “Rule Flow Group” field. We will implement more explicit support in the UI in the future.
Bootstrap your Kogito service with the archetype:
mvn archetype:generate
-DarchetypeGroupId=org.kie.kogito
-DarchetypeArtifactId=kogito-quarkus-archetype
-DarchetypeVersion=0.8.0
-DgroupId=com.acme
-DartifactId=sample-kogito
Caveat. Support for this feature is experimental, so it may not work seamlessly with Quarkus hot code reload; we also need the following extra step to enable it, but this will change in the future.
Update your
pom.xml with the following plugin declaration: <build>
<plugins>
<plugin>
<groupId>org.kie.kogito</groupId>
<artifactId>kogito-maven-plugin</artifactId>
<version>0.8.0</version>
<executions>
<execution>
<goals>
<goal>generateDeclaredTypes</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
You can now clear the contents of
src/main, and then drop the process and the following DRL to src/main/resources/com/acme folder.package com.acme;
unit AlertingService;
import org.kie.kogito.rules.DataStream;
import org.kie.kogito.rules.RuleUnitData;
declare Event
type: String
value: int
end
declare Alert
severity: String
message: String
end
rule IncomingEvent when
// matches when a temperature higher than 30 °C is registered (OOPath syntax)
$e : /eventData [ type == "temperature", value >= 30 ]
then
System.out.println("incoming event: "+ $e.getMessage());
alertData.set( new Alert( "warning", "Temperature is too high: " + $e ) );
end
As you may have noticed, you are not required to declare a query explicitly: the process will display the contents of the variables as a response; it will generate the endpoint
/AlertingWorkflow, and it accept a POST request of the following form: $ curl -X POST
-H 'Accept: application/json'
-H 'Content-Type: application/json'
-d '{ "eventData": { "type": "temperature", "value" : 40 } }'
http://localhost:8080/AlertingWorkflow
The reply will be:
{
"id": ...,
"eventData": {
"type": "temperature",
"value": 100
},
"alertData": {
"severity": "warning",
"message": "Temperature is too high: Event( type=temperature, value=100 )"
}
}
However, if you do declare a query, a separate endpoint will be available as well. For instance if you declare the query
Warnings you will still be able to POST to http://localhost:8080/warnings and invoke the rule service separately as follows:$ curl -X POST
-H 'Accept: application/json'
-H 'Content-Type: application/json'
-d '{ "eventData": { "type": "temperature", "value" : 40 } }'
http://localhost:8080/warnings
Notice that the request no longer contains a list of Events. This is because process variables are mapped to single values instead of DataStreams.
Conclusion
We have given a sneak peek on the work that we are doing to improve the getting started experience with rules and processes in Kogito. With these changes, we hope to have provided a more streamlined way to define knowledge-based services. Developers will always able to be more explicit about the data they want to process, by opting-in to writing Java; but if they want, they can embrace a fully DSL-centric development workflow.
For the lazies, examples are available at https://github.com/evacchi/kogito-rules-example/tree/master/code Have fun!
Etymology of Kogito
After writing up an introduction to our Kogito effort, it seems people are interested in hearing a little but more about the name, where it comes from, what the logo means, and (what seems to be the most important question) how to pronounce Kogito? Yes, there even was a JIRA issue [KOGITO-284] opened to addressRead more →
After writing up an introduction to our Kogito effort, it seems people are interested in hearing a little but more about the name, where it comes from, what the logo means, and (what seems to be the most important question) how to pronounce Kogito? Yes, there even was a JIRA issue [KOGITO-284] opened to address this issue!
First, the name Kogito itself comes from:
“Cogito, ergo sum”
a Latin philosophical proposition by René Descartes usually translated into English as “I think, therefore I am” [Wikipedia]. So Kogito simply means “I think”, and refers to how users are encoding business knowledge using various formats (processes, rules, constraints, etc.). The ‘c’ was replaced with a ‘k’ as a reference to Kubernetes, our target cloud platform, and Kie where the k stands for knowledge.
“Kogito, ergo automate” therefore means, “I think, therefore I automate” and refers to the use of business automation to encode business knowledge.
Our logo is a reference to Odin, the Norse God that gave up an eye for wisdom [Wikipedia].
“According to mythology, Odin ventured to the mystical Well of Urd at the base of the world-tree that holds the cosmos together. The well was guarded by Mimir, a shadowy being who becomes all knowing by drinking the magical waters. Odin asked for a drink and Mimir replied that Odin must sacrifice an eye for a drink. Odin gouged out his own eye, dropped it into the well, and was allowed to drink from the waters of cosmic knowledge.”
Finally, how do I pronounce Kogito? Since it comes from the Latin phrase “Cogito, ergo sum”, the obvious first question could be, how do I pronounce that? As it turns out, not an easy question to answer, but in the end the Italians in our team proclaimed this to be the only correct pronunciation:
[ˈkoː.d͡ʒi.to]
so that’s with the emphasis on the first syllable, and the ‘g’ pronounced as ‘dji’, or (if you’re not skilled in phonetic language at all like me ;)) just listen to the video below:
Some good news though, because it seems no mortal person is able to consistently pronounce it this way, other pronunciations are completely fine too!
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, butRead more →
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.
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
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)
Workbench is now Business Central!
5 years ago, on November 2013 we released 6.0.0.Final, that included the first version of the Workbench. It has been a long journey so far, but today we’re announcing that we’re retiring the Workbench brand and officially adopting Business Central as the new brand! Historical Context The KIE group has been developing web tooling forRead more →
5 years ago, on November 2013 we released 6.0.0.Final, that included the first version of the Workbench. It has been a long journey so far, but today we’re announcing that we’re retiring the Workbench brand and officially adopting Business Central as the new brand!
Historical Context
The KIE group has been developing web tooling for more than a decade now. The first public release that shipped a browser based tool was 5.0.1 (May of 2009), but its R&D started way before that.
|
Tip
|
KIE stands for Knowledge Is Everything, and it is pronounced exactly the word key in English: /kē/ . |
The first experiments of a web-based tool to manage a central repository for business rules that provided an intuitive user interface to create and package rules started back in September 2006 as jbrms. After a couple of years, it was renamed to Guvnor, and this is the name that would become known as the official name of our first web tooling.
Figure 1. Guvnor Guided Rule Editor User Interface.
The next generation that became known as Workbench started its R&D in May of 2012 with multiple goals and challenges that could be summarized in the following major two key points:
- A modular, plug-in based, composable tooling, to avoid the single project/repo that Guvnor became over the years
- A Virtual File System based storage, to avoid getting stuck with a technology like JCR
Figure 2. Workbench Original NSEW Compass Drag-and-Drop
Evolution
The Workbench has been distributed in two flavors: KIE Drools Workbench and KIE Workbench. Initially, the KIE Workbench used to be shipped with an embedded jBPM engine, what made the distributions significantly different. However, with the KIE-Server release and the engine unification, the embedded jBPM engine was removed from Workbench, and the differences between the two distros became just a matter of show/hide some user interface items.
It’s also clear that the current Workbench has very little in common with its original format. Over the years it not only get more polished and stable, but the target audience has evolved from a developer focused to a collaborative platform between practitioners and developers.
Based on the above facts and also looking for a more concise branding strategy a decision was made: unify the distributions and re-brand it as Business Central!
Business Central
So what’s in the new name? The major positive impact is that we have now a single distribution and terminology to reference the KIE group web tooling, that also unifies the product and community terminology.
Here’s a quick walkthrough of the changes you’ll see in the new Business Central:
Profiles and Entitlements
By default Business Central bootstrap with all the features enabled, that includes Drools, OptaPlanner, and jBPM. However, for those that are not taking advantage of our jBPM engine, we provide in settings a Profiles option that allows admins to adjust Business Central to display only the relevant profile to your needs.
The default profile can be also be defined in the startup using the
org.kie.workbench.profile environment variable with the following possible values:
- FULL
- PLANNER_AND_RULES
- FORCE_FULL
- FORCE_PLANNER_AND_RULES
The main difference between the “FORCE_” values is that it will hide the settings configuration, forcing the chosen profile.
Conclusion
After five years, the KIE group has decided that was time to retire the Workbench brand. Our web tooling evolved quite a lot and the use of the word Workbench, a common term for developers, didn’t reflect the current state of it.
The consolidation and re-branding to Business Central aims to provide a clear message about its targeted audience with a concise communication strategy. If you’re interested in giving it a try, Business Central is available to download today!
Business Process Driven Web Terminal – jBPM Business Apps Demo
In this jBPM Business Application demo we show how you can dynamically present your business process data to your users. Demo sample The demo app is a Websocket terminal app where you can enter in different commands and results of those commands are displayed back. Each command entered triggers our demo business process which usesRead more →
In this jBPM Business Application demo we show how you can dynamically present your business process data to your users.
 |
| Demo sample |
The demo app is a Websocket terminal app where you can enter in different commands and results of those commands are displayed back. Each command entered triggers our demo business process which uses the jBPM Business Rules task to evaluate the command and then passes it on to
the jBPM Exec workitem (or the OpenWeatherMap workitem if weather info is requested).
 |
| Business process used in demo |
The demo shows off how results of business process execution can dynamically trigger updates of your app UI. It also shows the power of the jBPM Exec workitem which can come really handy in my business app situations.
For more details and a walkthrough of this demo app view the youtube video here:
New DMN Editor Preview
The Workbench 7.13.0.Final was released Tuesday, October 16, and this version brings a lot of interesting features and important fixes. One of the highlights is the new DMN Editor as a tech preview feature that is still under development but that you can begin using. In this article, you’ll learn how to enable the DMNRead more →
The Workbench 7.13.0.Final was released Tuesday, October 16, and this version brings a lot of interesting features and important fixes. One of the highlights is the new DMN Editor as a tech preview feature that is still under development but that you can begin using.
In this article, you’ll learn how to enable the DMN Editor Preview, create a simple DMN model, and execute it via a REST API.
Let’s get started 🙂
1) Enabling the Preview editor
Since the feature is available as a tech preview, it’s hidden by default. To enable it, go to Settings -> Roles, select the role you’re logged in (for example, “admin”) and remove the “DMN Designer” exception in the “Permissions” section. Take a look at the steps:
2) Creating a DMN model
Now that you have the DMN Editor enabled, let’s create a new project: Go to “Projects”, click on “Add asset” and then open the “DMN Preview”. Here you can explore the editor and create your DMN file with your own rules or you can follow the steps provided by this video:
Notice that two input nodes (“Number of branches” and “Branches dispersion”) and one decision node (“Branches distribution”) were inserted. Additionally, we created a Decision Table in the “Branches distribution” node to write some rules.
The DMN file created in the video can be downloaded here.
3) Executing the DMN model
With the DMN file created and saved, it’s time to deploy the DMN model. Go to Projects -> Your project and click on “Deploy” to deploy your project in a KIE Server. Now, access your instance with the “/dmn” suffix, in my case the URL is:
http://localhost:8080/kie-server/services/rest/server/containers/DMNSample_1.0.0/dmn.
If you follow the steps above correctly, you’ll see something like this:
Notice the model-namespace and the model-name values, they will be useful in the next step.
Now, we can make requests to execute rules in our KIE Server instance. See the example below:
Replace the URL, the model-namespace and the model-name with your own information, and try it locally. The rules will be executed by the KIE Server with the DMN model you’ve created, and the response will be something like this:
This article describes a small part of all the functionality of the DMN Editor. You can write even more complex rules by applying different structures. If you want to read more about the DMN specification, see the DMN Cookbook.
The DMN Editor is still under development. New features and enhancements are to come. Stay tuned 😉