Rules Archives

DMN editor opens 1.1 and 1.3 assets now

by Guilherme Carreiro - November 17, 2020 Rules Tools News

The DMN editor continues evolving towards making users’ lives as simple as possible. On Kogito 0.8.1, we introduce a new mechanism to open DMN 1.1 and 1.3 assets. We’re still saving your model as a DMN 1.2 asset at conformance level 3. However, now any 1.1 or 1.3 model, non including DMN 1.3 features, isRead more →

BPMN and DMN Standalone Editors

by Paulo Martins - October 28, 2020 Process Rules Tools Article

In 0.7.2.alpha3 we started shipping a new component of the KIE tooling, what we’re calling Standalone Editors. These Standalone Editors provide a straightforward way to use our tried-and-true DMN and BPMN Editors embedded in your own web applications. The editors are now distributed in a self contained library that provides an all-in-one JavaScript file forRead more →

In 0.7.2.alpha3 we started shipping a new component of the KIE tooling, what we’re calling Standalone Editors.

These Standalone Editors provide a straightforward way to use our tried-and-true DMN and BPMN Editors embedded in your own web applications.

The editors are now distributed in a self contained library that provides an all-in-one JavaScript file for each of them, that can be interacted using a comprehensive API for setup and control of them.

Installation

In this release, you can choose from three ways to install the Standalone Editors:

Use our hosted JS files directly

Add a <script> tag to you HTML page:
- <script src="https://kiegroup.github.io/kogito-online/standalone/dmn/index.js"></script>
- <script src="https://kiegroup.github.io/kogito-online/standalone/bpmn/index.js"></script>

Manual download of each JS file

Download the files:
- DMN Editor: https://kiegroup.github.io/kogito-online/standalone/dmn/index.js
- BPMN Editor: https://kiegroup.github.io/kogito-online/standalone/bpmn/index.js
Add them in your own hosted application
Add a <script> tag to you HTML page:
- <script src="https://<YOUR_PAGE>/dmn/index.js"></script>

NPM package

Available at https://www.npmjs.com/package/@kogito-tooling/kie-editors-standalone
To add it to your package.json file:
- npm install @kogito-tooling/kie-editors-standalone
To import each Editor library in your TypeScript file:
- import * as DmnEditor from "@kogito-tooling/kie-editors-standalone/dist/dmn"
- import * as BpmnEditor from "@kogito-tooling/kie-editors-standalone/dist/bpmn"

Usage

The API is the same for both editors. Here is an example on how to open the DMN Editor:

Parameters description:

container: HTML element in which the Editor will be appended to.
initialContent: Promise to a DMN model content. Can be empty. Examples:
- Promise.resolve("")
- Promise.resolve("<DIAGRAM_CONTENT_DIRECTLY_HERE>")
- fetch("MyDmnModel.dmn").then(content => content.text())
readOnly (optional, defaults to false): Use false to allow content edition, and true for read-only mode, in which the Editor will not allow changes. WARNING: Currently only the DMN Editor supports read-only mode.
origin (optional, defaults to window.location.origin): If for some reason your application needs to change this parameter, you can use it.
resources (optional, defaults to []): Map of resources that will be provided for the Editor. This can be used, for instance, to provide included models for the DMN Editor or Work Item Definitions for the BPMN Editor. Each entry in the map has the resource name as its key and an object containing the content-type (text or binary) and the resource content (Promise similar to the initialContent parameter) as its value.

The returned object will contain the methods needed to manipulate the Editor:

getContent(): Promise<string>: Returns a Promise containing the Editor content.
setContent(content: string): void: Sets the content of the Editor.
getPreview(): Promise<string>: Returns a Promise containing the SVG string of the current diagram.
subscribeToContentChanges(callback: (isDirty: boolean) => void): (isDirty: boolean) => void: Setup a callback to be called on every content change in the Editor. Returns the same callback to be used for unsubscription.
unsubscribeToContentChanges(callback: (isDirty: boolean) => void): void: Unsubscribes the passed callback from content changes.
markAsSaved(): void: Resets the Editor state, signalizing that its content is saved. This will also fire the subscribed callbacks of content changes.
undo(): void: Undo the last change in the Editor. This will also fire the callbacks subscribed for content changes.
redo(): void: Redo the last undone change in the Editor. This will also fire the callbacks subscribed for content changes.
close(): void: Closes the Editor.
getElementPosition(selector: string): Promise<Rect>: Provides an alternative for extending the standard query selector when the element lives inside a canvas or even a video component. The selector parameter must follow the format of “:::”, e.g. Canvas:::MySquare or Video:::PresenterHand. Returns a Rect representing the element position.
envelopeApi: MessageBusClientApi<KogitoEditorEnvelopeApi>: Advanced Editor API. See more details in MessageBusClientApi and KogitoEditorEnvelopeApi.

