Hi Jakub,
You haven’t found this information as the general approach to registering Event Handling Components is that it belongs to a single Processing Group.
In turn, it is the Processing Groups which can be paired under a given Event Processor, creating a hierarchy where the TEP really is in charge of:
-
One to more Processing Groups, which
-
Have one or more Event Handling Components
I don’t have a codified solution ready at hand here to make this work within a single application, although I am confident it can be achieved by going to the bare bones.
Key here is to look at the EventHandlerInvoker, which is the wrapper around 1…n Event Handlers.
It’s this EventHandlerInvoker which is configured on the AbstractEventProcessor (which the TEP implements).
Might it not be simpler to just provide several instances of the Event Handler, per tenant to service?
I understand that it increases the numbers of Event Handling Components quite some, depending on how many tenants you want to serve on this one application of course.
Note that the MultiStreamableMessageSource is there to combine several distinct event streams into one stream from the perspective of a TrackingEventProcessor.
It could thus be used to combine several contexts (when looking at multi-context, like supported by Axon Server), or to combine several tenant event streams to be handled by a single TEP.
From what you have been describing I don’t have the feeling the MultiStreamableMessageSource as what you need immediately right now, hence why I am pointing this out.
By the way, the multi-context support in Axon Server is pretty often used to allow for multi tenant support within your Axon applications.
Might be worth having a look at that, if this proves to be too big a configuration effort.
That’s my two cents, hope this helps!
Cheers,
Steven
PS. It is important to note that this mailing list will be discontinued as specified in this thread.
The thread also specifies where to look further for help when it comes to Axon.
