Default Tracking Token to head in case of Sagas

When a SagaConfigurer will make the Saga instance use a TrackingEventProcessor as the mechanism to receive events, it would be beneficial to make the initialTrackingToken of that Processor start at the head.

The thought behind this is that if a new Saga is introduced into the stack, you’d typically want to start that at the point in time you introduce that logic. Hence, the TrackingToken for the Tracking Processor of such a Saga should start at that point in time.

[smcvb]

I might not have been overly clear with my response @muradm, but “Allowing to configure TrackingEventProcessorConfiguration on per saga/processing group” is actually possible at the moment. Figured that was clear from my response, but I guess I have jumped to many hops then.

Let me restate my solution in a full fledged sample, something I tried to avoid the previous time around:

// Some Saga which we want to start from the head
@Saga
class MySampleSaga { ... }

...

// Our Configuration class to set up our MySampleSaga to start at the head
@Configuration
class AxonConfig {

    @Autowired
    public void configureMySampleSaga(EventProcessingConfigurer eventProcessingConfigurer) {
        TrackingEventProcessorConfiguration tepConfig =
                TrackingEventProcessorConfiguration.forSingleThreadedProcessing()
                                                   .andInitialTrackingToken(StreamableMessageSource::createHeadToken);
        String processorName = "MySampleSagaProcessor";

        eventProcessingConfigurer.registerTrackingEventProcessor(
                processorName, Configuration::eventStore, config -> tepConfig
        );
    }
}

Doing the above will ensure that whenever you start the TrackingEventProcessor (TEP) of your Saga for the first time, the token will be add the head of the stream. So there you are simply configuring the TEP used by your MySampleSaga to start it’s TrackingToken at the head of the stream. Retrieving such a token is the job of the StreamableMessageSource you are using, which typically defaults to the EventStore implementation used in your application.

Trusting this helps you out further @muradm.

[smcvb]

We’ve actually quite recently introduce a dedicated samples repository just for that purpose. This repo will be further filled up as time progresses, likely searchable through a different portal as well. So, happy to hear you find it valuable, stay tuned for more to come 😃