Blog Posts BPMN DMN

Complex KIE server tests automation part 2: Deadline notifications after KIE server restart

Blog: Drools & jBPM Blog

“Deadlines keep you on track for success” (Timothy Dalton)

Motivation: shouldn’t we automate resilience testing as well?

This article follows the series of easing test automation in complex KIE server setups. In this ocasion, we will cover how to test deadline notifications after KIE server restart.

With human task deadlines, you can set a time limit for that task, when not started or completed. Therefore, the KIE server will send a notification (by default, an automated email) to the target people defined for that task as managers, administrators, other team members.

Here, we will focus on resilience testing. If the KIE server crashes, as there is a mechanism to persist the timer in a database, the KIE server will recover it after restarting. Consequently, the failover mechanism allows sending the deadline notification (triggered before crashing) at the right timing.

The following figure depicts this scenario:

This flow involves multiple system testing components: KIE Server, database, and SMTP server for mailing. We might be tempted to do a one-time setup instead of creating an automated test for our CI/CD pipelines.

But, in the spirit of Martin Fowler’s soundbite “if it hurts, do it more often” (reduces pain drastically), we will follow the automated approach. This way we will exercise the failover scenario regularly, taking advantage of containers. 

First of all, we have to select our tools wisely, as the SMTP server.

One SMTP Server to track them all

The purpose of notification testing is to ensure that:

So, we need a containerized SMTP server with the following requirements:

In our case, we have chosen “Mailhog”, an open-source SMTP server, as it fulfills these expectations and also has a docker image published in docker hub.

We use the following REST APIs in our automation. Respectively, they retrieve all the messages from the inbox and delete all the messages after each test:

Notice that they belong to different versions of the API (there is no DELETE operation at v2). Therefore, two different basePaths (/api/v2, /api/v1) will be set up for each endpoint in the REST-assured RequestSpecification.

Fitting containers together

Once we have defined our testing approach with self-unit independent pieces (containers) and the testing frameworks (Junit5 with REST-assured and testcontainers), it is time to write our tests that will be the glue for fitting all the components together. 

Our system-under-test -the main component- is the KIE Server. From version 7.61.0.Final, we can download it from the Red Hay Quay repository.

From a Multistage Dockerfile, a temporary image on-the-fly will be created containing the business application (kjar) for exercising test scenarios. Therefore:

The mailhog container is a testcontainers GenericContainer (that internally pulls the latest image from docker hub). It is exposing their SMTP and HTTP ports. Notice that it shares the same network as the rest of the containers: communication can occur among them without the need of exposing ports through the host.

public static GenericContainer<?> mailhog = new GenericContainer<>("mailhog/mailhog:latest")
        .withExposedPorts(PORT_SMTP, PORT_HTTP)
        .withLogConsumer(new Slf4jLogConsumer(logger))

Finally, the PostgreSQL container is one of the out-of-the-box testcontainers database modules. We will use the initialization script under /docker-entrypoint-initdb.d containing postgresql-jbpm-schema.sql as explained here.

Maven build-tool pulls the schema from GitHub sources, from the same branch as the system-under-test. It is automatically downloaded using the download-maven-plugin at generate-sources phase, as it is shown in this snippet taken from the pom.xml:


Testing deadline notifications after KIE server restart

This scenario (deadline notifications after KIE server restart) in former releases of KIE Server contained a bug tracked by jbpm#9920:  duplicated emails were received in the target inboxes.

The root cause was that the initialization of the human task service occurred before the deployment (upon server restart). Therefore, the timer service was not available at the moment of starting deadlines, provoking the problem of double notification.

Let’s try to verify that, after fixing, it is working properly.

First of all, we need a kjar containing a simple process with a human task with this deadline configuration:

We can easily stop the KIE Server container after deploying the kjar and start it again to simulate a crash with a reboot. 

And then, after deadlines timeout, we will check the expected outcome by means of REST-assured utils. We can connect to Mailhog to assure that the received emails match the expected ones:

     .body("total", equalTo(3))
     .assertThat().body("items[0].Content.Headers.To", hasItem(""))
     .assertThat().body("items[0].Content.Headers.From", hasItem(""))
     .assertThat().body("items[0].Content.Headers.Subject", hasItem("foo"))
     .assertThat().body("items[0].Content.Body", is("bar"));

We also have another test for checking the case when a different kjar is deployed after the KIE server restart, then, no notification is sent because the kjar that triggered the deadline is not deployed again.

Finally, you can find the code and configuration for this example here.

Conclusion: automated tests for deadline notifications after KIE server restart

Automated Tests are also a good option to make resilience and integration testing less painful.

We can combine different dockerized components (from the system-under-test -KIE server- to external databases -PostgreSQL- or SMTP servers -Mailhog-) into JUnit tests. As we control the containers’ lifecycle, it is easy to stop/start them to check failover mechanisms.

The post Complex KIE server tests automation part 2: Deadline notifications after KIE server restart appeared first on KIE Community.

Leave a Comment

Get the BPI Web Feed

Using the HTML code below, you can display this Business Process Incubator page content with the current filter and sorting inside your web site for FREE.

Copy/Paste this code in your website html code:

<iframe src="" frameborder="0" scrolling="auto" width="100%" height="700">

Customizing your BPI Web Feed

You can click on the Get the BPI Web Feed link on any of our page to create the best possible feed for your site. Here are a few tips to customize your BPI Web Feed.

Customizing the Content Filter
On any page, you can add filter criteria using the MORE FILTERS interface:

Customizing the Content Filter

Customizing the Content Sorting
Clicking on the sorting options will also change the way your BPI Web Feed will be ordered on your site:

Get the BPI Web Feed

Some integration examples