Walk-through

Now let’s implement an application that provides the DMN Editor and adds a simple toolbar to the top that explores the main features of the API.

First, we start with a simple HTML page, and add a script tag with the DMN Standalone Editor JS library. We also add a <div> for the toolbar and a <div> for the Editor.

For the toolbar, we will add a few buttons, that will take advantage of the Editor’s API:

<div class="toolbar">
 <span id="unsavedChanges" class="hidden">File contains unsaved changes.</span>
 <button id="undo">Undo</button>
 <button id="redo">Redo</button>
 <button id="download">Download</button>
 <button id="downloadSvg">Download SVG</button>
</div>

view raw file3.html hosted with ❤ by GitHub

With the HTML ready, we can add a script to open the editor:

const editor = DmnEditor.open({
 container: document.getElementById("dmn-editor-container"),
 initialContent: Promise.resolve(""),
 readOnly: false
});

view raw file4.js hosted with ❤ by GitHub

This script will open an empty and modifiable DMN Editor inside the div#dmn-editor-container. But we still have to implement the toolbar actions. To be able to undo and redo changes, we can add the following script:

document.getElementById("undo").addEventListener("click", () => {
 editor.undo();
});
document.getElementById("redo").addEventListener("click", () => {
 editor.redo();
});

view raw file5.js hosted with ❤ by GitHub

To be able to retrieve the content from the Editor and, for example, download it, we can add this:

document.getElementById("download").addEventListener("click", () => {
 editor.getContent().then(content => {
 const elem = window.document.createElement("a");
 elem.href = "data:text/plain;charset=utf-8," + encodeURIComponent(content);
 elem.download = "model.dmn";
 document.body.appendChild(elem);
 elem.click();
 document.body.removeChild(elem);
 editor.markAsSaved();
 });
});

view raw file6.js hosted with ❤ by GitHub

A similar approach is used to make the diagram SVG available for download:

document.getElementById("downloadSvg").addEventListener("click", () => {
 editor.getPreview().then(svgContent => {
 const elem = window.document.createElement("a");
 elem.href = "data:image/svg+xml;charset=utf-8," + encodeURIComponent(svgContent);
 elem.download = "model.svg";
 document.body.appendChild(elem);
 elem.click();
 document.body.removeChild(elem);
 });
});

view raw file7.js hosted with ❤ by GitHub

Finally, we can also subscribe for changes in the Editor, and be notified when its content changes:

editor.subscribeToContentChanges(isDirty => {
 if (isDirty) {
 document.getElementById("unsavedChanges").classList.remove("hidden");
 } else {
 document.getElementById("unsavedChanges").classList.add("hidden");
 }
});

view raw file8.js hosted with ❤ by GitHub

We can also add some style to the <head> to make the Editor use the full page:

<style>
 #dmn-editor-container {
 height: calc(100vh – 50px);
 }
 .toolbar {
 height: 30px;
 }
 .hidden {
 display: none;
 }
</style>

view raw file9.html hosted with ❤ by GitHub

Then it looks like this:

And here is the full code:

