Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

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. Kubernetes service discovery

You can use Kubernetes service discovery to reference Kubernetes resources using a custom URI for HTTP requests. The OpenShift Serverless Logic Operator resolves this URI into a network endpoint (URL) during workflow deployment.

Note

Service discovery triggers a scan of workflow configuration parameters. If application startup time is critical, consider using a static URL instead.

6.4.1. URI pattern for service discovery

Service discovery URIs follow a structure based on the Group, Version, and Kind (GVK) of the resource:

kubernetes:<kind>.<version>.<group>/<namespace>/<resource_name>?<attribute_name>=<attribute_value>

where:

<kind>.<version>.<group>
Specifies the GVK of the resource.
<namespace>
Specifies the namespace of the resource. Defaults to current namespace if omitted.
<resource_name>
Specifies the name of the target resource.
<attribute_name>=<attribute_value>
Specifies additional resource attributes, such as labels or ports.
Supported schemes and resources

The service discovery URI supports the following schemes:

  • kubernetes
  • openshift
  • knative

    For Knative Services, you can use a simplified knative:<namespace>/<service_name> pattern.

The following table lists the supported Kubernetes resources for GVK identifiers:

Expand
ResourceGVK identifier

Kubernetes Service

services.v1

Knative Service

services.v1.serving.knative.dev

Pod

pods.v1

Deployment

deployments.v1.apps

DeploymentConfig

deploymentconfigs.v1.apps.openshift.io

StatefulSet

statefulsets.v1.apps

Route

routes.v1.route.openshift.io

Ingress

ingresses.v1.networking.k8s.io

Query parameters

Query parameters allow the Operator to filter or select specific resources when multiple matches exist.

The following table lists the supported query parameters:

Expand
ParameterPurposeExample

label

Filter resources when multiple resources match. Supports multiple labels joined with &.

label=app=myapp&env=prod

port

Select a specific port if multiple ports are exposed.

port=http

6.4.2. Service discovery resolution

The Operator performs Kubernetes service discovery during the deployment of a managed workflow. It scans the associated workflow config map for URIs that match the discovery pattern, parses each URI, queries the Kubernetes API, and writes the resolved endpoints to an operator-managed config map.

The Operator resolves resources differently based on their type:

  • Direct URL resolution: For Service, KnativeService, Ingress, or Route resources, the Operator returns the service URL or host IP. The Operator automatically uses https if TLS is detected.
  • Indirect service resolution: For Pod, Deployment, DeploymentConfig, or StatefulSet resources, the Operator checks for an associated service. If found, the Operator returns the service URL.
  • Error handling: If URI parsing fails or the resource does not exist, the Operator logs an exception. If a resource exists but has no associated service, the Operator issues a warning.
Important

The Operator fully controls the operator-managed config map. It overwrites any manual edits during the next reconciliation cycle.

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

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red Hat
Nach oben