2016/07/27

In the area of microservices more and more people are looking into lightweight and domain IT solutions. Regardless of how you look at microservice the overall idea is to make sure it does isolated work, don't cross the border of the domain it should cover.
That way of thinking made me look into it how to leverage the KIE (Knowledge Is Everything) platform to bring in the business aspect to it and reuse business assets you might already have - that is:

business rules

business process

common data model

and possibly more... depending on your domain

In this article I'd like to share the idea that I presented at DevConf.cz and JBCNConf this year.

Since there is huge support for microservice architecture out there in open source world, I'd like to present one set of tools you can use to build up knowledge driven microservices, but keep in mind that these are just the tools that might (and most likely will) be replaced in the future.

Tools box

jBPM - for process management

Drools - for rules evenalutaion

Vert.x - for complete application infrastructure binding all together

Hazelcast - for cluster support for distributed environments

Use case - sample

Overall use case was to provide a basic back loan solution that process loan applications. So the IT solution is partitioned into following services:

Apply for loan service

Main entry point to the loan request system

Allow applicant to put loan request that consists of:

applicant name

monthly income

loan amount

length in years to pay off the loan

Evaluate loan service

Rule based evaluation of incoming loan applications

Low risk loan

when loan request is for amount lower that 1000 it’s considered low risk and thus is auto approved

Basic loan

When amount is higher than 1000 and length is less than 5 years - requires clerk approval process

Long term loan

When amount is higher than 1000 and length is more that 5 years - requires manager approval and might need special terms to be established

Process loan service

Depending on the classification of the loan different bank departments/teams will be involved in decision making about given loan request

Basic loans department

performs background check on the applicant and either approves or rejects the loan

Long term loans department

requires management approval to ensure a long term commitment can be accepted for given application.

2016/07/14

As part of ongoing development of jBPM version 7 I'd like to give a short preview of one of the changes that are coming. This in particular relates to changes how workbench and kie server are integrated. In version 6 (when kie server was introduced with BPM capability) we have had two independent execution servers:

one embedded in workbench

another in in kie server

in many cases it caused bit of confusion as users were expecting to see processes (and tasks, jobs etc) created in kie server vie workbench UI. To achieve that users where pointing workbench and kie server to same data base and that lead to number of unexpected issues as these two were designed in different way and were not intended to work in parallel.

jBPM version 7 is addressing this problem in two ways:

removes duplication when it comes to execution servers - only kie server will be available - no execution in workbench

integrates workbench with kie server(s) so its runtime views (e.g. process instances, definitions, tasks) can be used with kie server as backend

While the first point is rather clear and obvious, the second takes a bit to see its full power. It's not only about letting users use workbench UI to start processes or interact with user tasks, it actually makes the flexible architecture of kie server to be fully utilized (more on kie server can be found in previous blog series).

In version 6.4 there was new Server Management UI introduced to allow easy and efficient management of kie servers. This came with concept of server templates - that is a definition of the runtime environment regardless of how many physical instances are going to run with this definition. That in turn allow administrators to define partitioned environment where different server templates are representing different part of the organization or domain coverage.

Server template consists of:

name

list of assigned containers (kjars)

list of available capabilities

Once any kie server starts and connects to workbench (workbench acts as controller) then it will be presented in server management under remote servers. Remote servers reflects the current state of controller knowledge - meaning it only changes the list upon two events triggered by kie servers:

start of the kie server in managed mode - which connects to controller and registers itself as remote server

shutdown of the kie server in managed mode - which notifies controller to unregister itself from remote servers

With this setup users can create as many server templates as they need. Moreover at the same time each server template can be backed by as many kie server instances as it needs. That gives the complete control of how individual server templates (and buy that part of your business domain) can scale individually.

So enough of introduction, let's see how it got integrated for execution. Since there is no more execution server embedded in workbench, all that needs it will be carried on by kie server(s). To accomplish this workbench internally relies on two parts:

server management (that maintains server templates) to know what is available and where

kie server client to interact with remote servers

