viadee Process Application Validator

Process applications basically consist of process model(s) and Java code which both exist side by side and are edited in different tools. For the process models you will most likely use the Camunda Modeler, for the Java code the IDE of your choice. However, no one checks whether model and code are aligned beforehand, e.g. if a bean referenced in a delegate expression actually exists in the code. With the viadee Process Application Validator (vPAV, Open-Source), you can validate your process application regarding these inconsistencies with a simple JUnit test. You can also ensure that specific best-practices are met (e.g. naming conventions).

If you feel addressed by now, we might give it a try. It is as easy as adding a maven dependency (see below). Integrated in your CD/CI pipeline you’ll be able to find inconsistencies in the early stages.

Features/Checkers

Get Started

In order to provide ease of use, the viadeeProcessApplicationValidator can be integrated as a Maven dependency and executed as JUnit test. For demonstration purposes we forked the Camunda BPM examples to demonstrate the easy integration of vPAV.

Maven

You can start the validation by adding the dependency to your local projects POM.xml.

<dependency>
  <groupId>de.viadee</groupId>
  <artifactId>viadeeProcessApplicationValidator</artifactId>
  <version>...</version>
  <scope>test</scope>
</dependency>

JUnit

We recommend to configure a JUnit-4 test and start the validation by calling the ModelConsistencyTest.

import de.viadee.bpm.vPAV.ProcessApplicationValidator;
...
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = { SpringTestConfig.class })
public class ModelConsistencyTest{

    @Autowired
    private ApplicationContext ctx;   

    @Test
    public void validateModel() {
        assertTrue("Model inconsistency found. Please check target folder for validation output",
                ProcessApplicationValidator.findModelErrors(ctx).isEmpty());
    }
}

Note, that the Validator receives the Spring context. Thereby, the validation can
check referenced beans and their names.

Configuration

The viadeeProcessApplicationValidator provides a file called ruleSetDefault.xml, which is a basic configuration. By creating and storing a ruleSet.xml in your local project, you are able to use your very own set of rules. This allows you to de-/activate certain checkers or specify naming conventions, etc.

One set of rules to rule them all

If you want to manage more than one project at a time, it might be of use to have a parent set of rules. All projects inheriting from your parent project will use the same set of rules. But beware, local rules will override and therefore allow maximum customization.

Exclusion of false positives

With the creation of a file called .ignoreIssues you can whitelist known issues by listing their respective IDs, so they don’t break your build.

Example

# Comment 
8d04f2e77a7d282c521098ab947ac060

Output

The result of the check is first of all a direct one: if at least one inconsistency is found on the ERROR level, it will break your build or count as a failed unit test which will break your build too.

Further, the consistency check will provide an XML version, a JSON version and a visual version based on BPMN.io (see above) for all errors and warnings that have been found.

Visual Output

With the visual output you will be able to identify errors and warnings at a glance. Highlighting all elements that contain at least a warning and providing a comprehensive list that will let you find and eradicate errors in less than no time and get your build back up and running.

Contributing to the community version of the viadeeProcessApplicationValidator

The viadeeProcessApplicationValidator has been developed as open-source software by employees of the viadee Unternehmensberatung GmbH, a German IT consulting company located in Cologne and Münster, who support their customers in Camunda and software development projects.

If you want to extend our software, check out our Git repository and feel free to contribute your own ideas.
For further questions, remarks or feedback do not hesitate to contact us:

Benedikt Uckat

Claus-Alexander Usener