Skip to main content

Channels

Channel models are used to define a way through which event data is received or sent to other systems, using a transport mechanism (like a Kafka topic, JMS queue, etc.).

When a channel is used to receive events, it's called an inbound channel. Likewise, a channel that sends events is an outbound channel.

Let's look at inbound channels first, which consist of two parts:

  • The adapter: The adapter is a technical implementation and listens for incoming events. Any event that is received is passed on to the channel pipeline.
  • The pipeline: The adapter receives the "raw" event, pretty much a collection of bytes. The channel pipeline will process this data to make it usable.

Inbound channel pipeline

Any of the dark blue boxes on the picture above are pluggable and extensible. This means that any such box can be swapped out by a custom implementation if the out-of-the-box implementations are insufficient.

The consumer in this picture is typically a BPMN or CMMN waiting activity.

The default pipeline consists of following steps:

  1. Deserialization: transforms the raw data to a more useful format (e.g. String to JSON)
  2. Event key detection: the channel can be used to receive multiple types of events. In this case, this step defines how the actual event type (indicated by the event key) is determined. If the channel receives only one type of events, this can be a fixed value.
  3. Payload extraction: events typically have data. This step extracts the data from the event and is called the event payload.
  4. (Optional) Tenant detection: In a multi-tenant setup, a channel can be used to receive events from different tenants. This step defines how the tenant is determined from the event data. It's also possible to have one channel per tenant. In that situation, this step isn't needed.
  5. Event transformation: The event data is transformed to an Event Instance, which is a special type of variable that can be used in process or case instances.

Whenever an event is received by the adapter, it is passed into the pipeline. Any consumer (implemented by various process and case constructs) now receives the event.

caution

This means that an inbound channel does not need to be linked to a specific process or case. The correlated event will be used to trigger case or process instances. Linking it is useful to ensure that it is part of the app. However, when you use multiple apps with the same channel, you might want to deploy the channel separately.

An outbound channel, compared to the inbound counterpart, is a bit simpler:

Outbound channel pipeline

The producer in this picture is typically a BPMN or CMMN automatic service task activity. Note that the external system can be the very same Flowable installation, listening to the same transport mechanism with an inbound channel.

The event data now follows the reverse trajectory. Starting from the producer, an outbound pipeline is followed which processes the event and eventually hands it to the adapter. The adapter will then do the actual sending. An outbound pipeline is (by default) quite simple:

  1. Event transformation: The event instance is transformed to something any adapter understands.
  2. Serialization: the event is serialized to the format that is expected by the other side. For example, it could be a JMS queue that is only capable of receiving XML messages.