How to import/register Channels and Events

I’m a bit confused regarding Channel and Event support in the open source version.

I’ve created a Channel, an Event, and a Process with a trial of Flowable Enterprise via Designer. From there, I can, of course, export a zipped bar that contains everything.

Now I’m trying to understand if I can import those into the opensource version (I’m running the all-in-one docker image). I don’t see a way to import bars, or .event or .channel files.

I suppose they might not be compatible, but in that case, how do I define Channels and Events as configuration files? Or do I have to define them through Modeler? If I define them using Modeler, can they be exported?

Hey, I’ve hacked together some example code here: https://github.com/seletz/flowable-event-registry-demo

Maybe you find it useful.

From looking at your example, do I understand correctly that one just has to put the *.event and *.channel definitions files in a location that is in the path described by flowable.eventregistry.resource-location? (and flowable.eventregistry.enabled must be true, which I think it probably is in the all-in-one app)

I don’t see anything special going on to load them in your code, so I’m guessing the engine will load files from that location on it’s own?

Yes it does. Note that I haven’t had access to the enterprise version of flowable, so I needed some time to get the contents and format of the JSON files right.

The open source Modeler has a different way of handling events and channels: there, the event/channel is added on the element itself. The enterprise version has a specific model and UI for both events and channels.

As written above, the engine indeed picks up .event/.channel definitions. The class responsible for this is e.g. https://github.com/flowable/flowable-engine/blob/master/modules/flowable-event-registry-configurator/src/main/java/org/flowable/eventregistry/impl/configurator/deployer/EventDeployer.java#L44.

Hi Joram,

Thanks. Yes, I kind of figured that out by googling, although I haven’t quite gotten to trying it. It doesn’t seem to be terribly well documented. For example, with Kafka, one would put the topic in the Channel “Destination”, I believe?
Based on the the way the Channel and Event are basically inferred together from the properties of the a Start node, does that mean the one-to-many-to-many channel-to-event-to-process association is not possible in open source? Or is it just not supported through the editor, but could be modeled through files? What would happen if one specified the same channel name in two process start nodes? Would it create two channels with the same name, or is it smart enough to just create one?

The example is quite nice @seletz, thanks for sharing it.

Regarding your last post @ACoulson, the Flowable OSS Modeler is the one which generates files based on what you’ve modeled. However, if you use files only then only the channels defined in files ending with .channel will create and listen on channels. So you can have as many processes listening to the same event in the same channel.

I don’t quite understand what you are talking about here. Is this the UI (if yes which one?), or something else?

Cheers,
Filip

@filiphr actually, I’m referring to both the json definition of a channel and the Designer UI where I presume it would be exposed. The tooltip for “Channel destination” is definitely not very informative and the open source documentation doesn’t do a very good job of describing how a Kafka channel should be defined. It provide an example using JMS and does mention destination in a very non-specific way (“A Channel definition defines the destination of an incoming or outgoing event…”) but doesn’t really specify what is expected in the “destination” field when using kafka. The reader is left to infer from the JMS example, where it talks about a JMS Queue as an input “destination”, that for Kafka that might be the topic. Really, the use of the word “destination” is pretty confusing when referring to an input.

But the part I am least clear on is that, in Designer, you essentially define a Channel and Event in the properties that are specific to a particular Start node in a particular Process definition. If I understand how the core works, there is a one-to-many-to-many relationship between Channel-to-Events-to-Start Event Node. That’s not really being represented in Designer. So, in the Designer UI, if I create two different Processes, each of which has a Start Event Registry Event node, and I set Event and Channel properties to the exact same thing, it’s not clear to me what’s being defined within the resulting deployment. Does it create to Channels both consuming from the same topic? Or just one that is shared? And does it create two separate events or just one? If I wand to have another Process that listens to the same event, do I have to meticulously describe exactly the same event definition attributes again? Or since it’s already been defined in another Process node, can I just reference it?
I suppose I might just to have to experiment with it to find out…I just haven’t quite had the time to set up a full stack including Kafka to find out and tediously step the the step necessary to figure it out.

Correction: I meant “the Modeler UI” not “the Designer UI”. The open source modeler does not appear to expose the one-to-many relationships, so I’m trying to understand if they can still exist in the engine instanciated by flowable-task.

There is indeed Flowable Design, which has richer capabilities wrt channels and events (which is a commercial modeling tool for Flowable - but this forum is about the open source side of Flowable). The open source Modeler has indeed the limitations as you described.

That is correct and indeed the Modeler does not expose this. In fact, we see many people running it also with plain json configuration for service orchestration, like e.g. flowable-engine/modules/flowable-event-registry-spring/src/test/resources/org/flowable/eventregistry/spring/test/deployment at main · flowable/flowable-engine · GitHub

Channels can receive multiple types of events (defined by the event key) that then gets passed on. A channel is typically created for a topic to listen to incoming events. Another outgoing channel can exist for sending events back to the same channel (and potentially consume it through another process/case instance).

You’ve probably already seen Introducing the Flowable Event Registry – Flowable Blog or Flowable Business Processing from Kafka Events – Flowable Blog (which uses Flowable Design), and that one also links to an example done with Kafka here: flowable-examples/flowable-kafka at master · flowable/flowable-examples · GitHub

Thanks, yes, I was mistaking conflating Designer and Modeler. And, indeed, the demo and blog is what got me pointed in the right direction wrt prototyping this. I had a proof of concept that did work using a demo license of the commercial version, and am trying to recreate it using open source. I believe my company will be willing to go with a commercial license for the rollout of our solution, but in the meantime, I want to be able to continue demonstrating and prototyping new processes.