This chapter describes how to develop a Java command for PAK.

1. Introduction

This chapter gives an overview of the development of commands in the PAK framework.

2. Glossary

In the following a short glossary is given to clarify the terms used in this chapter.

Term Description


An adapter is a special kind of service that takes care of communication with external applications.


A concrete implementation of a task.
Commands are elements that are later displayed in the Construction Kit as part of the Palette in the editor.


An interpreter is a Java class used by PAK to make a command implementation executable.


A node is the parent-category for all elements that can occur in a workflow, e.g. a task is a specialization of a node.


Services are classes that are instantiated and configured by the end application and whose instances can be used in the commands to perform specific actions.


A task is a command that has already been placed in a workflow.
This means that there can be several tasks with the same command id, which can be distinguished by a different mapping in BPMN.

3. Command Meta Information

The command meta information is stored as JSON file.
It contains all the information relevant for the command so that the engine knows how to execute it.
Usually, a command developer does not need to interact with it because it is automatically generated by the provided tools.

Nevertheless, a developer should be aware of the existence of those files in order to be able to find the cause of errors (e.g. missing datastore keys, wrong data flow analysis, commands not displayed, …​).
Check Command Meta Doc for more details!

4. Java Command

This section describes how to write a command for PAK in Java.

4.1. Requirements

The Java Language Command Interpreter (JLCINT) is provided for command development using Java.

Several dependencies and tasks are required, which will be described in the following.
Additionally, an example implementation of a build.gradle for Gradle and a pom.xml for Apache Maven are given.

4.1.1. Dependencies

The required dependencies are described below.


Lightweight dependency that contains only annotations to define the program flow (including mappings) of a command.
Does not create dependencies to PAK APIs or similar.
Thus, commands remain independent of the PAK engine in the first step.


Annotation processor that automatically generates the command meta information JSON files from the command API annotations during build.
Needs the build information (version, group and name) from the java compiler via -A flags.


Test utilities that do not create a dependency on PAK and can be used to perform module tests on individual commands.

Additionally, you will need a new task (metaJar) to deploy the meta files to the Nexus repository and to define a new Javadoc custom tag, which defines the documentation for a workflow developer.

Command modules need to declare the scope of following dependencies as provided, see Classloader Delegation Concept.
provided de.asap.pak.jlcint:jlcint-commandapi

The Service-api(s) of the used services. For example if you use the Jenkins Adapter you have to provide the api module of the Jenkins Adapter as "provided"
provided de.asap.pak.adapter.jenkins:jenkins-adapter-api

A command could assume the dependencies in Chapter Services to be present, this might be due to changing credentials or something like that.

4.1.2. Gradle

If you want to use Gradle for your command development you can use the following build.gradle as orientation for needed dependencies.

