Featured Posts: Process

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!

Case Management in Kogito

by Ruben Romero Montes - October 13, 2020 Process Article

I want to explain how to bring Case Management to Kogito using the tools that flexible processes provide. Previously I introduced flexible processes in Kogito. See part 1 for a generic introduction and part 2 to see it in action. I would like to highlight that I will not cover all the concepts described inRead more →

I want to explain how to bring Case Management to Kogito using the tools that flexible processes provide.

Previously I introduced flexible processes in Kogito. See part 1 for a generic introduction and part 2 to see it in action.

I would like to highlight that I will not cover all the concepts described in the CMMN specification, just the most important and the ones that we considered a must for having a good Case Management experience. If you feel we are not covering some important use cases, don’t hesitate to join the Kogito Community and ask us directly.

The blog post contains is structured as follows:

Go through the most common Case Management concepts and explain how to use Kogito’s flexible processes in each case.
How to use Documents in Kogito.

Concepts

From my experience I find Case Management open to interpretation and what I will define is my point of view so it is fine to not agree with what I say 🙂

Case

A Case can be understood as an unstructured process where there isn’t necessarily a defined starting or end point. Maybe none of them even exist.

Cases are driven by Knowledge workers and they decide what information is missing or when the Case is ready to move forward or back to a previous stage.

So if we consider a Case a special process where we don’t need a start or an end… In Kogito we can say our process is an Ad-Hoc process.

By checking the Ad-Hoc flag our process will not require to have a start node because we will be adding individual tasks or groups of tasks that are known as discretionary tasks.

This is a hypothetical case for a public organization grant funding. You can see several discretionary tasks for preparing the proposal, adding comments and archiving the proposal. They do not depend on any previous action but may depend on the state of the case, that is, the Case file.

Case File

Knowledge workers will manipulate and transform the data used during the life of the Case. This data is the Case File. As we are in a process, the Case File will just be our Process Data. Sub-processes and tasks can share the data, either totally or partially.

Case ID

The Case ID is a value that helps Knowledge workers uniquely identify the Case, a correlation key. It is usually a sequential number with a prefix. E.g. CASE-00010230

In Kogito there is the concept of Business Key that you can set to each process instance, i.e. the Case instance upon creation. The process will always be created using a generated UUID but it will be possible to identify the process by the Business Key.

Milestones

The concept of a milestone is almost self-descriptive. We can define it as a single point of achievement within a case instance. No work is associated with a milestone, but it will allow the possibility to work on a different set of tasks after a certain state is reached.

A Milestone will wait for a signal to occur, the event will have the same name as the Milestone.

In this example, when the Resolve Case service task is executed, the “CaseResolved” is emitted. This signal triggers the CaseResolved milestone.

Milestones may have “Conditions” to control their completion. Conditions are defined using Java expressions and will be re-evaluated each time a variable is updated.

These conditions allow you to synchronize multiple events or states into a single point. Imagine a case where our “Approved” milestone should be completed when it has been reviewed by the expert and the financial availability check has also succeeded. We would have a condition like the following:

financialAvailability.isApproved() && technicalReview.isApproved()

Stages

Stages can be defined as a group of tasks that are executed for a common reason. In this example, there is the “Proposal preparation” stage that includes two tasks related to the preparation of a proposal. Once the proposal is ready to be reviewed, the stage will complete and the Case will move to the next stage.

In flexible processes we consider that Stages are a sub-process embedded in the main process. The formal name for that is Ad-hoc sub-process. You don’t need to define any task within a Stage but it will help with business visualization and grouping. Ad-hoc sub-processes can have activation and completion conditions that allows you to set the stage as completed or to re-use it when needed.

For example, if the knowledge worker responsible for the documentation review concludes that there is something missing this stage can be activated again so that the user can update or attach more documents.

Ad-Hoc Fragments

Discretionary tasks are any type of task that users or the knowledge workers can interact with at any point in time during the Case life cycle.

These tasks can be of any type and can be triggered by signals (internal or external). In flexible processes a discretionary task or an ad-hoc fragment is any node that:

Is not a start node
Is not linked with a previous node. I.e. doesn’t have an incoming connection
Is not auto-started

Case Life cycle

Cases have a life cycle, they can be started, aborted, suspended, completed or terminated.

After receiving a new request containing the initial Case File data the process will be started. If it has a start node and/or ad-hoc auto-start nodes, they will all be executed.

Then users and knowledge workers can interact with the discretionary tasks or any other active tasks in the process.

The End node sets the process as completed but not terminated. Tasks are still available in case the knowledge worker wants to execute any more actions.

The process terminates after reaching the Termination End node.

It is important to mention that once the case is terminated, Case data will remain in the Data Index but will be removed from the engine memory. See more about the Data Index

Documents in Kogito

Case Files very often contain documents but nowadays most companies and individuals rely on cloud services for that document management. That means the most common way to work with documents is by using the reference or the minimal metadata to uniquely identify such documents in a specific cloud provider.

For example in Microsoft OneDrive, if you wanted to identify a document you will need to provide:

userId
driveId
itemId

Whereas for Google Drive it seems enough to just keep the fileId (similar to the OneDrive’s itemId)

So it seems reasonable to create a POJO that represents a reference to the document depending on your organizations requirements and just provide the necessary metadata to identify the documents in the cloud provider.

