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 Link kopierenLink in die Zwischenablage kopiert!
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
ConfigMapnamed<workflow-name>-propsthat includes all the configurations before workflow deployment. For example, if your workflow name isgreeting, theConfigMapname isgreeting-managed-props. If suchConfigMapdoes not exists, the Operator creates the workflow to have empty or default content. -
Managed properties: automatically generated by the Operator and stored in a
ConfigMapnamed<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.
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-definedpropertiesConfigMap, or the Operator has created it.
Procedure
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>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 aConfigMapnamedgreeting-props.Edit the workflow
ConfigMapby executing the following example command:$ oc edit configmap greeting-propsReplace
greetingwith the actual name of your workflow.Modify the
application.propertiessection.Locate the
datasection and update theapplication.propertiesfield with your desired configuration.Example of
ConfigMapapiVersion: v1 kind: ConfigMap metadata: labels: app: greeting name: greeting-props namespace: default data: application.properties: | my.properties.key = any-value ...- After updating the properties, save the file and exit the editor. The updated configuration will be applied automatically.
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 Link kopierenLink in die Zwischenablage kopiert!
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.
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:
| Property Key | Immutable Value | Profile |
|---|---|---|
|
|
|
|
|
|
| |
|
|
|
|
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 Link kopierenLink in die Zwischenablage kopiert!
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
Locate the
SonataFlowPlatformresource in the same namespace as your workflow services.This is where you will define global managed properties.
Open the
SonataFlowPlatformresource in your default editor by executing the following command:$ oc edit sonataflowplatform sonataflow-platform-exampleDefine custom global managed properties.
In the editor, navigate to the
spec.properties.flowsection 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.category2 value: INFO3 This configuration adds the
quarkus.log.category=INFOproperty to the managed properties of every workflow service in the namespace.Optional: Use external
ConfigMapsorSecrets.You can also reference values from existing
ConfigMaporSecretresources using thevalueFromattribute 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-credentials2 keyName: AUTH_TOKEN - name: my.petstore.url valueFrom: configMapRef: petstore-props3 keyName: PETSTORE_URL- 1
- The
valueFromattribute is derived from the KubernetesEnvVarAPI and works similarly to how environment variables reference external sources. - 2
valueFrom.secretKeyRefpulls the value from a key namedAUTH_TOKENin thepetstore-credentialssecret.- 3
valueFrom.configMapRefpulls the value from a key namedPETSTORE_URLin thepetstore-propsConfigMap.
6.4. Kubernetes service discovery Link kopierenLink in die Zwischenablage kopiert!
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.
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 Link kopierenLink in die Zwischenablage kopiert!
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 knativeFor Knative Services, you can use a simplified
knative:<namespace>/<service_name>pattern.
The following table lists the supported Kubernetes resources for GVK identifiers:
Expand Resource GVK identifier Kubernetes Service
services.v1Knative Service
services.v1.serving.knative.devPod
pods.v1Deployment
deployments.v1.appsDeploymentConfig
deploymentconfigs.v1.apps.openshift.ioStatefulSet
statefulsets.v1.appsRoute
routes.v1.route.openshift.ioIngress
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 Parameter Purpose Example label
Filter resources when multiple resources match. Supports multiple labels joined with
&.label=app=myapp&env=prodport
Select a specific port if multiple ports are exposed.
port=http
6.4.2. Service discovery resolution Link kopierenLink in die Zwischenablage kopiert!
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, orRouteresources, the Operator returns the service URL or host IP. The Operator automatically useshttpsif TLS is detected. -
Indirect service resolution: For
Pod,Deployment,DeploymentConfig, orStatefulSetresources, 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.
The Operator fully controls the operator-managed config map. It overwrites any manual edits during the next reconciliation cycle.
6.5. Custom PodSpec configuration Link kopierenLink in die Zwischenablage kopiert!
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 Link kopierenLink in die Zwischenablage kopiert!
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
# ...
- 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
initContainersif your workflow requires them. Knative disables them by default.
6.5.2. Customization exceptions Link kopierenLink in die Zwischenablage kopiert!
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
workflowin the containers array. To customize the primary workflow container, use the.spec.podTemplate.containerfield. 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 Volume Type Path Profile workflow-propertiesconfig map
/deployments/config/application.propertiespreviewworkflow-propertiesconfig map
${PROJECT_ROOT}/src/main/resources/application.properties,${PROJECT_ROOT}/src/main/resources/application-dev.propertiesdevresourcesprojected
${PROJECT_ROOT}/src/main/resources/devImportantIn the dev profile, the Operator mounts all workflow resources defined in the
SonataFlowCR into theresourcesprojected volume. Do not mount additional volumes or data at this path to avoid configuration conflicts or data loss.
6.5.3. Custom images Link kopierenLink in die Zwischenablage kopiert!
- Custom image in the default container
-
Set the
.spec.podTemplate.container.imageattribute 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.resourcesattribute is ignored because the workflow content is supplied entirely by the image.
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.