<!DOCTYPE html>
<html lang="en">
 <head>
 <style>
 #dmn-editor-container {
 height: calc(100vh – 50px);
 }
 .toolbar {
 height: 30px;
 }
 .hidden {
 display: none;
 }
 </style>
 <title></title>
 <meta charset="UTF-8" />
 <meta name="viewport" content="width=device-width, initial-scale=1.0" />
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
 <script src="https://kiegroup.github.io/kogito-online/standalone/dmn/index.js"></script>
 </head>
 <body>
 <div class="toolbar">
 <span id="unsavedChanges" class="hidden">File contains unsaved changes.</span>
 <button id="undo">Undo</button>
 <button id="redo">Redo</button>
 <button id="download">Download</button>
 <button id="downloadSvg">Download SVG</button>
 </div>
 <div id="dmn-editor-container" />
 <script>
 const editor = DmnEditor.open({
 container: document.getElementById("dmn-editor-container"),
 initialContent: Promise.resolve(""),
 readOnly: false
 });
 document.getElementById("undo").addEventListener("click", () => {
 editor.undo();
 });
 document.getElementById("redo").addEventListener("click", () => {
 editor.redo();
 });
 document.getElementById("download").addEventListener("click", () => {
 editor.getContent().then(content => {
 const elem = window.document.createElement("a");
 elem.href = "data:text/plain;charset=utf-8," + encodeURIComponent(content);
 elem.download = "model.dmn";
 document.body.appendChild(elem);
 elem.click();
 document.body.removeChild(elem);
 editor.markAsSaved();
 });
 });
 document.getElementById("downloadSvg").addEventListener("click", () => {
 editor.getPreview().then(svgContent => {
 const elem = window.document.createElement("a");
 elem.href = "data:image/svg+xml;charset=utf-8," + encodeURIComponent(svgContent);
 elem.download = "model.svg";
 document.body.appendChild(elem);
 elem.click();
 document.body.removeChild(elem);
 });
 });
 editor.subscribeToContentChanges(isDirty => {
 if (isDirty) {
 document.getElementById("unsavedChanges").classList.remove("hidden");
 } else {
 document.getElementById("unsavedChanges").classList.add("hidden");
 }
 });
 </script>
 </body>
</html>

view raw file10.html hosted with ❤ by GitHub

We hope this new distribution is useful to you, and stay tuned for new updates!

DMN lives in the KIE Group YouTube channel

by Guilherme Carreiro - October 26, 2020 Rules Tools Event

The KIE YouTube channel is regularly posting quite interesting content! Last week I had the pleasure of presenting a talk about DMN at the KieLive#11 session: Tomorrow (October 27th), Edson Tirelli will also talk about DMN, but from a different and more advanced perspective at the KieLive#12: I’ve just activated the YouTube reminder because IRead more →

How to maintain DMN models on Business Central and VSCode

by Guilherme Carreiro - October 15, 2020 Rules Tools Article

Currently, the DMN editor is supported in a variety of environments. You can create a DMN model in an online editor, in a chrome extension, in a desktop app, in a VSCode extension, and even on Business Central. Until the latest release, you could face some differences between a model created by VSCode and aRead more →

Currently, the DMN editor is supported in a variety of environments. You can create a DMN model in an online editor, in a chrome extension, in a desktop app, in a VSCode extension, and even on Business Central.

Until the latest release, you could face some differences between a model created by VSCode and a one created by Business Central. Now, this post aims to demonstrate that both environments are fully compatible by showing the same project from two perspectives: I) how to create a project on VSCode and import it on Business Central, and II) how to create a project on Business Central and import it on VSCode.

Let’s check both environments.

–

The VSCode perspective

Let’s get started to understand how to use VSCode to handle a DMN file in a context of a Business Central project by relying only on VSCode.

In a shell prompt, enter the following mvn command to create a project:

mvn archetype:generate \
  -DarchetypeGroupId=org.kie \
  -DarchetypeArtifactId=kie-kjar-archetype \
  -DarchetypeVersion=7.44.0.Final \
  -DartifactId="Some Application" \
  -DgroupId="org.kie" \
  -DartifactId="vscode-2-bc"

When the archetype plug-in switches to interactive mode, accept the default values for the remaining fields
After generating your project, create a DMN asset at the src/main/resources/<your package> directory and populate it with some interesting decision, like the one in the video:

Now, initialize the git repository for your project, add all files, and commit them:

git init && git add . && git commit -m "Init"

Use pwd to get the local path of your project
Open the Business Central spaces screen, click on Import Project, and set file://<the local path of your project> as the Repository URL

Done! You’ve successfully created a Business Central project relying only on your terminal and on your VSCode DMN editor! 🎉

–