With this solution, Kogito doesn’t need to directly handle documents which is something that it wasn’t meant to do. It’s up to the developers to provide the best experience with documents to their users and knowledge workers. Besides it provides an additional layer of confidentiality and security already defined at the organization level.

Examples of front-end applications:

Embed a widget to let the user pick documents directly from their OneDrive folders and attach them without even uploading them.
Let the users upload the document to an application-managed drive to just keep the document metadata.

Flexible processes in Kogito – Part 2

by Ruben Romero Montes - July 13, 2020 Process Article

In the previous blog post Flexible processes in Kogito – Part 1 I talked about the new components and functionalities for flexible processes introduced in Kogito 0.12.0. In this post I will walk you through an example process putting all this in practice. Service Desk process The flexible-process-quarkus example is available in the kogito-examples GitHubRead more →

In the previous blog post Flexible processes in Kogito – Part 1 I talked about the new components and functionalities for flexible processes introduced in Kogito 0.12.0.

In this post I will walk you through an example process putting all this in practice.

Service Desk process

The flexible-process-quarkus example is available in the kogito-examples GitHub repository. In the project README.md file you can find instructions to build and execute the process.

It describes a service desk process where customers open a ticket related to a problem or question about a specific product.

First, the ticket goes through a triage process where it is assigned to a support team and then a random engineer will be designated. If the system can’t decide which team has to handle the ticket, the support engineer will be assigned manually.

At any moment both, the engineer and the customer, can add comments until any part is satisfied and the case can be considered as Resolved. If for any reason, someone decides to add another comment, the case will be reopened and assigned to the other party until it is resolved again.

Finally, once resolved, the customer will have a task to send a satisfaction questionnaire considering the case as closed.

Overview

This is a diagram of the service desk process:

Create a support case

In order to start the process, an initial supportCase object has to be provided in the request. It will contain information about the product, the customer and a description of the problem itself.

{ 
  "supportCase": {   
    "customer": "Paco the customer",   
    "description": "Kogito is not working for some reason.",   
    "product": {     
      "family": "Middleware",     
      "name": "Kogito"   
    } 
  }
}

The triage

The Triage sub-process is automatically started when the process is instantiated and the support group is decided through the following decision table that takes as the entry the product name and family and returns the supportGroup.

You can see that for the case where the product family is not in the list. The engineer will have to be assigned manually.

Adding comments

The Work case sub-process is also auto-started. Anyone from the customer group can add comments and the same for people from the support group.

As mentioned above, an empty POST request has to be sent in order to create a task that can be used to add a comment. Imagine it as the “Add comment” button that renders the form next.

So, after sending this empty POST you will see something like this:

curl -D - -XPOST -H 'Content-Type:application/json' -H 'Accept:application/json' http://localhost:8080/serviceDesk/b3c75b24-2691-4a76-902c-c9bc29ea076c/ReceiveSupportComment

HTTP/1.1 200 OK
Content-Length: 305
Link: </b3c75b24-2691-4a76-902c-c9bc29ea076c/ReceiveSupportComment/f3b36cf9-3953-43ae-afe6-2a48fea8a79a>; rel='instance'
Content-Type: application/json

{
  "id":"b3c75b24-2691-4a76-902c-c9bc29ea076c",
  "supportCase":{
    "product": {
      "name":"Kogito",
      "family":"Middleware"
    },
    "description":"Kogito is not working for some reason.",
    "engineer":"kelly",
    "customer":"Paco the customer",
    "state":"WAITING_FOR_OWNER",
    "comments":null,
    "questionnaire":null
  },
  "supportGroup":"Kogito"
}

The URL present in the Link HTTP header can be used when rendering the form action. Don’t forget to add the user and the group query parameters. Note that the data sent must be in JSON format. This example assumes the Javascript framework will deal with that.

<form action=”/serviceDesk/b3c75b24-2691-4a76-902c-c9bc29ea076c/ReceiveSupportComment/f3b36cf9-3953-43ae-afe6-2a48fea8a79a?user=kelly&group=support” method=”post”>
  <label for="comment">Comment:</label>
  <input type="text" id="comment" name="comment">
</form>

Case resolved

Let’s say the customer is happy with the resolution provided by the support engineer. The customer decides to click the “Resolve Case” button.

This button sends an empty POST which triggers the service task. The case is then set as Resolved and a “CaseResolved” event is emitted.

Closing the case

The event will signal the milestone which doesn’t have any Condition. Then, the Questionnaire task is started and assigned to the customer.

The task expects a comment and a numeric evaluation based on the customer’s satisfaction. As a result, the questionnaire is added to the support case and the case is finally closed.

Flexible processes in Kogito – Part 1

by Ruben Romero Montes - July 13, 2020 Process Article

What are flexible processes you might be wondering about? If you are familiar with Case Management you will get it quickly. If not, I suggest you start here. As a brief introduction. In Case Management there is the concept of Case that is opened. Then the knowledge workers will perform tasks or update the Case-relatedRead more →

What are flexible processes you might be wondering about? If you are familiar with Case Management you will get it quickly. If not, I suggest you start here.

As a brief introduction. In Case Management there is the concept of Case that is opened. Then the knowledge workers will perform tasks or update the Case-related information, known as Case File. At a certain point the Case can be considered as closed. Cases might eventually be reopened, depending on the situation.

Case Management is a way to provide traditional processes with more flexibility because the execution path is not rigid. This is an advantage when the process can’t be fully automated or the scope is hard to measure. A typical example is related to healthcare. A patient has a file that is accessible to the doctor and any health professionals assigned to the patient. They take actions, make different decisions and assessments until the patient is diagnosed and treated.

Instead of implementing Case Management as defined in the CMMN specification we decided to use BPMN extensions to provide a similar experience. This is what we call Flexible processes in order to avoid false expectations and misunderstandings.

What’s new?

Ad-Hoc process

Starting with the processes themselves, the first thing to do is to say that your process is an ad-hoc process in the modeler. For that, open the process properties and check the Ad-Hoc flag. This flag tells the modeler that you are defining a flexible process that might or might not have a start node.

Ad-Hoc sub-processes

An Ad-Hoc sub-process is a way to wrap related tasks together. Consider it as the equivalent to Stages in Case Management.

This type of sub-processes have some interesting features like the Activation and Completion Conditions. Activation Conditions control when the tasks within a node can start their execution. On the other hand, Completion Conditions decide when is time to move on to the next node. The same applies to the completion condition after the execution of all the nodes. The sub-process node will wait for the right state to complete and continue to the next node, if any.

These conditions are defined as Java lambdas and they will be re-evaluated each time a process variable is updated.

Milestones

This is a concept directly taken from Case Management. Although the same functionality can be achieved through different BPMN components we considered some users might find it simpler to understand and to apply.

Milestones are a node that can be automatically started by an event with the same name of the node

Additionally, they can have an optional “Condition” input assignment. Use a Java expression to decide when this node is ready to be completed and move forward to the next one.

Imagine the example about the patient. Possible milestones could be “Patient diagnosed” or “Patient recovered”. Each milestone implies that a specific state has been achieved and it’s time to move on to the next one.

AdHoc Fragments

We call AdHoc fragments nodes that don’t have an incoming connection to any other node and are not start nodes. AdHoc fragments may or may not start automatically, depending on the AdHoc Autostart flag.

If the node is automatically started it will be executed when the process is created. However, when this flag is not set, the only way to trigger the node execution is with a signal. Processes receive signals externally through the REST API, internally by using events or programmatically. See more about external signals in the next section.

REST API

For non-flexible processes, the main POST request will trigger the Start node whereas in a flexible process it will just create the process instance. All nodes with the AdHoc Autostart flag will start with the process.

For the case of the AdHoc fragments an empty POST can be sent to start the execution of the node. In the specific case of the HumanTasks where a new task is created, users or API consumers will most likely be interested in the generated task URL. This is possible through the Link HTTP header present in the response. It will contain a relative path with the process instance ID, the task name and the task instance ID.

curl curl -D - -XPOST -H 'Content-Type:application/json' -H 'Accept:application/json' http://localhost:8080/serviceDesk/b3c75b24-2691-4a76-902c-c9bc29ea076c/ReceiveSupportComment

HTTP/1.1 200 OK
Content-Length: 305
Link: </b3c75b24-2691-4a76-902c-c9bc29ea076c/ReceiveSupportComment/f3b36cf9-3953-43ae-afe6-2a48fea8a79a>; rel='instance'
Content-Type: application/json

{
  "id":"b3c75b24-2691-4a76-902c-c9bc29ea076c",
  "supportCase":{
    "product": {
      "name":"Kogito",
      "family":"Middleware"
    },
    "description":"Kogito is not working for some reason.",
    "engineer":"kelly",
    "customer":"Paco the customer",
    "state":"WAITING_FOR_OWNER",
    "comments":null,
    "questionnaire":null
  },
  "supportGroup":"Kogito"
}

Give me an example!

In the next blog post I use all this in an example. Go to Flexible processes in Kogito – Part 2 and see it in action!

Delivering domain logic with Custom Tasks

by Karina Varela - July 5, 2020 Process Article

Custom Tasks, a.k.a. custom Work Items are used when the natively provided components are not clear enough to demonstrate the required domain demands. See examples of domain-specific tasks that a business user would find useful to have available in the process designer: Enhance customer data; Validate Personal ID against Official State Service; Check customer healthRead more →

Enhance customer data;
Validate Personal ID against Official State Service;
Check customer health plan;
Calculate tax over an acquisition;

Creation of custom work item handler demands the involvement of a developer which knows Java. Once developed and deployed, the custom WIH will be displayed in the process designer components tab, along with the other bpmn2 tasks. In this way the business automation specialists can drag and drop it into the flow, and care only about the parameters, and not about the logic execution itself.

Let’s separate the Custom WIH in four topics:

Development: Creation of the project and development of the core logic.
Deployment: Provision of the custom tasks in a service repository.
Installation: Act of choosing available tasks from the service repository and installing into a Business Central.
Usage: Using the new custom task in process design.

Once developed, deployed and installed, the custom task is displayed in the process designer pallet, under the service tasks option ready to be used during the authoring phase.

Development

To develop a custom WI, a new Java project needs to be created. This project can be created from scratch or from an official jBPM maven archetype.

Here is some important information the developer should know:

Creating the project that will hold the WI, based on the archetype will provide all the necessary structure including test samples; It will also provide generation, deployment and installing features.
To use the archetype it is necessary to clone the project jbpm-work-item to the local environment. This will eliminate a lot of manual work and save dev time.
The archetype is org.jbpm.jbpm-workitems-archetype, and it is available in the project https://github.com/kiegroup/jbpm/tree/master/jbpm-workitems/jbpm-workitems-archetype .
The project is Maven based and can be edited in your favorite IDE; The project core is consisted initially by one class: CustomWorkItemHandler.java (it may have a different prefix other than “Custom”)
In this class is the method where the developer should code the domain specific custom logic, executeWorkItem. This method is executed when your task is activated;
Then, if the task finishes successfully, the engine will trigger the method completeWorkItem;
If the task gets aborted, the abortWorkItem method will be triggered.

Creating a custom task

Let’s see how to create it using a maven archetype org.jbpm.jbpm-workitems-archetype which provides all the basic starters already set and ready to use.

[INFO] For versions prior to jBPM 7.40.0 , it is required to use JDK 8. You can confirm you Java version by running the “java -version” command on your terminal. Check details here: https://issues.redhat.com/browse/JBPM-9204

The first step is to download the project which contains the official work item archetype:

$ mkdir ~/projects/jbpm-getting-started-lab/ && cd ~/projects/jbpm-getting-started-lab/
$ git clone https://github.com/kiegroup/jbpm-work-items
$ cd jbpm-work-items
$ mvn clean install

It might take a while until the dependencies are downloaded. Then, it is possible to create a new project using the archetype:

$ mvn archetype:generate -DarchetypeGroupId=org.jbpm -DarchetypeArtifactId=jbpm-workitems-archetype -DarchetypeVersion=7.40.0-SNAPSHOT -DgroupId=org.kie.learning -DartifactId=hello-workitem -DclassPrefix=Custom -Dversion=7.40.0-SNAPSHOT -DarchetypeCatalog=local

The following parameters can be changed according to your environment and needs.

artifactId: name of your project
groupId: group id used in your project
classPrefix: will be appended to the work item files;
archetypeVersion: Should be set according to the version of jBPM you just cloned. You can check that on the pom.xml using the command

$ head -10 ~/projects/jbpm-getting-started-lab/jbpm-work-items/pom.xml

After executing the archetype generation command, Maven will download all the required libs to build the project. You will be asked to confirm if the data is correct. If it is correct, input Y and press enter.

A new project will be created in the current directory with the name of your artifactId, in this example, hello-workitem. The developer can import the project to eclipse, check its structure, created classes, annotations, tests and implement the custom logic.

Once the development is done, compile the project with mvn clean install. The file jar file is created inside the target folder.

Now, it is ready to be deployed to jBPM and configured in BA Projects.

Deployment

Once the coding phase is done, the project should be compiled and installed in a maven repository which is visible for Business Central (during authoring) and for Kie Server (for execution).

Compile the project using the command below and the jar will be available inside target folder.

$ cd hello-workitem/
$ mvn clean package

Install it into the maven repository or do this using business central UI.

Access Business Central settings (right up corner settings icon), and access Service Tasks Administration menu.

Click on “Add Service Task” button and upload the jar generated inside your project target folder i.e. ~/projects/labs/hello-workitem/target/hello-workitem-7.40.0-SNAPSHOT.jar.

After deploying it, look for it in the task list and enable it.

If you open the class src/main/java/org/kie/learning/CustomWorkItemHandler.java, you will see the class-level annotation defining this WIH name as “CustomDefinitions”.

The custom WIH will now be available to be installed in any project. Let’s proceed.

Installation

Now that your Business Central and Kie Server have access to your custom task (the jar is in the maven repository), the business application can be configured.

Access the project, and open the project settings;

Select the “Service Tasks” menu

Locate your custom task in the list and click on the “Install” button.

Check if it is properly configured under Deployment, Work Item Handler, if the WIH with the name you configured and class are present, for example: CustomDefinitions, new org.kie.learning.CustomWorkItemHandler()

Hit the save button.

If you open a new business process and check the tasks, you will be able to see your custom task:

That’s it, you can now create custom tasks with so that the user who is authoring business process can re-use domain logic in a more customize and visible way.

This blog post is part of the fourth section of the jBPM Getting started series:
Effective modeling, Integration and Delivery.

Getting Started with the Kie Server Java API

by Karina Varela - June 28, 2020 Process Article

Kie Server Java client API is used when it’s necessary to create a Java service to interact with a remote Kie Server (not an embedded engine). Consider that you have an architecture with a Kie Server running your business projects and you want to consume them using a Java service running in another application server (deploying applications in different JVMs is a recommended practice). To allow this service to interact with deployed Kie Containers, it first needs to be authenticated and authorized to execute operations inside Kie Server. Once the service is authorized, it is now possible to create and manipulate Kie Deployments, Containers, interact with business assets and query data.

Kie Server Java client API has core services that can be used in your Java classes to authenticate, manage and consume the assets. These services facilitate the development and interaction with business assets since it is not required to create and parse each detail of the requests (this is a need, for example, in front-end applications which connect directly to Kie Server).

TIP: Instead of presenting details of each available method in the services, the author opted to present the documentation and source code, which is the best origin of reliable knowledge. All the classes presented in this section are in the source code in the jBPM repository: https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server-parent/kie-server-remote/kie-server-client/src/main/java/org/kie/server/client/

The available services that can be used to interact with Kie Server and business projects are:


Kie Management Related:	`org.kie.server.client.KieServicesClient org.kie.server.client.KieServicesConfiguration org.kie.server.client.KieServicesFactory`
Cases Related	`org.kie.server.client.CaseServicesClient; org.kie.server.client.DocumentServicesClient`
Rules Related	`org.kie.server.client.DMNServicesClient org.kie.server.client.RuleServicesClient`
Solver Related	`org.kie.server.client.SolverServicesClient`
Process Related	`org.kie.server.client.ProcessServicesClient org.kie.server.client.QueryServicesClient org.kie.server.client.JobServicesClient`

Every client application needs to be authenticated and authorized to interact with Kie Server. The necessary role to authorize this interaction is kie-server role. The user containing this role should be configured in the application server where Kie Server is running, or, it should exist in the external IDP (i.e. Keycloak).

The following guideline provides overall steps on how to configure the Kie Client Java API in any Java application. Details on REST and JMS integration configuration are provided in sequence. To allow an application to interact with business assets:

Add the kie server client library as a dependency in the client application project:
- To consume remote kie servers, add org.kie.server:kie-server-client dependency in the pom.xml file.
Create a configuration class (extending KieServicesConfiguration) . This class indicates whether this is a JMS or a REST client. Additionally, it contains the connection settings used to integrate with the Kie Server. Let’s see more details on each respective topic in a while.
Once the configuration is set, use KieServicesFactory to create a new Kie Services Client. It’s recommended that this is done only once, for example during the application startup. All the client services presented in the previous services table are accessible from KieServicesClient instance. Use the configuration created on step 2, as to create this object:

kieServicesClient = KieServicesFactory.newKieServicesClient(conf);

4. Choose the services you need in this client, and initialize them. Example:

ProcessServicesClient processService = kieServicesClient.getServicesClient(ProcessServicesClient.class);

5. Use the services as you wish. For example, to start a new process instance:

processService.startProcess("container:id", "processId");

After following these steps this application is now a client ready to interact with any deployed business application inside the configured remote Kie Server. The developer can now do all kinds of integration: fire rules, manage and interact with processes, cases, and resource planning assets.

This blog post is part of the sixth section of the jBPM Getting started series:
Consuming Business Assets

Mastering Transaction Boundaries

by Karina Varela - June 28, 2020 Process Article

When planning usage of processes that are complex, long-running, and with possible points of failures like custom work item handlers, asynchronous tasks, timers, signals, and service tasks, it is crucial to understand how jBPM deals with transactions. This knowledge might save some troubleshooting hours if you have persistent processes. “Why?“, you might ask: if theRead more →

This knowledge might save some troubleshooting hours if you have persistent processes. “Why?“, you might ask: if the process is not properly designed and an unhandled error occurs, you may end-up with tasks being triggered more times than you planned.

Let’s drill down.

During the following process execution, jBPM will execute all these tasks in a single transaction:

Therefore, if the process reaches Service B, and it throws an exception, Service A won’t be rolled back. This process will not be persisted on the database, it is like it was never executed. This would happen because there is no wait state point in this process.

To the engine, a wait state is any point during the process execution which it might need to wait for some external intervention. When this occurs, the engine persists the process state in the database. These are the possible wait states of a process:

Human Tasks
Catch events (signals, timers)
Async Tasks (marked with Async flag)

So, if we consider the following process, what will happen if Service B throws an exception?

If service B with an unrecoverable error and throwing exception, Service A would be triggered three times. (worrying, right?)

In this case, the process was persisted when the human task was completed. So, when Service B threw an exception, the transaction will roll back and return to the Human Task again. Gateway is validated, Service A is triggered the second time, and then, Service B is triggered. If B throws an exception, the execution again returns to the Human Task. This will happen as many times as configured in the engine retry count, which by default is three.

In cases like the one represented below, by simply configuring Rest Task 2 as Async you can make the engine persist the process state, and in case of an error on REST Task 3, Rest Task 1 and 2 would not be executed again.

To avoid situations like this, during the process authoring, have the transaction boundaries clear in your mind. Choose wisely which task should be async, which are the wait states, and if you need to create any wait state or handle errors with compensation events to avoid unexpected businesses outcomes.

Summary

Understanding how the engine works will help business automation specialists and developers to deliver fine-tuned projects that perform better on the jBPM engine. The business automation specialist should be able to absorb the business requirements and be able to reflect this on the project not only by authoring the assets but by improving the execution of these assets adjusting every configuration to best perform in each scenario and by being able to understand the impacts of the transaction boundaries in each delivered process.

This blog post is part of the fifth section of the jBPM Getting started series:
Techniques to boost a BA Project

Persisting custom data: Configuring external persistence

by Karina Varela - June 17, 2020 Process Article

When working with business processes, it is expected to work with persistent process data scenarios. Considering this situation, it is common for users to use a different database to store process data, apart from the database where the domain information is stored. As an example, storing critical information from customers apart from the engine databaseRead more →

As an example, storing critical information from customers apart from the engine database is an expected data architecture. In this way, the user can maintain the data consistent and isolated. But what if these objects, stored in a different database, needs to be used in one of the business automation projects?

[INFO] Many of the concepts here applied are valid for any application which involves distributed transactions (XA Transactions), this means, any application which might possibly have a transaction which spawns through two or more different databases. An overview of how application deployed in Java EE application servers, communicates with a database can be found at this blog post: Datasources, what, why, how?