Server management is used to collect information about:

server templates whenever project is to be deployed - regardless if there are any remote servers or not - again this is just update to the definition of the server

NOTE: in case of multiple server templates are available there will be selection box shown on the screen so users can decide which server template they are going to interact with. Again, users do not care about individual remote servers as they represent same setup so it's not important which server instance will be used for given request, as long as one of them is available.

Server templates that do not have any remote servers available won't be visible on the list of server templates.

And when there is only one server template selection is not required and that one becomes the default - for both deployment and runtime operations.

On right top corner users can find server template selection button in case there are more than one server template available. Once selected it will be preserved across screen navigation so it should be selected only once.

Build & Deploy has been updated to take advantage of the new server management as well, whenever users decide to do build and deploy:

if there is only one server template:

it gets selected as default

artifact name is used as container id

by default container is started

if there are more than one server templates available user is presented with additional popup window to select:

container id

server tempalte

if container should be started or not

That concludes the introduction and basic integration between kie server and workbench. Let's now look what's included and what's excluded from workbench point of view (or the differences that users might notice when switching from 6 to 7).

First of all, majority of runtime operations are suppose to work exactly the same what, that includes:

Process definition view

process definition list

process definition details

Operations

start process instance (including forms)

visualize process definition diagram

Process instance view

process instance list (both predefined and custom filters)

process instance details

process instance variables

process instance documents

process instance log

operations

start process instance (including forms)

signal process instance (including bulk)

abort process instance (including bulk)

visualize process instance progress via diagram

Tasks instance view

task list (both predefined and custom filters)

task instance details (including forms)

life cycle operations of a task (e.g. claim, start, complete)

task assignment

task comments

task log

Jobs view

jobs list (both predefined and custom filters)

job details

create new job

depending on status cancel or requeue jobs

Dashboards view

out of the box dashboards for processes and tasks

All of these views retrieve data from remote kie server so that means there is no need for workbench to have any data sources defined. Even the default that comes with wildfly is not needed - not even for dashboards :) With that we have very lightweight workbench that comes with excellent authoring and management capabilities.

That leads us to a last section in this article that explains that changed and what was removed.

Let's start with changes that are worth noting:

asynchronous processing of authoring REST operations has been moved from jbpm executor to UberFire async service - that makes the biggest change in cluttered setup where only cluster member that accepted request will know its status

build & deploy from project explorer is unified - regardless if the project is managed or unmanaged - there are only two options

compile - which does only in memory project build

build and deploy - which includes build, deploy to maven and provision to server template

Now moving to what was removed

since there is no jbpm runtime embedded in workbench there is no REST or JMS interfaces for jBPM, REST interfaces for the authoring part is unchanged (create org unit, repository, compile project etc)

jobs settings is no longer available as it does not make much sense in new (distributed) setup as the configuration of kie servers is currently done on server instance level

ad hoc tasks are temporally removed and will be introduced as part of case management support where it actually belongs

asset management is removed in the form it was known in v6 - the part that is kept is

managed repository that allows single or multi module projects

automatic branch creation - dev and release

repository structure management where users can manage their modules and create additional branches

project explorer still supports switch between branches as it used to

asset management won't have support for asset promotion, build of projects or release of projects

send task reminders - it was sort of hidden feature and more of admin so it's going to be added as part of admin interface for workbench/kie server

Enough talking (... writing/reading depends on point of view) it's time to see it in action. Following are two screen casts showing different use cases covered.

Case 1 - from zero to full speed execution

Create new repository and project

Create data object

Create process definition with user task and forms that uses created data object

Visualize process instance progress - this project does not have image attached so it comes blank

Monitor via dashboards

Before we end a short note for these that want to try it out. Since we have integration with kie server and as you noticed it does not require any additional login to kie server and workbench uses logged in user, there is small need for configuration of Wildfly:
workbench comes with additional login module as part of kie-security.jar so to enable smooth integration when it comes to authentication, please declare in standalone.xml of your wildfly following login module: