Questo contenuto non è disponibile nella lingua selezionata.

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>
  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

    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
      ...

  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

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
  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

    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

    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.

6.4. Custom PodSpec configuration

You can use a custom PodSpec configuration in the SonataFlow custom resource (CR) to meet specific container and deployment requirements on Red Hat OpenShift.

You can use this feature for advanced configurations, such as:

  • Setting CPU and memory requests and limits
  • Adding sidecar containers
  • Configuring volumes and mounts
  • Selecting a non-default deployment model

The OpenShift Serverless Logic Operator enables these customizations through the .spec.podTemplate attribute within the SonataFlow CR.

The following example shows a SonataFlow CR with defined resource requests and limits, along with environment variables for the workflow container:

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: <name>
spec:
  podTemplate:
    container:
      resources:
        limits:
          cpu: "250m"
          memory: "128Mi"
        requests:
          cpu: "100m"
          memory: "64Mi"
      env:
        - name: EXAMPLE_VAR
          value: "value"
    # ...

The .spec.podTemplate attribute supports most fields defined in the standard Kubernetes PodSpec API, and Kubernetes API validation rules apply.

6.4.1. Knative deployment model

By default, each SonataFlow instance is deployed as a Kubernetes Deployment object. To deploy the instance as a Knative Serving Service object, set the .spec.podTemplate.deploymentModel field to knative.

For example:

apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
  name: <name>
spec:
  podTemplate:
    deploymentModel: knative
    # ...
Important
  • Do not use the Knative deployment model in dev profile. If you specify this option, the Operator ignores it.
  • Knative can terminate idle pods, which can interrupt long-running workflows or slow external services.
  • Enable persistence for workflows using callback states to resume after pod termination.
  • Explicitly enable initContainers if your workflow requires them. Knative disables them by default.

6.4.2. Customization exceptions

You can add additional containers, initContainers, and volumes to the pod. However, some elements are operator-managed and cannot be overridden.

Container naming
Do not name any container workflow in the containers array. To customize the primary workflow container, use the .spec.podTemplate.container field. This approach helps prevent accidental misconfiguration when adding additional containers.
Operator-managed immutable volumes and paths

The Operator manages certain volumes and filesystem paths and ignores any attempts to override them.

Expand
VolumeTypePathProfile

workflow-properties

config map

/deployments/config/application.properties

preview

workflow-properties

config map

${PROJECT_ROOT}/src/main/resources/application.properties, ${PROJECT_ROOT}/src/main/resources/application-dev.properties

dev

resources

projected

${PROJECT_ROOT}/src/main/resources/

dev

Important

In the dev profile, the Operator mounts all workflow resources defined in the SonataFlow CR into the resources projected volume. Do not mount additional volumes or data at this path to avoid configuration conflicts or data loss.

6.4.3. Custom images

Custom image in the default container
Set the .spec.podTemplate.container.image attribute to indicate that the workflow image is already built. The Operator does not rebuild, upgrade, or reconcile the image and automatically selects the gitops profile.
Custom image in the dev profile
In the dev profile, base custom images on the default development image at registry.redhat.io/openshift-serverless-1/logic-swf-devmode-rhel8:<version>.
Custom image in the preview profile
When you specify a custom image in the preview profile, the Operator skips the internal build process and deploys the provided image. The .spec.resources attribute is ignored because the workflow content is supplied entirely by the image.
Important

Ensure that the workflow definition in .spec.flow matches the workflow packaged in the provided image. If these definitions differ, configuration, service discovery, and service binding might behave unexpectedly.

Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red Hat
Torna in cima