Skip to main content
Version: 1.3.2

Controller configuration

The jadice flow controller is a spring boot application and can run in a cloud environment or on a local machine. It is the main component controlling jobs and managing the workflows.

Kubernetes / Cloud environment is configured via the helm chart. In the standalone distribution, the configuration files reside in the corresponding /config-directories.

application.yaml

The application.yaml is the main configuration file. It contains all configuration aspects of the spring boot application itself (e.g. port, keycloak-enabled, metrics configuration).

JobTemplates are stored in a separate file called jobTemplates.yaml. This allows the controller to persist only the JobTemplates, when the configuration has changed (e.g. via the UI). The jobTemplates.yaml is imported into the application.yaml via an import statement. It is possible to omit the jobTemplates.yaml and directly place the JobTemplates in the main configuration file, but this is not recommended.

When executing a JobTemplate, this is done in a Job. Each step of the JobTemplate might call an external jadice flow worker.

The possible workers are configured in the workers.yaml file. It is imported into the main configuration file like the jobTemplates.yaml. The controller will not persist / change the worker configuration though; only job templates can be configured dynamically (e.g. via UI).

Database

In a standalone distribution, the jdbc source is configured in the application.yaml file of the controller directly:

spring:
datasource:
url: jdbc:mariadb://localhost:3306/jadice_flow?createDatabaseIfNotExist=true
username: jf_db_user
password: password
hikari:
schema: JADICE_FLOW
maximum-pool-size: 50

Jadice flow main configuration

Main configuration:

# Jadice flow main config
jadice-flow:
server-url: http://localhost:8080/
securityToken: _token_
# System config / Scaling
system:
lockJobConfiguration: false
configFileJobs: ${user.dir}/config/jobtemplates.yaml
maximumConcurrentJobCount: 4
maximumConcurrentWorkerInvocationsDefault: 1
#maximumConcurrentWorkerInvocationsSpecific:
# org.jadice.flow.batch.processor.impl.SingleToTiffProcessor: 3
autoJobDeletionEnabled: true
autoJobDeletionThresholdDays: 30
autoJobDeletionCheckHour: 12
event-bus:
enabled: true

Most noteworthy configuration parameters:

  • jadice-flow.system.lockJobConfiguration: Allows to lock the system configuration so it cannot be changed via Rest / UI
  • jadice-flow.system.configFileJobs: The available JobTemplates are imported into the application.yaml from the jobtemplates.yaml by default.
  • jadice-flow.system.maximumConcurrentJobCount: Defines how many jobs may run in parallel

License

To use the flow controller, a license is needed. The license which is provided is added to the file as a separate block:

jadice:
license-configuration:
license: |
----BEGIN LICENSE----
Ic5OXgAAACQAAAACAAAACAAAABBjdXN0b21lcnsibmFtZSI6IlRSSUFMIn0AAAAa
....
c2lnbmF0dXJlRGlnZXN0U0hBLTUxMg==
----END LICENSE----
fingerprint: 6149d57c-...
public-key: |
-----BEGIN PUBLIC KEY-----
MIICITANBgkqhkiG9w0BAQEFAAOCAg4AMIICCQKCAgANW2cb2XJxgnysASNpfQfL
...
iLjj/Yso3fK+SkDr0ZVMqQIDAQAB
-----END PUBLIC KEY-----

jobTemplates.yaml

As mentioned before, the jobTemplates.yaml contains the workflow definitions.

Note: The amount of active job templates might be restricted by the license. If more job templates are available than the license permits, some templates have to be disabled.

Example content:

---
jadice-flow.jobs:
jobTemplates:
- jobName: "Local-Sleep"
description: "A local test template which sleeps for each item."
properties: {}
enabled: true
stepTemplates:
- stepName: "Sleep"
workerDefinitionName: "Sleep"
inputMimeTypes: []
expectsNewPartResult: false
markSrcAsMetaOnResult: false
parameters: []
jobFlow:
- from: ""
"on": "*"
to: "Sleep"

This file should only be edited manually by advanced users. To configure JobTemplates, users should generally use the UI / Rest endpoints.

workers.yaml

The workers.yaml contains the worker definitions of possible callable workers.

Example:

---
jadice-flow.workers:
workerDefinitions:
- workerName: "uuid"
description: "Creates a uuid in the property NEW_UUID"
processorClass: "com.jadice.flow.controller.server.processor.RemotePartProcessor"
workerURL: "https://jf-worker.net/"
infoTags:
- "PART_BASED"
- "REMOTE"
workerParameters: []

Usually, jadice flow will come with a pre-configured workers.yaml with the relevant workers already entered for the customer.

Main parameter is the workerURL, the other settings define how the controller shall interact with the worker (the processor class) and which description to use. Those values usually do not need to be changed by the customer.

There might be the need to customize the worker-URLs to fit the current environment.