Let’s understand how to configure and access different databases within the same project.

Pluggable Variable Persistence (PVP)

Here are the steps required to make a business automation process store process variables (domain information) in a different database:

Configure the app server datasource pointing the database where you want to store the custom data;
Make sure custom POJOs (the object to be persisted) are a JPA object
1. Data Object must implement Serializable interface;
2. Must be a JPA Entity;
3. Must have a unique id, a primary key;
Configure business automation project
1. Configure a JPA Marshalling Strategy;
2. Configure the persistence unit (pointing to the datasource mentioned on the first step);

Once this is done, every time this object gets created or updated during the process execution, it will be properly persisted on the database. Let’s check this with a hands-on exercise.

Persisting custom objects using PVP

Bootstrap a database

To run this example, using docker to start a database is the easiest way to get a database up and running. Make sure you have docker running in your environment. Let’s create a directory to store the database information.

$ mkdir -p ~/projects/jbpm-getting-started-lab/postgresql

Make sure you have Docker up and running. Then you can start a Postgres container:

$ docker run --name jbpm-postgres-container -e POSTGRES_PASSWORD=psqlpass -d -p 6543:5432 -v $HOME/projects/jbpm-getting-started-lab/postgres:/var/lib/postgresql postgres:9.4

This command will download the image (if you don’t have it locally), start a container named postgres, based on the latest PostgreSQL image. expose the internal port 5432 opened by PostgreSQL, to be accessed externally also in 6543.

Let’s enter in this SQL Server to create a new database for our jBPM tables. Run the command below to get the Container ID of this psql container:

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
620350186bbe postgres:9.4 "docker-entrypoint.s…" About a minute ago Up About a minute 0.0.0.0:6543->5432/tcp jbpm-postgres-container

Use the whole ID, or simply the first two numbers, to enter the container. Then, we will start the psql client:

$ docker exec -it jbpm-postgres-container /bin/bash 
$ psql -h localhost -U postgres -d postgres

Now, let’s create a database to be used by jBPM, with a new a user and password. This user needs permision on this new database. The tables will be created automatically by jBPM on startup.

[TIP] You might want to create additional indexes on some tables and columns in your production environment

CREATE DATABASE jbpmdb;
CREATE USER jbpmdb WITH ENCRYPTED PASSWORD 'jbpmdb';
GRANT ALL PRIVILEGES ON DATABASE jbpmdb TO jbpmdb;

And create another database, to store the specific domain data.

CREATE DATABASE labpvp;
CREATE USER labuser WITH ENCRYPTED PASSWORD 'labuser';
GRANT ALL PRIVILEGES ON DATABASE labpvp TO labuser;

When done, type q and press enter, to quit psql client, and then exit to exit the container.

Configuring the Application Server

Now, let’s configure WildFly: we will create two datasources one connecting to jbpmdb and other to labpvp . Once the datasources are configured, applications can start connecting to these databases.

In this example we expect that you have downloaded jBPM and have it available in your ~/projects directory. If you want to use the commands here, you can optionally create a symbolic link for the folder with the command below:

$ ln -s ~/projects/jbpm-server-7.38.0.Final-dist ~/projects/jbpm

Configuring WildFly basically requires two steps:

Adding a JDBC driver (the responsible for teaching WildFly how to talk the specific database language);
Adding a datasource with the credentials, connection URL, and driver information.

The simplest way to add a JDBC driver to WildFly is deploying it. Download postgresql-42.2.2.jar and place it into ~/projects/jbpm/standalone/deployments. WildFly will immediately tell you the driver is deployed:

16:11:07,515 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) WFLYJCA0005: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 42.2)
16:11:07,540 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0018: Started Driver service with driver-name = postgresql-42.2.12.jar
16:13:33,885 INFO [org.jboss.as.server] (ServerService Thread Pool -- 45) WFLYSRV0010: Deployed "postgresql-42.2.12.jar" (runtime-name : "postgresql-42.2.12.jar")

Let’s use the JBoss CLI script, which is less error-prone, to do the configuration. Start your WildFly in one terminal tab, and open another terminal tab so you can connect to it using CLI.

$ ~/projects/jbpm/bin/jboss-cli.sh -c

Add a new datasource, informing the connection data, and your deployed driver name:

[standalone@localhost:9990 /] xa-data-source add --name=psqljBPMXA --jndi-name="java:/jboss/datasources/psqljBPMXADS" --user-name=jbpmdb --password=jbpmdb --driver-name=postgresql-42.2.2.jar --xa-datasource-class=org.postgresql.xa.PGXADataSource --xa-datasource-properties=[{ServerName=localhost,PortNumber=6543,DatabaseName=jbpmdb}]

Now, let’s add a datasource to connect to our domain-specific database, labpvp:

[standalone@localhost:9990 /] xa-data-source add --name=psqlLabPVP --jndi-name="java:/jboss/datasources/psqlLabPVP" --user-name=labuser --password=labuser --driver-name=postgresql-42.2.2.jar --xa-datasource-class=org.postgresql.xa.PGXADataSource --xa-datasource-properties=[{ServerName=localhost,PortNumber=6543,DatabaseName=labpvp}]

The following test commands validate both datasource configurations:

[standalone@localhost:9990 /] /subsystem=datasources/xa-data-source=psqljBPMXA:test-connection-in-pool
{
"outcome" => "success",
"result" => [true]
}

Finally, we need to tell jBPM to stop using the H2 database and start using Postgres by connecting through the datasource with JNDI name: java:/jboss/datasources/psqljBPMXADS .

[standalone@localhost:9990 /] /system-property=org.kie.server.persistence.ds:write-attribute(value=java:/jboss/datasources/psqljBPMXADS, name=value)
[standalone@localhost:9990 /] /system-property=org.kie.server.persistence.dialect:add(value=org.hibernate.dialect.PostgreSQLDialect)

Restart jBPM.

It will bootstrap creating its tables inside the Postgres in your docker container. You can confirm this by getting into your Postgres container and listing the tables:

$ docker exec -it jbpm-postgres-container /bin/bash
root@620350186bbe:/# psql -h localhost -U jbpmdb -d jbpmdb
psql (9.4.22)
Type "help" for help.
jbpmdb=>d

Creating persistent objects with Business Central

Scenario: You joined a team which has on-going project, hello-jbpm. In this project, the final user does a question, complain or suggestion and gets an automatic or a manual answer. You noticed that the data architecture can be improved by storing the reported issue and person details, into a separate database. apart from the one used by the engine.

Import project 02-customer-service-jbpm if you don’t have it in your business central yet. You should see it in your space:

In order to persist a POJO into a database, we need will make use of JPA benefits and to convert it into a JPA Entity.

Open hello-jbpm project, and notice both data object named Issue and the Person.

You can use the filter to see only specific types of assets. In this example the list is filtered to show only Model assets.

Let’s start by configuring Person. By clicking on the “Source” tab you can view it’s code.

[TIP] In order to be persisted, classes should implement java.io.Serializable interface. By default, Business Central creates the Data Objects implementing Serializable interface.

Transform it into an entity by adding @javax.persistence.Entity annotation;
Inform the name of the table you want to store this Data Object with the annotation @javax.persistence.Table(name = "Person")
This class does not have a primary key yet. Add an id, with type Long to Person.java. Don’t forget the attribute should have the get and set method and be annotated with @javax.persistence.Id.

Person.java should look like this:

@javax.persistence.Entity 
@javax.persistence.Table(name = "Person")
public class Person implements java.io.Serializable {

