What is the use of processingGroup annotation?
One possible use case might involve specifying the order in which event handlers are processed. Assume you have the following code example.
The first class could be annotated with:
@Component
@ProcessingGroup(value = "some-unique-name")
@Order(1)
public class FirstHandlers{
@EventHandler
private void doSomething(SomeEvent event){
...
}
}
The second class could be annotated at class level with:
@Component
@ProcessingGroup(value = "some-unique-name")
@Order(100)
public class SecondHandlers{
@EventHandler
private void doSomethingElse(SomeOtherEvent event){
...
}
}
Doing so ensures event handlers in the FirstHandlers
class are always called before the ones in the SecondHandlers
class.
Surely there are some other use case as well. You could also check the documentation for more details.
From the reference docs:
So the processing group âprovides non-functional configurationâ. From my perspective the main thing here would be:
- creating specific processing groups for specific event handlers (overriding the default of one processing group per package)
- setting whether the processing group is a subscribing event processor or a tracking event processor.
In practice there is only one value you can give to the annotation (the name of the group):
And you need to configure it either using properties or through configuration in Java.
You can see usage of it in my example app:
- Projection class using the @ProcessingGroup annotation
- Configuring it to be a subscribing event processor
This is all in addition to the points raise in the excellent answer from @KDW
Not sure about other âmessagingâ type plugins but itâs also vital for consuming kafka messages that are not auto-routed. When you create a subscriber, it needs to be registered with the event processor where the processor name is specified. In addition to this (and not specifically documented) is that you then need to register the processor against a processor group name, e.g.
// ... kafka subscriber set-up ommitted
eventProcessingConfigurer.registerTrackingEventProcessor("processorName", configuration -> kafkaSubscriber);
eventProcessingConfigurer.assignProcessingGroup("myKafkaEventGroup", "processorName");
// ...
You can then create an event handler that processes incoming kafka events:-
@Component
@ProcessingGroup(value = "myKafkaEventGroup")
public class MyKafkaEventHandler {
@EventHandler
private void on(KafakEvent event){
...
}
}
Without registering the subscriber against a processor/group and then annotating your event handler the events are simply dropped, at least from my experimenting anyway.
The annotation @ProcessingGroup is designed for event handler (code) organization. More importantly, it has a real function allowing us to âorderâ event handler invocation. I can give you a simple example how we use it. There is a set of events from our main system that we need to create a data warehouse for our analytics group. Every day we create around 10K records and we would like to summarize them daily. So, we have a processing group called âsome-widget-createdâ, and we have 2 projectors âSomeWidgetCreatedProjector.javaâ using @Order(10) and âSomeWidgetCreatedSummaryProjector.javaâ using @Order(20). The aggregate id would be the someWidgetId in this case.
In this case, we need to handle creating the detail records first in the âCreatedâ projector listening to the âWidgetCreatedâ event and we also need to listen to the same event âWidgetCreatedâ in the âSummaryâ projector knowing that the detail record is already created and exists in the relational database when code starts executing in the âSummaryâ method âonWidgetCreatedâ method. This way the detail event projector âWidgetCreatedâ can concentrate on creating the detail records and the summary event projector âWidgetCreatedSummaryâ can concentrate on creating the summary records (querying the detail record by aggregateId).
âSeparation of Concernâ is observed and they (the event projectors) both are grouped under the same processing group âsome-widget-createdâ indicating both event handlers are acting on an overlapping set of âsome-widgetâ related events.