I currently have a some sagas that pass around a custom CorrelationId on a base message class. All events and commands inherit from that base class and so have easy access to the CorrelationId. As a result, the ConfigureHowToFindSaga
mappings look something like this:
protected override void ConfigureHowToFindSaga(SagaPropertyMapper<MySagaData> mapper)
{
mapper.ConfigureMapping<MyCommand>(message => message.CorrelationId)
.ToSaga(sagaData => sagaData.CorrelationId);
mapper.ConfigureMapping<MyEvent>(message => message.CorrelationId)
.ToSaga(sagaData => sagaData.CorrelationId);
}
In each step of the saga (and the other services that the saga communicates with) the custom CorrelationId is currently manually mapped from message to message like so:
public Task Handle(MyCommand message, IMessageHandlerContext context)
{
// do something
return context.Publish(new MyEvent { CorrelationId = message.CorrelationId });
}
I was wondering if I could use the NSB ConversationId
message header to replace the custom CorrelationId as I believe NSB already maps this from message to message automatically.
I had two questions relating to this:
1. Does this sound reasonable?
2. If it does, is there a simple way set up the ConfigureMapping
mappings so that the saga will read from the context.MessageHeaders[Headers.ConversationId]
rather than directly from a property on the message body? I realise I could write a custom SagaFinder to dig into the headers and get the ConversationId and use that to then find the saga. However, I thought that if I needed to do this for every saga then maybe the whole approach is wrong.
Thanks
The saga mapping property's intention is to provide a unique identifier of to the Saga from a business aspect, i.e bank transaction, order id, claimid, or another example might be loan id. so relaying on a technical identifier sounds like you are going down the wrong direction...
What is your business story for those sagas?