    @javax.persistence.Id
    @javax.persistence.SequenceGenerator(name = "ID_GENERATOR", sequenceName = "PERSON_ID_SEQUENCE")
    private java.lang.Long id;

Click on the save button.

Configuring business application persistence unit with Business Central

The persistence unit, if the configuration which tells a Java EE application which datasource it must use to connect to the database. To configure a business application to persist process variables in a custom database, inform the datasource details in the persistence unit, and create a Marshaller configuration. This Marshaller configuration allows the engine to convert the variables data to/from process and database.

When the JPA Marshaller is configured, every JPA Entity used as a process variable, is automatically persisted in the database pointed by the application used datasource.

To configure the persistence unit details, access the project Settings, and select the Persistence option.

2. Considering we are using PostgreSQL and the datasource configured in the last step, use the following values in the form:

Persistence Unit: customer-service-jbpm-pu
Data Source java:/jboss/datasources/psqlLabPVP
hibernate.dialect: org.hibernate.dialect.PostgreSQLDialect
hibernate.show_sql: true

3. Set the show_sql attribute to true, to enable logs and permit checking in the server logs if the entity is being manipulated as expected. Save the configuration.

4. Make sure you scroll down and add the persistable class, Person:

4. Still in the project Settings, configure the JPA Marshaller. Access the Deployments option, and select Marshalling Strategies.

5. Click on “Add Marshalling Strategy“, insert the following value and hit save:

new org.drools.persistence.jpa.marshaller.JPAPlaceholderResolverStrategy("customer-service-jbpm-pu", classLoader)

Now you have JPA Classes ready to be used as process variables, and to be automatically persisted in a different database!

You can check the result of this work by clicking on the Deploy button. If everything is properly set, you should see something similar in the server log:

17:41:12,801 INFO [stdout] (default task-20) Hibernate: create table Person (id int8 not null, birthDate timestamp, name varchar(255), primary key (id))

Start a new process instance, and validate if the object was persisted in the database table you specified.

This blog post is part of the fifth section of the jBPM Getting started series:
Techniques to boost a BA Project

Runtime Strategy: Choose wisely

by Karina Varela - June 16, 2020 Process Article

Kie Server can be configured to deal differently with the requests it receives and the objects it stores in memory or in the database. Properly configuring how the engine deals with the objects in memory, ensures a project with fewer resource consumption and avoids unexpected behaviors. Runtime Strategy configuration affects directly how the engine dealsRead more →

Runtime Strategy configuration affects directly how the engine deals with the lifecycle of the Kie Sessions and objects loaded in memory.

You have to choose between four options, for each new project deployment you create:

Singleton Runtime Strategy
Per Process Runtime Strategy
Per Request Runtime Strategy
Per Case

Choosing a strategy

Understand the key concepts of each strategy to guide your decision of when you should use each of them:

Singleton Runtime Strategy: If you create and deploy a project, this runtime strategy configuration is used. It’s the default configuration. This strategy uses a single Kie Session. This makes things easier for beginners since every inserted object is available in the same Kie Session. Also, jBPM persists the Kie Session, and it is reused if the server restarts.

Rule execution within processes can be impacted. Consider that: if process instance A inserts person John to be evaluated by business rules. Process instance B, inserts Maria. Later, when process C fires rules for its own person, John and Maria will still be in memory and will be evaluated by process C rules improperly!

When using this configuration, process execution happens within a synchronized Runtime Engine: it is thread-safe. Consequently, this characteristic can affect and bring consequences on performance. If you expect a high workload, or if the project use timers or signals in the process definitions, you may want to consider a diﬀerent strategy for your production environment.

Per Request Strategy: defines a stateless behavior. The engine will create one Kie Session per request and destroy it at the end. The Kie Session will not be persisted. This is a good choice for high workload environments.

The following situation can occur: Consider two requests executed simultaneously to interact with the same process instance. One of the two requests might lock a database row to update it, and the other request might try to update it as well. This will lead to an OptimisticLockException.

This strategy might do the implementation more challenging if your project uses timers events or if the process involves business rule tasks.

Per Process Instance Strategy: recommended when your process uses timers and businessrule tasks. The Kie Session is created when the process instance starts, and it dies, when the process instance ends. This is usually adequate for most use cases.

Keep in mind: creating Kie Bases is an expensive operation. Creating new Kie Sessions is cheap.

The engine stores the Kie Session in the database, and always use the same Kie Session for the same process instances.

Per Case: this strategy should be used if you are using a Case Management project. If you create a new “Case Project”, this strategy is selected by default. The Kie Session will last while the case is still opened (active).

Now, let’s check the possible places to configure Runtime Strategies, and when should each one be used.

Choosing where to configure the strategy

Container Level: Affects the deployed kjar. Configuration can be made in kie containers using Business Central via the Execution Servers page.

Project level: The configuration will affect only this project. Configuration can be done via Business Central in the XML file or via. Inside the file src/main/resources/META-INF/kie-deployment-descriptor.xml the following configuration is present: SINGLETON

Server level: No UI Available. A new system property needs to be configured pointing to the new file.

This change will impact all projects from this server. A new deployment-descriptor.xml needs to be provided with all the tags and components (not only the ones which you want to customize). The system property is org.kie.deployment.desc.location and its value must point to a valid accessible file: “file:/path/to/file/deployment-descriptor.xml“

[INFO] If using the server level configuration, make sure to provide a valid XML file. See more details about the configuration in the official documentation, topic “Default deployment descriptor”
https://docs.jboss.org/jbpm/release/latest/jbpm-docs/html_single/#_deployment_descriptors

Finally, considering that we can configure the runtime strategy in three different places, this is how the precedence works by default: Container configuration overrides KJar and Server configs. KJar configuration overrides Server configs.

This blog post is part of the fifth section of the jBPM Getting started series:
Techniques to boost a BA Project

5. Techniques to boost a BA Project

by Karina Varela - June 16, 2020 Process Article

Previous posts of the jBPM Getting Started Series should provide a good base for the understanding of this chapter. Also, basic knowledge about application transactions should provide a better understanding of the chapter. The engine can be tuned for business automation projects to achieve better performance results are achieved. Mainly when involving business rules validation,Read more →

KIE

KIE

Type

Authors

Featured Posts: Process

Flexible processes in Kogito – Part 2by Ruben Romero Montes

Flexible processes in Kogito – Part 1by Ruben Romero Montes

Delivering domain logic with Custom Tasksby Karina Varela

Getting Started with the Kie Server Java APIby Karina Varela

Mastering Transaction Boundariesby Karina Varela

Persisting custom data: Configuring external persi...by Karina Varela

Dealing with Unexpected Errors in Processesby Karina Varela

Getting Started with jBPMby Karina Varela

Kogito 0.9.1 releasedby Kris Verlaenen

Etymology of Kogitoby Kris Verlaenen

Building Business Applications with DMN and BPMNby Edson Tirelli

Control business rules execution from your process...by Maciej Swiderski

Installation

Usage

Walk-through

Concepts

Case

Case File

Case ID

Milestones

Stages

Ad-Hoc Fragments

Case Life cycle

Documents in Kogito

Service Desk process

Overview

Create a support case

The triage

Adding comments

Case resolved

Closing the case

What’s new?

Ad-Hoc process

Ad-Hoc sub-processes

Milestones

AdHoc Fragments

REST API

Give me an example!

Development

Creating a custom task

Deployment

Installation

Summary

Pluggable Variable Persistence (PVP)

Persisting custom objects using PVP

Bootstrap a database

Configuring the Application Server

Creating persistent objects with Business Central

Configuring business application persistence unit with Business Central

Choosing a strategy

Choosing where to configure the strategy

Flexible processes in Kogito – Part 2
by Ruben Romero Montes

Flexible processes in Kogito – Part 1
by Ruben Romero Montes

Delivering domain logic with Custom Tasks
by Karina Varela

Getting Started with the Kie Server Java API
by Karina Varela

Mastering Transaction Boundaries
by Karina Varela

Persisting custom data: Configuring external persi...
by Karina Varela

Dealing with Unexpected Errors in Processes
by Karina Varela

Getting Started with jBPM
by Karina Varela

Kogito 0.9.1 released
by Kris Verlaenen

Etymology of Kogito
by Kris Verlaenen

Building Business Applications with DMN and BPMN
by Edson Tirelli

Control business rules execution from your process...
by Maciej Swiderski