Este contenido no está disponible en el idioma seleccionado.
Chapter 6. Workflow eventing system
			You can set up the eventing system for a SonataFlow workflow.
		
In a OpenShift Serverless Logic installation, the following types of events are generated:
- Outgoing and incoming events related to workflow business logic.
- Events sent from workflows to the Data Index and Job Service.
- Events sent from the Job Service to the Data Index Service.
The OpenShift Serverless Logic Operator leverages the Knative Eventing system to manage all event communication between these services, ensuring efficient and reliable event handling.
6.1. Platform-scoped eventing system configuration
				To configure a platform-scoped eventing system, you can use the spec.eventing.broker.ref field in the SonataFlowPlatform custom resource (CR) to reference a Knative Eventing broker.
			
				This configuration instructs the OpenShift Serverless Logic Operator to automatically link every workflow deployed in the specified namespace, using the preview or gitops profile, to produce and consume events through the defined broker.
			
The supporting services deployed in the namespace without a custom eventing configuration are also linked to this broker.
In production environments, use a production-ready broker, such as the Knative Kafka Broker, for enhanced scalability and reliability.
				The following example displays how to configure the SonataFlowPlatform CR for a platform-scoped eventing system:
			
6.2. Workflow-scoped eventing system configuration
				A workflow-scoped eventing system configuration allows for detailed customization of the events produced and consumed by a specific workflow. You can use the spec.sink.ref and spec.sources[] fields in the SonataFlow CR to configure outgoing and incoming events.
			
6.2.1. Outgoing eventing system configuration
					To configure outgoing events, you can use the spec.sink.ref field in the SonataFlow CR. This configuration ensures the workflow produces events using the specified Knative Eventing Broker, including both system events and workflow business events.
				
					The following example displays how to configure the SonataFlow CR for a workflow-scoped outgoing eventing system:
				
- 1
- Name of the Knative Eventing Broker to use for all the events produced by the workflow, including the SonataFlow system events.
- 2
- Defines the namespace of the Knative Eventing Broker. If you do not specify a value, the parameter defaults to theSonataFlownamespace. Consider creating the broker in the same namespace asSonataFlow.
- 3
- Flow definition field in theSonataFlowCR.
- 4
- Events definition field in theSonataFlowCR.
- 5
- Example of an outgoing eventoutEvent1definition.
- 6
- Event type for theoutEvent1outgoing event.
6.2.2. Incoming eventing system configuration
					To configure incoming events, you can use the spec.sources[] field in the SonataFlow CR. You can add an entry for each event type requiring specific configuration. This setup allows workflows to consume events from different brokers based on event type.
				
If an incoming event type lacks a specific Broker configuration, the system applies eventing system configuration precedence rules.
					The following example displays how to configure the SonataFlow CR for a workflow-scoped incoming eventing system:
				
						The link between a spec.sources[] entry and the workflow event, is by using the event type.
					
- 1
- Configure the workflow to consume events of typein-event-type1using the specified Knative Eventing Broker.
- 2
- Name of the Knative Eventing Broker to use for the consumption of the events of typein-event-type1sent to this workflow.
- 3
- Optional: If you do not specify the value, the parameter defaults to theSonataFlownamespace. Consider creating the broker in the same namespace as theSonataFlowworkflow.
- 4
- Configure the workflow to consume events of typein-event-type2using the specified Knative Eventing Broker.
- 5
- Name of the Knative Eventing Broker to use for the consumption of the events of typein-event-type2sent to this workflow.
- 6
- Optional: If you do not specify the value, the parameter defaults to theSonataFlownamespace. Consider creating the broker in the same namespace as theSonataFlowworkflow.
- 7
- Flow definition field in theSonataFlowCR.
- 8
- Events definition field in theSonataFlowCR.
- 9
- Example of an incoming eventinEvent1definition.
- 10
- Event type for the incoming eventinEvent1. The link of the workflow event, with the correspondingspec.sources[]entry, is by using the event type namein-event-type1.
- 11
- Example of an incoming eventinEvent2definition.
- 12
- Event type for the incoming eventinEvent2. The link of the workflow event, with the corresponding spec.sources[] entry, is created by using the event type name in-event-type2.
6.3. Cluster-scoped eventing system configuration
				In a SonataFlowClusterPlatform setup, workflows are automatically linked to the Broker specified in the associated SonataFlowPlatform CR. This linkage follows the Eventing System configuration precedence rules.
			
				To ensure proper integration, you can configure Broker in the SonataFlowPlatform CR referenced by the SonataFlowClusterPlatform CR.
			
				The following example displays how to configure the SonataFlowClusterPlatform CR and its reference to the SonataFlowPlatform CR:
			
					The SonataFlowClusterPlatform CR can refer to any SonataFlowPlatform CR that has already been deployed.
				
6.4. Eventing system configuration precedence rules
The OpenShift Serverless Logic Operator follows a defined order of precedence to determine the eventing system configuration for a workflow.
Eventing system configuration precedence rules are as follows:
- If the workflow has a defined eventing system by using either workflow-scoped outgoing or incoming eventing system configurations, the choice of configuration takes priority over the other configuration and applies to the workflow.
- 
						If the SonataFlowPlatformCR enclosing the workflow has a platform-scoped eventing system configured, this configuration is then applied to the next step.
- If the current cluster is configured with a cluster-scoped eventing system, it is applied if no workflow-scoped or platform-scoped configuration exists.
- Review the following information, if none of the above configurations are defined: - The workflow uses direct HTTP calls to deliver SonataFlow system events to supporting services.
- 
								The workflow consumes incoming events by HTTP POST calls at the workflow service root path /.
- No eventing system is configured to produce workflow business events. Any attempt to produce such events might result in a failure.
 
6.5. Linking workflows to the eventing system
The OpenShift Serverless Logic Operator links workflows with the eventing system using Knative Eventing, SinkBindings, and triggers. These objects are created automatically by the OpenShift Serverless Logic Operator and simplify the production and consumption of workflow events.
				The following example shows the Knative Eventing objects created for an example-workflow workflow configured with a platform-scoped eventing system:
			
				The example-broker object is a Kafka class Broker, and its configuration is defined in the kafka-broker-config config map.
			
The following example displays how to configure a Kafka Knative Broker for use with the SonataFlowPlatform:
- 1
- The Kafka class is used to create theexample-brokerobject.
				The following example displays how the example-workflow is automatically linked to the example-broker in the example-namespace for event production and consumption:
			
- 1
- Theexample-workflowoutgoing events are produced by using theSinkBindingnamedexample-workflow-sb.
- 2
- Events of typein-event-type1are consumed by using theexample-workflow-inevent1-b40c067c-595b-4913-81a4-c8efa980bc11trigger.
- 3
- Events of typein-event-type2are consumed by using theexample-workflow-inevent2-b40c067c-595b-4913-81a4-c8efa980bc11trigger.
				You can list the automatically created SinkBinding named example-workflow-sb by using the following command:
			
oc get sinkbindings -n example-namespace
$ oc get sinkbindings -n example-namespaceExample output
NAME TYPE RESOURCE SINK READY example-workflow-sb SinkBinding sinkbindings.sources.knative.dev broker:example-broker True
NAME                   TYPE          RESOURCE                           SINK                    READY
example-workflow-sb    SinkBinding   sinkbindings.sources.knative.dev   broker:example-broker   TrueYou can use the following command to list the automatically created triggers for event consumption:
oc get triggers -n <example-namespace>
$ oc get triggers -n <example-namespace>Example output
NAME BROKER SINK AGE CONDITIONS READY REASON example-workflow-inevent1-b40c067c-595b-4913-81a4-c8efa980bc11 example-broker service:example-workflow 16m 7 OK / 7 True example-workflow-inevent2-b40c067c-595b-4913-81a4-c8efa980bc11 example-broker service:example-workflow 16m 7 OK / 7 True
NAME                                                              BROKER           SINK                                                     AGE   CONDITIONS   READY   REASON
example-workflow-inevent1-b40c067c-595b-4913-81a4-c8efa980bc11    example-broker   service:example-workflow                                 16m   7 OK / 7     True
example-workflow-inevent2-b40c067c-595b-4913-81a4-c8efa980bc11    example-broker   service:example-workflow                                 16m   7 OK / 7     True