2018/07/26

jBPM Workitems Spotlight - GitHub and Slack


So far we have posted a number of articles describing the jBPM Workitem Repository and its features but there was little mention about its actual content and the powerful integration capabilities it brings to your business processes.

Currently the workitem repository includes 25 different workitem groups and a total of 57 individual workitem handlers. These include various integration services with Google,  Dropbox, IBM, Twitter and many more. New workitems can easily be added as was described in this previous article.  Given that the number of workitems in growing at a steady pace we thought to start showcasing them with simple working examples that you can take and use to start implementing your custom integration solutions.

In this article we will focus on two workitem groups, namely GitHub and Slack:




For our simple example to showcase these workitems we will create a business process which fetches all open issues from one of your GitHub repositories, accumulate them into a message and then send this message to a specified channel on Slack notifying you of these open issues and give you simple links to each so you can start addressing them.

First let's look at the pre-requisites for each of the workitems. To start using GitHub workitems the required information is your login data, namely your username and password. For this example we will use the FetchIssuesWorkitemHandler where you will also need to know the name of the repository where you want to fetch the issues from.

To start using the Slack workitem handlers you need to first create a Slack App. Follow this link to get started with that. Once you create your app make sure to enable OAuth so Slack will create an access token for it. This access token is then passed to the workitem handler as it needs it for authentication with the Slack service. The workitem handler we will use here is PostMessageToChannelWorkitemHandler which also needs the name of one of the channels your slack app has access posting messages to.

To follow this example we also assume that you have the KIE workbench+server set up and ready but if you don't you can follow this article to do that literally in minutes. We also assume that you have an existing GitHub repository set up with some real or test issues defined. If you don't you could use this test one

Test GitHub repo with some test issues

