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:
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:
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.
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.
Found an issue?
If you find an issue or any misleading information, please feel free to report it here. We really appreciate it!