Axon 3.x to 4.x Saga configuration with EventProcessingStrategy

Imported from Google Groups
1

We’re in the process of transitioning from Axon 3 to 4 and aren’t quite sure how to configure our event processing strategy for Sagas. While most of the upgrade issues have been resolved through various forums, google foo, and source code trolling, finding the equivalent for the **SagaConfiguration**.subscribingSagaManager with an EventProcessingStrategy is proving challenging.

`

public static SagaConfiguration subscribingSagaManager(
Class sagaType,
Function<Configuration, SubscribableMessageSource<EventMessage<?>>> messageSourceBuilder,
Function<Configuration, EventProcessingStrategy> eventProcessingStrategy);

`

We currently configure our saga(s) beans in the following manner in order

`

@Bean
public SagaConfiguration activityMonitorSagaConfiguration(
SpringAMQPMessageSource eventSource,
@Qualifier(…) Executor executor) {

return SagaConfiguration.subscribingSagaManager(
ActivityMonitorSaga.class, c -> eventSource,
c -> new AsynchronousEventProcessingStrategy(executor,
SequentialPerAggregatePolicy.instance()));
}

@Bean
public SagaConfiguration licenseMonitorSagaConfiguration(
SpringAMQPMessageSource eventSource,
````@Qualifier(…) Executor executor) {

return SagaConfiguration.subscribingSagaManager(
````LicenseMonitorSaga.class, c -> eventSource,
c -> new AsynchronousEventProcessingStrategy(executor,
SequentialPerAggregatePolicy.instance()));
}

…

@Saga(sagaStore = “cachingSagaStore”)
class ActivityMonitorSaga { … }

@Saga(sagaStore = "cachingSagaStore")
class LicenseMonitorSaga { ... }

`

What is the proper way to configure a Saga with an EventProcessingStrategy in Axon 4? Your help is much appreciated and many thank yous in advance.

2

Hi Steven,

When making the move from Axon 3 to 4, we have taken a different stance on the SubscribingEventProcessor.
Firstly, we removed it’s default status, giving that over to the TrackingEventProcessor.

Secondly, we feel the SubscribingEventProcessor should mainly be used for synchronous processing, providing you the means to update a model in the same thread publishing the event.
This can for example be necessary when you hit Set Validation issue and require to have a small data model next to your Aggregates to validate the set.
Using the SubscribingEventProcessor here is key to make sure that model is updated with the uniqueness data in the same transaction as the event is published in.

When it comes to asynchronous processing, we feel the Tracking Event Processor really should be the way to go.
Having said all that, this change has not been cemented completely yet, as the EventProcessingStrategy is still there.
Reasoning for this is that we needed to give this a think as well and as such, we still left it in.

So, my recommendation here would be to use Tracking Event Processors for your Sagas.
If you desire to still use Subscribing Event Processor, then the only way to adjust the EventProcessingStrategy currently is by invoking the SubscribingEventProcessor.Builder manually to build the entire processor yourself.

Trusting this will help you further Steven.

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 as soon as this mailing list is closed.