Skip to main content

Introducing Events and Channels

Outdated documentation page

This is an old version of the documentation for Flowable until version 3.13 and for the Angular-based Flowable Design 3.14/3.15. If you are running the latest version of Flowable please check out the current version of this page.

In many modern use cases, data resides in and moves through different services and systems. These systems often communicate with each other through 'events', which e.g. indicate that new data has been created, something has changed, some functionality was triggered, etc. With these events, the pattern of

if this happens --> do this

can be implemented in a scalable way (both technically and functionally), giving rise to so-called event-driven architectures (or at least, event-capable architectures). In these kind of architectures, often the events are exchanged using a queueing or event streaming solution. Flowable Work (and thus Flowable Engage too) supports this out of the box

Other solutions can be plugged in via extension mechanisms of Flowable.

Continuing on the 'if event happens -> do this' pattern, one fundamental problem to solve is that of context to apply the 'do this' part. The event originates from some system and is then propagated to other systems that are interested in it. However, the consequence of the event happening always needs to be applied in a certain context on the receiving side to be useful.

Process and case models are a natural fit when it comes to providing this context. If a process or case instances are waiting for a certain event to happen, the actual process or case instance is the context (data variables, documents, people, etc.) in which the event can be applied without having to worry about gathering everything that's relevant to handle the event.

Versioning​

When it comes to versioning channel and event definitions, things are slightly different from the standard way deployments and definition versions are handled.

When it comes to determining which channel definition is used, the latest deployed version (for the same key) will be used. The reasons are the following:

  • It's highly unlikely that multiple queues (or topics, etc.) would be setup for handling the same use case.
  • For the receiving side, it would be inefficient to keep an instance of a 'listener' running for all versions of the inbound channel definition.

When it comes to event definitions, the same rule applies: the event detection step of the channel pipeline will always use the latest version of a deployed event definition.

Configuration properties​

See the admin guide for details on how to enable and configure the connection with a queueing solution.