Listing 1. build.gradle
plugins {
    // java - no more to say
    id 'java-library'

ext {
    pakVersion = '1.5.14'

version = '1.0.0-SNAPSHOT'
project.description = 'TestCommand' = 'org.example.commands'

repositories {
    maven {
        name = 'pak-explorer-maven'
        url ''

dependencies {
    annotationProcessor "de.asap.pak.jlcint:jlcint-processor:${pakVersion}"
    implementation "de.asap.pak.jlcint:jlcint-commandapi:${pakVersion}"
    testImplementation "de.asap.pak.jlcint:jlcint-testutils:${pakVersion}"

compileJava {
    //  pass required options to annotation processor#

javadoc {
    source = sourceSets.main.allJava
    options.tags = [
            'workflowDocu:cm:Workflow Developer Documentation:'

task metaJar(type: Jar) {
    archiveClassifier = 'pakmeta'
    from sourceSets.main.output
    include 'meta/**'
    include 'entities/**'
    include 'icon/**'

4.1.3. Apache Maven

If you want to use Apache Maven for your command development you can use the following pom.xml as orientation for needed dependencies.

Listing 2. pom.xml
<project xmlns=""





                            <head>Workflow Developer Documentation:</head>


4.2. Implementation

This chapter will show you how to use annotations to declare a command in Java.

4.2.1. Annotation Quick Reference

To develop a command you must use several annotations.
The available annotations are listed below.
Each list item refers to a documentation of the respective annotation.

4.2.2. Example

The following is a simple example of a command that clones a repository with git.

Listing 3. Command implementation:
import de.asap.pak.jlcint.commandapi.CommandGroup;
import de.asap.pak.jlcint.commandapi.JavaCommand;
import de.asap.pak.jlcint.commandapi.Persistent;
import de.asap.pak.jlcint.commandapi.Run;
import de.asap.pak.jlcint.commandapi.Service;

 * Sample implementation for a simple command that uses a Git service to execute
 * a method on it. The @JavaCommand annotation is necessary for the annotation
 * processor to recognize this class as a command. If this is not set, no meta
 * file will be generated!
 * @workflowDocu Clones a GIT repository to a target directory
@CommandGroup("Git") // described name will be shown as group/cluster in the workflow editor
public class GitClone {
	 * Fields annotated with @Service are automatically resolved by JLCINT via
	 * injection. For tests, a mocked instance could also be handed over. It is also
	 * possible to specify a named service instance (@Named or to set this service
	 * as optional (@Service(optional = true)).
	private IGitService gitService;

	 * @Persistent means that the value is read or saved from the data store.
	 *             Without this specification the value is a mandatory read value.
	 *             The annotation provides many options, which are described in the
	 *             JavaDoc.
	 * @workflowDocu Source repository URI to clone
	private String gitUri;

	 * @workflowDocu target directory, where the repository should be cloned to
	private String targetFolder;

	 * Methods that are annotated with @Run are executed when the task is called.
	 * Any number of exceptions can be thrown, these can then be handled by an
	 * exception handler during runtime (see exception handling concept).
	public void doClone() throws IOException, GitServiceException {
		this.gitService.cloneRepository(this.gitUri, target);

4.2.3. Don’ts

Don’t name @Run Method like getter

Make sure that the method under ‚@Run‘ is not named like a possible getter for one of the fields.
Otherwise, hard interpreter errors will occur.

Listing 4. Do not follow this
public class FetchFile {


	private String fileName;

	public void getFileName() {

In the example above the getter of the field fileName would be getFileName which is also the name of the method annotated with @Run.

4.2.4. Best Practices

Deprecation over Removal

Instead of removing or renaming an old command use the @Deprecated annotation instead.
This ensures that old workflows will still work after an update of the available commands.

Listing 5. Deprecation over Removal
 * @workflowDocu Creates a new test run from test cases.
 * @deprecated CreateNewTestRunFromTestCases is the follow-up version of this
 *             command.
 *             Use that instead!
@Deprecated(since = "adapter version 1.1.0")
public class CreateNewTestRun {

4.3. Conversion

The interpreter handles the conversion of data types between the datastore and the command.
This enables a smooth usage of the interacting commands.

4.3.1. Possible Conversions

  • String ⇐⇒ Number

  • Number ⇐⇒ Number (Integer ⇐⇒ Double)

  • String that represents a number ⇐⇒ Number

  • String ⇐⇒ Boolean

  • Primitive ⇐⇒ Boxed

  • Object implements Interface ⇒ Interface

  • Object extends SuperObject ⇒ SuperObject

  • Object ⇒ Everything that Object is castable to

  • Object ⇒ String (via toString())

  • String ⇒ File

4.3.2. Impossible Conversions

Not convertible are

  • numbers that exceed the limit for another type of number

  • objects not extending/implementing the same super class.

4.3.3. Example

For example, a command saves a time value as double and another command requests the time value from the datastore as integer.
This conversion is only possible when the object saved in the datastore is convertible to another class.

Figure 1. Conversion Examples

4.4. Testing

To test a command the jlcint-testutils package offers a JUnit 5 (Jupiter) extension which takes care of resolving datastore values and services.

A possible simple implementation of a test for the command of Listing 3 looks like this.

Listing 6. Example test class for command of
import de.asap.pak.jlcint.commandapi.Persistent;
import de.asap.pak.jlcint.commandapi.Service;
import de.asap.pak.jlcint.testutils.JlcintExtension;
import org.junit.Test;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.extension.ExtendWith;


import static org.junit.jupiter.api.AssertTrue.assertTrue;

/** The @ExtendWith is required to load the Jlcint test extensions */
public class GitCloneTest {
	 * We want to set the gitUri variable directly here in the test class, the value
	 * stored here will then be injected in the command
	private String gitUri;

	/** the same happens with targetFolder and the git service */
	private String targetFolder;

	private IGitService gitService;

	 * The provider class is provided by the test utils and then inserted here by
	 * the extension. This one then takes care oft the mapping and the command
	 * instantiation.
	private Provider<GitClone> command;

	public void prepare() throws IOException {
		// Here we use a specific service instance. Equally possible would be a mock.
		this.gitService = new GitService();
		this.targetFolder = Files.createTempDirectory(this.getClass().getSimpleName()).toString();
		this.gitUri = "... some-repo-at-github ...";

	// TODO: Delete the created temporary directory in @AfterEach

	public void testRun() throws Exception {
		// The command can be executed directly and then the result can be validated.
		// Write mappings are also written back to the test class if return values are
		// to be validated.
		// Of course, the provider implementation also allows extensive access to the
		// instance, for example to execute
		// only the PostConstruct method or similar actions.

		// we only look here that the README.MD file was created from our test repo
		assertTrue(new File(this.targetFolder + "/README.MD").exists());

Sonatype Nexus

PAK features connectors and commands for Sonatype Nexus. This means the software can directly interact with Nexus repositories for storing and managing artifacts. Through these connectors, PAK can automate tasks like uploading binaries or retrieving dependencies, ensuring efficient artifact management within Nexus.


PAK has connectors and commands for Jenkins. This allows the software to directly communicate with Jenkins servers, enabling the automation of CI/CD (Continuous Integration/Continuous Deployment) tasks. Through these connectors, PAK can trigger builds, fetch build statuses, or manage job configurations, streamlining the CI/CD processes within Jenkins.

Git Hub

PAK possesses connectors and commands for GitHub. This means the software can interface directly with GitHub repositories, facilitating actions like code pushes, pull requests, or issue tracking. Through these connectors, PAK can automate various GitHub operations, enhancing code collaboration and repository management.

Atlassian Confluence

PAK is equipped with connectors and commands for Atlassian Confluence. This enables the software to directly interact with Confluence spaces and pages. Through these connectors, PAK can automate actions such as creating, updating, or retrieving documentation, ensuring efficient content management and collaboration within Confluence.


PAK features connectors and commands for Codebeamer. This allows the software to seamlessly integrate with Codebeamer’s ALM (Application Lifecycle Management) platform. Through these connectors, PAK can automate tasks like issue tracking, test management, or requirements tracing, enhancing the coordination and management of software development processes.

JFrog Artifactory

PAK has connectors and commands for JFrog Artifactory. This means the software can directly interface with Artifactory repositories, enabling actions like artifact storage, retrieval, and management. Through these connectors, PAK can automate tasks such as deploying artifacts or managing repository configurations, streamlining the integration and management of binary artifacts within Artifactory.

Amazon Web Services (AWS)

PAK has connectors and commands for Amazon Web Services (AWS). This means the software possesses specialized interfaces to directly interact with AWS services and execute actions on the AWS platform. Through these connectors, PAK can automate AWS-specific commands, such as launching EC2 instances, managing S3 buckets, or configuring Lambda functions. This allows for efficient integration, management, and automation of AWS resources and services directly from PAK.

Atlassian Jira

PAK features integration tools and capabilities for Atlassian Jira. These tools allow for a direct connection to Jira and the execution of specific actions. Using these integration tools, PAK can automate Jira actions such as adding comments or changing ticket priorities, ensuring seamless handling and coordination of Jira processes.


PAK has connectors and commands for Git. This means it has interfaces to directly communicate with Git and execute actions. Through these connectors, the software can automate Git commands such as retrieving changes or creating branches, enabling efficient integration and management of Git tasks.

Generic Human Tasks

PAK offers you a standard set of commands which require creative input from the user. Enables you to start with automating your workflows, that still need abit of human input.

Generic Commands

PAK offers a standard set of commands giving you the first steps to automate your workflows.

Nexus Maven Command Pool

Nexus is an artifact repository manager for storing binaries, libraries, and artifacts, supporting formats like Maven. Maven, a software project management tool, is based on the Project Object Model (POM) and allows developers to consistently define projects and dependencies. Our Command Pool offers commands for interactions between Maven and Nexus, such as artifact uploads or dependency retrieval.

Artifactory Maven Command Pool

Artifactory allows developers to store, retrieve, and manage binary files and artifacts, providing a
central source for all binaries used in a development process. Apache Maven is a software project
management and comprehension tool that enables developers to consistently describe a project and
its dependencies. Our Command Pool offers a collection of commands used to facilitate interactions
between Maven and Artifactory, such as uploading artifacts or retrieving dependencies.

Open API Command Interpreter

The OpenApi Command Interpreter allows you the automatic parsing of commands from an OpenApi defintion. No additional code needs to be written anymore, just add the address to the definition and our framework does the rest!

Kotlin Command Interpreter

The Kotlin Command Interpreter allows you the parsing and execution of commands within a Kotlin environment to automate various tasks or processes.

Bpmn Interpreter

Workflows come in many shapes and forms. The BPMN (Business Process Model and Notation) Interpreter enables the parsing of worklows defined in the BPMN format into the PAK intern model.

Human Task Interpreter

The Human Task Interpreter allows you the parsing and running of commands within a HTML and Javascript environment. Use this to build commands which need the creative input of a workflow user!

Java Command Interpreter

The Java Command Interpreter allows you the parsing and execution of commands within a Java
environment to automate various tasks or processes.


The heart of the PAK-Framework. Contains the means to run workflows with the PAK engine, but also the possibility to enrich the frameworks interfaces with your own implementations and solutions.

RocksDB Persistence

Data that is generated by a workflow run needs to be saved for short or longer terms. Our solution to the Persistence Interface of the PAK-Framework is to use the high-performance, key-value based RocksDB developed by Facebook.

PAK online

PAK Online is a web based application and provides an Open API based REST API. It enables you to upload workflows and run them periodically or on REST demand.

Command Line App

Run tasks and workflows on the console or as part of a CI/CD Pipeline with our Command Line Interface.

Workflow Editor

With our specially developed editor, a wide variety of workflows can be easily modeled in the wide known BPMN process format.

Workflow Executor

The Workflow Executor is the application to run your workflows. It features a multilingual UI and easy managment of your favorite workflows.


We offer a community website where you can exchange ideas and support each other. For our Pro packages we also offer full support via email.