The Business Central perspective

Alright, now let’s do the opposite. Let’s create a project on Business Central and import it to VSCode.

Create a project on Business Central in the spaces screen
Create a DMN asset and populate it with some interesting decision, like the one in the video above
Now, click on “Settings” to open the project settings screen

Copy the HTTP URL of your project

Clone the URL of your project

git clone http://localhost:8080/business-central/git/MySpace/bc-2-vscode

Open the project directory with VSCode
Done! You’ve successfully opened your Business Central project with VSCode. You can now perform changes into your DMN mode, commit them with git, and the Business Central will automatically detect them

–

I hope you’ve enjoyed this quick tutorial! Stay tuned for new DMN features! 🙂

DMN editor supports multiple diagrams now

by Guilherme Carreiro - October 13, 2020 Rules Tools Release

The DMN editor was already great for expressing business logic and decomposing complex decisions into multiple nodes. However, in some advanced use cases, your graph may get complicated, and your model might look like this: I’ve removed all labels from this example to focus on the number of nodes and their relationship. Even without acknowledgingRead more →

DMN Validation updates: Kogito and migration to Executable Model

by Matteo Mortari - September 22, 2020 General Rules Article

In this article, we will describe some of the recent updates to the DMN Validation module (kie-dmn-validation) and how the migration to make use of the Executable Model enabled a number of use-cases, such as porting the functionality on the Kogito platform. Introduction The Drools DMN Engine provides static and semantic validation of DMN models:Read more →

In this article, we will describe some of the recent updates to the DMN Validation module (kie-dmn-validation) and how the migration to make use of the Executable Model enabled a number of use-cases, such as porting the functionality on the Kogito platform.

Introduction

The Drools DMN Engine provides static and semantic validation of DMN models:

validation of DMN against specification XSDs
static validation of DMN file
- e.g.: pre-compilation phase semantic validations (duplicate names, missing decision logic, etc.)
- fun-fact: static validation is performed with… Drools rules!
compilation phase checks
decision tables static analysis
- implements Method & Style checks
- semantic checks
- Hit Policy recommender
- Experimental features such as the MC/DC test case generator

The pre-compilation phase, where semantic validations are performed statically by introspecting deserialised DMN models, make use of Drools rules to ensure the conformance requirements from the DMN specification itself are respected in the DMN model provided by the user.

Migrating the DMN Validation to make use of the Executable Model

The migration required to fix some small corner cases in the executable model itself: I am extremely thankful to my colleagues Mario and especially Luca who supported me extensively in this migration, making it possible!
As any dogfooding program (the DMN validation module makes use of DRL rules to describe DMN specification semantics), this has been helpful also to highlight and overcome limitations early-on in the executable model itself when compared to the classic DRL mode of evaluation, to everyone’s benefit! 🙂

This migration also offers right off the bat several additional advantages:

now kie-dmn-validation uses the same default as per any kjar project Maven-built for Drools rules
several performance improvements;
for a basic example, executing the full kie-dmn-validation module tests now is cut in half (was 40s, now ~18s)
it is an enabler: the kie-dmn-validation has been enabled also on Kogito, during code generation phase

DMN Validation on Kogito

By default now Kogito performs validation of DMN against specification XSDs and static validation of DMN file (pre-compilation phase semantic validations). Decision Table analysis on Kogito platform will be enabled in a future iteration.

As a basic example: if you inadvertently violated the DMN specification by authoring a DMN model with two identical names in the nodes, you will be presented with a relevant DMN Validation message:

You can always opt-out of DMN Validation by disabling it entirely by configuring with application.properties:

kogito.decisions.validation=DISABLED

or ignoring any error during the build by configuring instead:

kogito.decisions.validation=IGNORE

Next Steps

As we expand the DMN Validation features (and the Kogito platform itself) please try it out and let us know your feedback!

We believe the DMN Validation can better support you authoring DMN models more effectively.

About DMN endpoints on Kogito

by Matteo Mortari - August 4, 2020 Rules Article

This post summarises the current design of REST endpoints which are automatically generated and made available, when using DMN model assets in a Kogito application. This work was finalised as part of KOGITO-2840. Introduction For each DMN model in a Kogito application, a collection of REST endpoints is automatically code generated based on the contentRead more →

This post summarises the current design of REST endpoints which are automatically generated and made available, when using DMN model assets in a Kogito application. This work was finalised as part of KOGITO-2840.

Introduction

For each DMN model in a Kogito application, a collection of REST endpoints is automatically code generated based on the content of the model.

For each DMN model there will be:

one REST “business-domain” endpoint to support the evaluation of the whole model
one REST “business-domain” endpoint to support the evaluation for each Decision Service(s) in the model

and also analogous endpoints returning classic DMNResult comprising business domain context and helper messages and helper decision “pointers”:

one REST “dmnresult” endpoint to support the evaluation of the whole model
one REST “dmnresult” endpoint to support the evaluation for each Decision Service(s) in the model

and finally:

one REST GET to return the DMN xml without decision-logic
This can be helpful for model introspection.
We are planning to eventually parametrise this endpoint with additional options for TrustyAI.

URL naming

The naming of the endpoints is currently structured with the following convention:

POST

{modelname}
{modelname}/{decisionServiceName}
{modelname}/dmnresult
{modelname}/{decisionServiceName}/dmnresult

GET

{modelname}

Choosing between “business-domain” and dmnresult variant of the REST endpoints

If a client application is only concerned with a positive evaluation outcome, is not interested in parsing Info/Warn message(s) and only needs to get an http 5xx in case of Errors, might prefer to opt for using the “business-domain” variant. Especially the feature of singleton coercion of Decision Service result, mimicking the DMN modeling behaviour, might be helpful for single page application-like clients.

If a client needs to parse also Info/Warn/Error messages in all the cases, it is best to prefer the dmnresult variant.

API details of the “business-domain” endpoints

The whole model endpoint needs as the input payload, all the Input Data of the model.

Once invoked, the output payload will be the resulting DMN context of the whole model evaluation, that is the one composed of the actual resulting Decision values, the original input values, and all other parametric DRG requirements in serialized form (e.g.: a BKM will be available in string serialized form in its signature).

The decision service endpoint needs as the input payload, all the requirements of the Decision Service.

Once invoked, the output payload will be the resulting DMN context of the Decision Service evaluation, that is the one composed of the actual resulting Decision values, the original input requirements, and all other parametric DRG requirements in serialized form (e.g.: a BKM will be available in string serialized form in its signature).

In the case the Decision Service is composed of a single output decision, the output payload will be the resulting value of that specific Decision; this is to provide an equivalent at API level of a specification feature, when invoking the Decision Service in the model itself. This feature can be used for example to interact very easily from single page web applications, with a DMN Decision Service.

For all these endpoints, in case of a DMN evaluation Error, a full DMNResult payload is returned along with a http 5xx error. In case of a DMN Info/Warn message, these will be returned along with the “business-domain” return rest payload, in the X-Kogito-decision-messages extended http header, more as an helper than to be used for client-side business logic; this is based on the assumption that, in case when more refined client-side business logic is required, the client can actually use the “dmnresult” variant of the endpoints.

Examples

In the following sections, some basic examples will be presented.

Endpoint: whole model

Given:

We notice the name of the DMN model is Traffic Violation:

endpoint: localhost:8080/Traffic Violation

input payload:

{
    "Driver": {
        "Points": 2
    },
    "Violation": {
        "Type": "speed",
        "Actual Speed": 120,
        "Speed Limit": 100
    }
}

output:

{
  "Violation": {
    "Type": "speed",
    "Speed Limit": 100,
    "Actual Speed": 120
  },
  "Driver": {
    "Points": 2
  },
  "Fine": {
    "Points": 3,
    "Amount": 500
  },
  "Should the driver be suspended?": "No"
}

Endpoint: decision service with singleton output decision

Given:

we notice the name of the decision service is TrafficViolationDecisionService:

endpoint: localhost:8080/Traffic Violation/TrafficViolationDecisionService

input payload:

{
    "Driver": {
        "Points": 2
    },
    "Violation": {
        "Type": "speed",
        "Actual Speed": 120,
        "Speed Limit": 100
    }
}

output:

"No"

Endpoint: decision service with multiple output decision

Now given instead:

endpoint: localhost:8080/Traffic Violation/TrafficViolationDecisionService

input payload:

{
    "Driver": {
        "Points": 2
    },
    "Violation": {
        "Type": "speed",
        "Actual Speed": 120,
        "Speed Limit": 100
    }
}

output:

{
    "Violation": {
        "Type": "speed",
        "Speed Limit": 100,
        "Actual Speed": 120
    },
    "Driver": {
        "Points": 2
    },
    "Fine": {
        "Points": 3,
        "Amount": 500
    },
    "Should the driver be suspended?": "No"
}

Conclusions

We have seen the current design of DMN REST endpoints automatically generated in a Kogito application and how can be used to support several use-cases.

We like to hear your feedback! Do you have some thoughts or question about this topic? Please make sure to let us know!

Making Executable DMN Modeling More Business-Friendly

by Matteo Mortari - July 9, 2020 Rules Article Presentation Video

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 →

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

Lists as DMN boxed expressions

by Guilherme Carreiro - May 4, 2020 Rules Tools Article

Literal expressions, Decision Tables, Contexts, Relations, Functions, and Invocations are quite powerful boxed expressions already. However, now our editor supports Lists as a new boxed expression type. Lists represent a group of FEEL expressions. You may use it to define complex items for a particular decision, check this example: Notice that each cell of this listRead more →

Getting Started with jBPM

by Karina Varela - May 4, 2020 Process Rules Article

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

This image has an empty alt attribute; its file name is screen-shot-2020-04-25-at-02.06.14.png

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

	{
	"full service name": "function full service name( service name )",
	"services": [
	"Acme Agency (status: running)",
	"Global Scoring (status: stopped)",
	"Nook Inc. (status: running)"
	]
	}

KIE

KIE

Type

Authors

Featured Posts: Rules

About DMN endpoints on Kogitoby Matteo Mortari

Making Executable DMN Modeling More Business-Friendlyby Matteo Mortari

Lists as DMN boxed expressionsby Guilherme Carreiro

Getting Started with jBPMby Karina Varela

Kogito 0.9.1 releasedby Kris Verlaenen

Learn DMN in 15 minutesby Guilherme Carreiro

Kogito, ergo Rules: From Knowledge To Service, Eff...by Edoardo Vacchi

Etymology of Kogitoby Kris Verlaenen

Recent Drools DMN open source engine performance i...by Matteo Mortari

Kogito, ergo Rules — Part 1: Bringing Drools Fur...by Edoardo Vacchi

drools.js: Towards a Polyglot Drools on GraalVM (w...by Edoardo Vacchi

Quarking Drools: How we turned a 13-year-old Java ...by Mario Fusco

Installation

Usage

Walk-through

The VSCode perspective

The Business Central perspective

Introduction

Migrating the DMN Validation to make use of the Executable Model

DMN Validation on Kogito

Next Steps

Introduction

URL naming

Choosing between “business-domain” and dmnresult variant of the REST endpoints

API details of the “business-domain” endpoints

Examples

Endpoint: whole model

Endpoint: decision service with singleton output decision

Endpoint: decision service with multiple output decision

Conclusions

jBPM main components

Getting familiar with jBPM

Hands On – Running on WildFly

jBPM on WildFly: Authentication and Authorization

Hands On – Running on Spring Boot

Hands On – jBPM Docker Image

About DMN endpoints on Kogito
by Matteo Mortari

Making Executable DMN Modeling More Business-Friendly
by Matteo Mortari

Lists as DMN boxed expressions
by Guilherme Carreiro

Getting Started with jBPM
by Karina Varela

Kogito 0.9.1 released
by Kris Verlaenen

Learn DMN in 15 minutes
by Guilherme Carreiro

Kogito, ergo Rules: From Knowledge To Service, Eff...
by Edoardo Vacchi

Etymology of Kogito
by Kris Verlaenen

Recent Drools DMN open source engine performance i...
by Matteo Mortari

Kogito, ergo Rules — Part 1: Bringing Drools Fur...
by Edoardo Vacchi

drools.js: Towards a Polyglot Drools on GraalVM (w...
by Edoardo Vacchi

Quarking Drools: How we turned a 13-year-old Java ...
by Mario Fusco