domingo, 22 de abril de 2018

Using jBPM embedded and CDI in a JavaFX application

A few years ago I wrote about using jBPM remote API from JavaFX. That was straightforward because the remote APIs are usually simply wrappers to REST APIs running on server side.
Since then a few things happened:

  • jBPM is in version 7.7, that article was for jBPM 6.3.0!
  • In version 7 the Business Central execution server was replaced by Kie Server (we even wrote a JavaFX client for Kie Server)
  • A new jBPM services API was introduced and it is mature and ready for production use.
  • CDI 2.0 was released and it allows the use of CDI in standalone Java applications ( and in a JavaFX application as we described).

We could use jbpm embedded at that time, but we would have to make use of underlying Kie APIs (RuntimeManager, KieSession, etc), which I was not willing to use at that time. With services API we can easily bring jbpm to every Java application, just just one of its flavors: CDI, EJB, Spring or pure Java.

But what is different from using embedded jbpm from Kie Server? Basically the engine will run inside the Java client application, which means that it will not rely on a central server to execute the business processes:

There might be the case where you don't want to maintain a central server and put the execution on the client. It is hard to defend such model in Cloud Computing days. create docker image and orchestrate it on Openshift. And I agree with it, 96.9% (made up statistic) of the cases will be better handled by this model. However, with an embedded client the jbpm engine execution will happen on the client, which means that we will remove the server for processes execution and we will optionally share a database between the clients:

In this model you may have a shared database or a shared maven repository. The jBPM API is very flexible, you can run it without a database and loading process definitions from the file system. The use cases for it may be:
  • Small business: they may not want to maintain a server or contract a cloud service, but they know the advantages of using jBPM to model their processes;
  • IoT: you may want to have local processes execution in IoT devices and avoid a single point of access;
  • Apartment complex: control garage, residents, apartment occupancy, visitants flow and other aspects of an apartment complex  may be done using BPM tools.
In any case, I managed to run jBPM on a JavaFX application with CDI and I would like to share it with you. The source is already on my github and it uses the same view from the Rewards Client we used with the Business Central remote API. This is what you need to know:
  • We use CDI, which means that after configuring jBPM (see package ) we can simply inject jBPM service in our application (ProcessService, UserTaskService, RuntimeDataService and more);
  • You have two datasource: in memory H2 or MySQL, by default it will connect to MySQL, see the class DatasourceSetup for more information;
  • It is JavaFX and Java 8. in Java 11 JavaFX will be removed from the JDK and you may use OpenJFX and OpenJDK in your commercial application, get JavaFX support from Gluon (if you want) and jBPM embedded support from Red Hat (if you want). If you don't want it, you should (hopefully) be free to build your commercial application based on these APIs.
The application structure show us that we need a few classes to configure jBPM (see conf directory). The API usage happens on RewardsServiceEmbeddedCDI.

That is all I wanted to share. Usually BPM users are big company, but embedded jBPM is a flexible and lightweight alternative for those who don't want to use a central server for processes execution. Of course the same API can be used in a Web application, but we will talk about it in future posts.

Nenhum comentário:

Postar um comentário