With our KIE worbench running log in and create a new project. Within this project create a new business process (with legacy editor as it's currently only one capable of installing workitems from a repository).  Click on the repository icon in the process editor menu bar and connect to your running service repository
Installing workitems from workbench legacy bpmn2 editor
Find the two workitem handlers we mentioned earlier, namely FetchIssuesWorkitemHandler and PostMessageToChannelWorkitemHandler and click on the little wrench icon next to each to install them into your workbench. Note that the install also updates your project pom with all necessary maven dependencies to execute these workitems as well as your projects deployment descriptor xml. 

To finish the setup we do need to edit the projects deployment descriptor slightly, passing in our login information to the github workitem as well as the Slack access token created to the slack workitem so they can authenticate with their respective services correctly:

For this in the project explorer navigate to your projects /src/main/resources/META-INF directory and edit the kie-deployment-descriptor.xml file. Note that under the work-item-handlers element in this xml file the workitem installer has already added the definitions of two workitem handlers we want to use, however it needs to be slightly changed to add the sensitive info we talked about:

So for the GitHub handler we need to add:

<identifier>new org.jbpm.process.workitem.github.FetchIssuesWorkitemHandler("YOUR_GITHUB_LOGIN_NAME", "YOUR_GITHUB_LOGIN_PASSWORD")</identifier>

and for the Slack handler:

<identifier>new org.jbpm.process.workitem.slack.PostMessageToChannelWorkitemHandler("YOUR_SLACK_APP_ACCESS_TOKEN")</identifier>

Note that in the image below I have cut off the sensitive info as I used my personal login information when making the demo

Modifying the kie deployment descriptor

            
Now we should be all set up to create our business process. You can download or import the one used in this example from this Gist.

Our test business process

The example process first fetches all open issues from our testrepo GitHub repository. This list is then saved in a process variable which the script task iterates to create a message. The created message is then used by the Slack workitem to connect to your defined channel and create a new post to it.

You can now build and deploy your worbench process and start and instance of our example process


Starting new instance of the example process

Process instance completed info panel

Once the process has completed execution you should see in your Slack channel the result message:



And that's it :) Let us know what other workitems you would like to see featured next. 







2018/07/19

Easy Workitem installation (jBPM WorkItem Repository)

We added the ability to install workitems hosted by the  jBPM Workitem Repository on any running KIE Worbench instance directly from the repository. itself This lifts some limitations of installing workitems which was so far only possible from within process editors inside each running workbench. It also allows for future integrations with other runtime systems that can take advantage of the hosted workitems.

When browsing workitems inside the repository you will now find the "Install" column:

Install column - Repository homepage

Selecting "Kie Workbench" will trigger the installation modal:

Workitem installation modal

Here you can enter specific information about the running KIE Workbench instance such as URL, Username, Password, Space name, and Project info where this workitem should be installed in.

Clicking the Install button will install all workitem handlers from the selected workitem group to your workbench instance. Upon successful installation you should be able to see the installed workitem handlers inside the selected workbench project.

Install success message

Archive workitem installed in "myproject"


Once installed you can start using your workitems when modeling your business processes:

Start using the installed workitem!

Note that this feature is available only if you are running the workitem repository in "hosted" mode, so by hosting it via the repository-springboot, or the repository-wildfly modules. When serving the repository content from the file system the Install column will not be displayed. 

Another thing to note is that since in almost all cases your hosted repository will have a different origin(domain) than the running workbench instances you are installing workitems to we need to enable CORS on the servers the workbench is running on. If you are running on Wildfly, this can simply be done inside your standalone.xml config:

Wildfly CORS config

Don't forget to change the value of the "Access-Control-Allow-Origin" header to the domain where you are hosting your workitem repository. In this case we use the default http://localhost:8090 which is used when running spring-boot repository setup. 

Last thing to mention is that currently the KIE Workbench servlet filters do not handle CORS preflight requests unfortunately (hopefully this will be changed in the future). Because of this by default the workitem repository is not able to issue CORS requests to the workbench intances. To lift this limitation add this filter definition to your workbench web.xml and restart the server:

Filter definition within KIE workbench


As always feel free to leave any comments and suggestions. Enjoy!





2018/07/17

Performance baseline for jBPM 7 (7.8.0)

The aim of this article is to show a base information about performance of the jBPM to set a baseline and to answer basic question how good jBPM performs when it comes to execution. This is not to be seen as competitive information or show jBPM is faster or slower than other engines but more for setting a stage and open the door for more performance tests that can be performed in different types of environments.

Overview

The performance test is executed on KIE Server so it actually measures performance of the jBPM as a running service instead of focusing on raw execution of the APIs. So anyone can perform this tests by following the instructions at the end of this article.

Environment

The test has been executed on:
  • community 7.8.0 single zip distribution that you can download on jbpm.org
    • WildFly 11
    • Postgres data base 
  • hardware
    • macOS 10.13.4
    • Processor Intel Core i7 2,3 GHz
    • Memory 16GB
  • JMeter as the test client
All components (client, application server and database) are on the same hardware, meaning they share the resources.

Scenarios

There are three scenarios selected for this test that are executed with various concurrency settings.

Script task

Most basic process definition that runs directly from the beginning till the end without persisting any state in between.
This test consists of just single call to KIE Server.

User task

User task based process that will persist its state when reaching user task activity. Completion of the task is done in another call. 
This test consists of three calls to KIE Server
  • start process
  • get tasks for given process instance
  • complete first task


Parallel script and user tasks

More advanced process definition that combines both user and script tasks with parallel gateways.

This test consists of five calls to KIE Server
  • start process
  • get tasks for given process instance
  • complete first task
  • get tasks for given process instance
  • complete second task

Performance test

Tests are separated per scenario and then number of concurrent threads. The test is designed to run fixed number of process instances (1000) in the shortest possible time.

Script task execution results


Actual figures
  • 1 thread - 11 421 ms
  • 4 threads - 4 428 ms
  • 8 threads - 3 124 ms

Throughput: 
  • 1 thread - 91 instances/s
  • 4 threads - 240 instances/s
  • 8 threads - 361 instances/s

User task execution results



Actual figures
  • 1 thread - 64 439 ms
  • 4 threads - 18 397 ms
  • 8 threads - 13 927 ms

Throughput: 
  • 1 thread - 16 instances/s
  • 4 threads - 52 instances/s
  • 8 threads - 72 instances/s

NOTE: throughput is for complete process instance execution including completion of user task


Parallel script and user tasks execution results



Actual figures
  • 1 thread - 153 543 ms
  • 4 threads - 34 769 ms
  • 8 threads - 20 426 ms

Throughput: 
  • 1 thread - 11 instances/s
  • 4 threads - 45 instances/s
  • 8 threads - 70 instances/s

NOTE: throughput is for complete process instance execution including completion of user tasks

Conclusion

These performance results show the base performance of the jBPM execution through KIE Server - meaning it adds network and marshalling overhead. The application server or hardware has not been tuned in anyway and the sample processes are simple as well. So with that said, it's not meant to provide complete performance report but rather a base line. More advanced performance tests can be performed on dedicated hardware and with tuned application server and database for optimal performance.


Instruction for execution

In case someone would like to try these tests themselves, here are few steps one how to do it.

  1. Download and install jBPM 7.8.0 (or newer)
    1. download 
    2. getting started 
  2. Change data base to PostgreSQL or MySQL - see getting started (bottom of the page)
  3. Import this project into workbench on your running jBPM server
  4. Download and start JMeter
  5. Open this script in JMeter
  6. Run the selected scenario.