Chapter 6. Configuring workflow services


This section describes how to configure a workflow service by using the OpenShift Serverless Logic Operator. The section outlines key concepts and configuration options that you can reference for customizing your workflow service according to your environment and use case. You can edit workflow configurations, manage specific properties, and define global managed properties to ensure consistent and efficient execution of your workflows.

6.1. Modifying workflow configuration

The OpenShift Serverless Logic Operator decides the workflow configuration based on two ConfigMaps for each workflow: a workflow for user-defined properties and a workflow for Operator managed-properties:

  • User-defined properties: if your workflow requires particular configurations, ensure that you create a ConfigMap named <workflow-name>-props that includes all the configurations before workflow deployment. For example, if your workflow name is greeting, the ConfigMap name is greeting-managed-props. If such ConfigMap does not exists, the Operator creates the workflow to have empty or default content.
  • Managed properties: automatically generated by the Operator and stored in a ConfigMap named <workflow-name>-managed-props. These properties are typically related to configurations for the workflow. The properties connect to supporting services, the eventing system, and so on.
Note

Managed properties always override user-defined properties with the same key. These managed properties are read-only and reset by the Operator during each reconciliation cycle.

Prerequisites

  • You have OpenShift Serverless Logic Operator installed on your cluster.
  • You have created your OpenShift Serverless Logic project.
  • You have access to a OpenShift Serverless Logic project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
  • You have installed the OpenShift CLI (oc).
  • You have previously created the workflow user-defined properties ConfigMap, or the Operator has created it.

Procedure

  1. Open your terminal and access the OpenShift Serverless Logic project. Ensure that you are working within the correct project, namespace, where your workflow service is deployed.

    $ oc project <your-project-name>
    Copy to Clipboard Toggle word wrap
  2. Identify the name of the workflow you want to configure.

    For example, if your workflow is named greeting, the user-defined properties are stored in a ConfigMap named greeting-props.

  3. Edit the workflow ConfigMap by executing the following example command:

    $ oc edit configmap greeting-props
    Copy to Clipboard Toggle word wrap

    Replace greeting with the actual name of your workflow.

  4. Modify the application.properties section.

    Locate the data section and update the application.properties field with your desired configuration.

    Example of ConfigMap

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

  5. After updating the properties, save the file and exit the editor. The updated configuration will be applied automatically.
Note

The workflow runtime is based on Quarkus, so all the keys under application.properties must follow Quarkus property syntax. If the format is invalid, the OpenShift Serverless Logic Operator might overwrite your changes with default values during the next reconciliation cycle.

Verification

  • To confirm that your changes are applied successfully, execute the following example command:

    $ oc get configmap greeting-props -o yaml
    Copy to Clipboard Toggle word wrap

6.2. Managed properties in workflow services

The OpenShift Serverless Logic Operator uses managed properties to control essential runtime behavior. These values are stored separately and override user-defined properties during each reconciliation cycle. You can also apply custom managed properties globally by updating the SonataFlowPlatform resource within the same namespace.

Some properties used by the OpenShift Serverless Logic Operator are managed properties and cannot be changed through the standard user configuration. These properties are stored in a dedicated ConfigMap, typically named <workflow-name>-managed-props. If you try to modify any managed property directly, the Operator will automatically revert it to its default value, but it will preserve your other user-defined changes.

Note

You cannot override the default managed properties set by the Operator using global managed properties. These defaults are always enforced during reconciliation.

The following table lists some core managed properties as an example:

Expand
Table 6.1. Managed properties overview
Property KeyImmutable ValueProfile

quarkus.http.port

8080

all

kogito.service.url

http://greeting.example-namespace

all

org.kie.kogito.addons.knative.eventing.health-enabled

false

dev

Other managed properties include Kubernetes service discovery settings, Data Index location properties, Job Service location properties, and Knative Eventing system configurations.

6.3. Defining global-managed-properties

You can define custom global managed properties for all workflows in a specific namespace by editing the SonataFlowPlatform resource. These properties are defined under the .spec.properties.flow attribute and are automatically applied to every workflow service in the same namespace.

Prerequisites

  • You have OpenShift Serverless Logic Operator installed on your cluster.
  • You have created your OpenShift Serverless Logic project.
  • You have access to a OpenShift Serverless Logic project with the appropriate roles and permissions to create applications and other workloads in OpenShift Container Platform.
  • You have installed the OpenShift CLI (oc).

Procedure

  1. Locate the SonataFlowPlatform resource in the same namespace as your workflow services.

    This is where you will define global managed properties.

  2. Open the SonataFlowPlatform resource in your default editor by executing the following command:

    $ oc edit sonataflowplatform sonataflow-platform-example
    Copy to Clipboard Toggle word wrap
  3. Define custom global managed properties.

    In the editor, navigate to the spec.properties.flow section and define your desired properties as shown in the following example:

    Example of a SonataFlowPlatform with flow properties

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowPlatform
    metadata:
      name: sonataflow-platform-example
    spec:
        properties:
            flow: 
    1
    
             - name: quarkus.log.category 
    2
    
               value: INFO 
    3
    Copy to Clipboard Toggle word wrap

    1
    Attribute to define a list of custom global managed properties.
    2
    The property key.
    3
    The property value to apply globally.

    This configuration adds the quarkus.log.category=INFO property to the managed properties of every workflow service in the namespace.

  4. Optional: Use external ConfigMaps or Secrets.

    You can also reference values from existing ConfigMap or Secret resources using the valueFrom attribute as shown in the following example:

    Example of a SonataFlowPlatform properties from ConfigMap and Secret

    apiVersion: sonataflow.org/v1alpha08
    kind: SonataFlowPlatform
    metadata:
      name: sonataflow-platform-example
    spec:
        properties:
            flow:
             - name: my.petstore.auth.token
               valueFrom: 
    1
    
                    secretKeyRef: petstore-credentials 
    2
    
                        keyName: AUTH_TOKEN
             - name: my.petstore.url
               valueFrom:
                    configMapRef: petstore-props 
    3
    
                        keyName: PETSTORE_URL
    Copy to Clipboard Toggle word wrap

    1
    The valueFrom attribute is derived from the Kubernetes EnvVar API and works similarly to how environment variables reference external sources.
    2
    valueFrom.secretKeyRef pulls the value from a key named AUTH_TOKEN in the petstore-credentials secret.
    3
    valueFrom.configMapRef pulls the value from a key named PETSTORE_URL in the petstore-props ConfigMap.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat