Configuring Workflow Services

This document describes how to configure a Workflow service with the SonataFlow Operator.

Editing the Workflow Configuration

When the operator deploys the Workflow service, it also creates a ConfigMap named after the SonataFlow object with the suffix -props. For example, if your Workflow name is greeting, then the ConfigMap name is greeting-props.

You can use the Kubernetes object editor of your preference to add or edit the properties in the Workflow configuration. Using kubectl you can do:

Editing the Workflow Properties

kubectl edit cm <workflow-name>-props

Note that it’s important to respect the properties format, otherwise the operator will replace your configuration with the default one.

Here’s an example of a Workflow properties stored within a ConfigMap:

Example of a Workflow ConfigMap Properties

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    app: greeting
  name: greeting-props
  namespace: default
data:
  application.properties: |
    my.properties.key = any-value

The underlying runtime engine that executes the Workflow service is based on Quarkus. The application.properties key in the ConfigMap means that you can configure the Workflow as you would any Quarkus application.

Any SonataFlow configuration that the documentation describes or general Quarkus application property can be configured using this method.

Immutable properties

A few properties cannot be changed in this configuration. Usually, they are already defined in the properties file. The table below lists them.

Table 1. List of immutable properties
Property Key	Immutable Value	Profile
quarkus.http.port	8080	all
quarkus.http.host	0.0.0.0	all
org.kie.kogito.addons.knative.eventing.health-enabled	false	dev

If you try to change any of them, the operator will override them with the default, but preserving your changes in other property keys.

Additional resources

Found an issue?

If you find an issue or any misleading information, please feel free to report it here. We really appreciate it!