Options for handling multiple Request/Response correlation within a saga

#1

Hey Everyone,

We currently have a Saga that sends 2 request/response (full-duplex) messages, that are of the same message type ( AddNoteToOrder ), throughout it’s execution for a SINGLE order.

AddNoteToOrder

  • OrderId
  • Subject
  • Note

Our Saga needs to perform different logic for each response. Therefore, we need to distinguish between which response came from what request.

Is there any advice on how we should approach this? I see the below options:

  1. Generate a Guid and use this as the messageId of the request. This will be set by the nservicebus framework as the correlationid “automatically” on the response message. I can then use this to understand what request this response is associated with.

  2. Add a property of type GUID to the message called CorrelationId to the request and response message. Assign the value to the CorrelationId on the response message.

  3. Use some existing property of combination of properties on the existing message. This seems like a bad idea depending on which and what properties are used because this would be unclear to the consumer which one can be used as a correlation id and is expected to be “unique” between messages.

For Option 1, i couldn’t find any information in the nservicebus documentation referring to this. i was not sure if this is considered bad practice. For Example, is the NServiceBus CorrelationId header only meant to be used internally by nservicebus for request/response correlation OR can this be used for applications to take advantage of?

Any advice and feedback would be great on this!

#2

Michael:

1: This option, while would work, it feels like you are mixing infrastructure and business logic concerns and in general I try to avoid doing that whenever possible.

2: I like this option, and is one I have used often in the past. It is very straightforward, the property name can be semantic to the business logic (I would personally avoid CorrelationId because it sounds too much like infrastructure to my NSB-tuned mind).

  1. Yeah, compound keys always have that problem. I don’t think they are a tool you should completely throw away, but in general, I try to avoid them unless they would be naturally used together in a compound way.

Other options would be:

Header value: This would work, but like using MessageId I think headers are best left for infrastructure requirements, not business logic.

Message type: This is another favorite of mine. I know many developers worry about having too many message types, but they are great semantically. Would something like “AddFirstNoteToOrder” / “AddSecondNoteToOrder” work?

Without more detailed information about the exact business requirements, I can’t give you specific advice. If you would like me to reach out to you we can schedule a call to discuss the details of your business requirements in a more private setting.

  • Bob
#3

Hey @boblangley ,

We ended up going with option 2. Because we are using the database to generate the ID of notes ( identity column ) we don’t really have anything unique on the message that would be a good fit for representing the given request. Thanks for the feedback as always!