segunda-feira, 23 de novembro de 2015

Quickpost: Using jBPM remote API from a JavaFX Application

Recently I wrote an article for Master the Boss to show the use of the jBPM/BPM Suite remote API. To test that, I also created a simple JavaFX application to remember the good old days when I used to create JavaFX apps daily :)

 The app I created was actually really simple, here are some screenshots:

The simply app allow an user do the steps of a business process using the remote API which are start a process, manage human task, read process variables and the process execution history. This the the process we are talking about:

Below you can see a video of the app in action interacting with jBPM deployed process and tasks. Notice it is possible to see the status of the business process in real time.

It was created in less than one hour and all the JavaFX code is below and the entire project is in github.

domingo, 15 de novembro de 2015

Wildfly 10 Javascript Hello World in 2 minutes

We already talked about Nashorn, JavaFX and Javascript in this blog, but today I was surprised by the announcement that Widlfly 10 supports Javascript in the server side. I should have seen before, but only after a few months it was released I saw it on twitter!

After seeing the announcements samples, I thought I had to try it and surprisingly it took less than a few minutes to have my first script running. Here are the steps I had to follow:

(I am considering you already have Java 8 installed)

  • * Download Widlfly 10: I downloaded Widlfly 10.0.0.CR4 Application Server Distribution. See more in widlfly downloads page;
$ wget

  • Unzip it somewhere locally: 
$ unzip

  • Start it "quietly":
$ cd wildfly-10.0.0.CR4
& ./bin/ > /dev/null &

  • Create the application structure in the deployments directory
$ mkdir -p standalone/deployments/app.war/WEB-INF

  • Create the only descriptor needed in your application and declare the Javascript file on it (hello.js):
$ cat standalone/deployments/app.war/WEB-INF/undertow-scripts.conf 

  • Create the javascript file itself in the application root directory:
$ cat standalone/deployments/app.war/hello.js 
$undertow.onGet("/say-hello", function($exchange) {
return "Hello World!";

As you can see above, when you send a HTTP request using the GET method to the URL {host}/{app context}/say-hello it should return "Hello World!". We just have to provide the context and the function that will handle the requests.
  • Deploy the application itself:
$ touch standalone/deployments/app.war.dodeploy

  • Check if it was correctly deployed by checking the logs:
$ tail  -n 3 standalone/log/server.log 
2015-11-15 21:47:09,649 INFO  [] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "app.war" (runtime-name: "app.war")
2015-11-15 21:47:11,600 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 63) WFLYUT0021: Registered web context: /app
2015-11-15 21:47:11,654 INFO  [] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "app.war" (runtime-name : "app.war")

  • Finally test the application using a web browser or curl:
$ curl http://localhost:8080/app/say-hello
Hello World!

Well, that's just the beginning. You can now using Java EE services in your javascript annotation as it is described in the release announcement

I guess you still did not notice the best part: you don't need to recompile your application anymore, you can simply edit the javascript and touch the app.war.dodeploy file and the changes will be immediately available (after, of course, a redeploy). Stuart Douglas pointed that you can configure hot deployment and no redeploy is needed. The hot deployment configuration is described in the announcement as well and to configure it I simply created the file undertow-external-mounts.conf with the directory where my javascripts are located:

$ echo /opt/jboss/WILDFLY/wildfly-10.0.0.CR4/standalone/deployments/app.war/  > standalone/deployments/app.war/WEB-INF/undertow-external-mounts.conf

Now if I edit any javascript file in the pointed directory I will see the changes immediately once I reach the endpoint.

If you still do not believe it is really simple, I have created a video for you!

domingo, 26 de julho de 2015

A Parser work item handler for jbpm 6

One usual task we do in a process is to have to parse XML/JSON to objects and vice versa. I always look at sample work item handlers from jbpm and I want to create my own work item handlers because it is fun. Today I will quickly show the first public useful work item handler I have created: The parser.

What is and how to use it?

It is a simple parser task that you can use in your BPM Suite/ jbpm 6 process to parse from XML/JSON to some Java object and vice versa. You can, for example, read XML from a file and convert to your model object. It can be used with the REST Task for previous jbpm version, since recently support to transform was added to the REST Task

It accepts the following parameters:

Input: The input data. If you provide a string, the parser will try to parse the string to an object of type Type and format Format (see below), if not, it will try to parse the object to a String of format Format. It is a required parameter;
Format: It is a required parameter that can have the values JSON or XML;
Result: The result is an output parameter that will be a string if you provide an Input object that is not of String type; and an object of type Type if you provide  an Input object of type String.

Providing these parameters correctly is enough to use the parser task. Please bear in mind that it uses JAXB to parse the object, so it must have the @XmlRootElement annotation.


The steps to install it are similar to the steps we used to install the hello world work item handler. But since we are on BPM Suite 6.1, it will be slight different, see:

* Clone the source code from my github and run mvn clean install to have it in your maven repository (actually in the maven repository used by BPM Suite); Or download the JAR containing this work item handler and upload it as an artifact to your installation;

* Add the GAV information of the WIH(Group: org.jbpm.process.workitem; Artifact ID: parser-task; version: 1.0) as a dependency of your project:

* Now edit the new deployment descriptor to include a declaration of this WIH class. Notice I am sending the Classloader as a parameter. It is needed to load classes defintion to be parsed:

* Finally edit the wid file to include the declaration of the WIH. Now you can open the process and drag it to use in your process.

If you want to see more details about this WIH, please see  the project in github and also the tests for it.


It is easy to extend the jbpm 6 library to include your own custom tasks. The parser task was approved for the Service Repository in BPM Suite! See jbpm github!

sábado, 4 de abril de 2015

Creating custom Work Item Handler in BPM Suite/jBPM 6

Hi all! In this post I am going to share my experience creating a work item handler for BPM Suite 6.0.3 (which is very similar to jbpm as explained in a previous post).

The Hello World Work Item Handler

Let's create a really simple WorkItemHandler just to print "Hello World" in the console. Of course you can implement more feature and make it receive parameters, access database, web services, etc. But in this post we will keep it simple. Really simple.

First thing to do is to create a maven project for my WorkItemHandler. Here's the pom.xml of my Maven project:

Notice that we are importing jbpm dependency so we can find the java interface that is used to create work item handlers.

Now we can start coding. Let's create a class name HelloWorkItemHandler in package org.jugvale.jbpm, here is the simple code:

Now we can build our project and go to BPM Suite to configure it so we can use this workitem.

Registering the WorkItemHandler

The first thing to do is to make our artifact visible to BPM Suite. We can either import it in the maven used by BPM Suite or we can upload the JAR using the web application. In any case, the common step is to build our project.

After building it, decide if you want to install it in your maven repository so you can use it in the BPM Suite project as a dependency or you can upload the JAR to BPM Suite and make it a dependency of the BPM Suite project. That's what we are going to do.
  • So, after starting BPM Suite, and logging into business central, we can go to Authoring -> Artifact Repository  and upload the JAR with our Work Item Handler:

Now we create a simple project in BPM Suite. You can do this by going to Authoring -> Project Authoring and then New Item -> Project. Notice that I am considering that you have already a repository created.

Now that you have your project created, let's add the artifact we uploaded as a dependency of it. To do this, select the project and go to Tools -> Project Editor and on the Project Settings drop down menu, select Dependencies. Now you can specify the uploaded artifact as a dependency of your project using the Add from repository button and choose our artifact from the list that will show up and then we are done with this part. Don't forget the save the changes.

Remember that WorkItemHandlers are registered in the file META-INF/kmodule.xml of your project. However, we can do this visually! Go to Project Editor  and from the Project Settings dropdown button, choose Knowledge base and sessions. Add a new knowledge base, make it default and add a new ksession, make it default, edit it and add the work item handler. Here are some useful screenshots:

 Adding the kbase and the ksession:

Editing the ksession to add the work item handler:

Save it and now the project is already configured with a kbase and a ksession with our work item handler! See how our kmodule.xml looks like:

We are almost done.  Let's create a process to test the WorkItemHandler we created, use the menu New Item -> Business Process and do nothing for now, just close the process editor.Now let's simple edit the file WorkDefinitions.wid of our project to include metadata about the WorkItemHandler. Here we can set the icon and the name that will appears in the process editor. We simple only set a display name:

   "name" : "HelloWorkItemHandler",
    "displayName" : "Hello World!",
    "icon" : "defaultemailicon.gif"

Save the file, create a new process and MAGIC! Now you can use your custom work item handler and it will be appear in the process editor library under the Service Tasks pane. See my sample process:

If you build, deploy the project and run the process above, you see the "Hello World!" message in the logs:

00:25:16,904 INFO  [stdout] (http-localhost.localdomain/ Hello World!

That's our Hello World Work Item Handler! Of course you can also declare parameters for the Work Item and do more complex operations, such as access a Web Service, send email, send SMS, update a database....

Download the sources on github