What is the use of processingGroup?

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.

2 Likes

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):

image

And you need to configure it either using properties or through configuration in Java.

You can see usage of it in my example app:

This is all in addition to the points raise in the excellent answer from @KDW

1 Like

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.

1 Like