This makes it possible to combine a chain of messages into a graph of producers and consumers. When a message is created within the context of an existing message, such as in a consumer, a saga, etc., the CorrelationId of the message (if available, otherwise the MessageId may be used) is copied to the InitiatorId header. If an existing context is used to send or publish a message, the ConversationId is copied to the new message, ensuring that a set of messages within the same conversation have the same identifier. The conversation is created by the first message that is sent or published, in which no existing context is available (such as when a message is sent or published by using IBus.Send or IBus.Publish). This header should not typically be set by the consumer, as it is handled automatically. When the message is received by a consumer, the response message sent by the Respond method (on the ConsumeContext) is assigned the same RequestId so that it can be correlated by the request client. When using the RequestClient, or the request/response message handling of MassTransit, each request is assigned a unique RequestId. In addition to the correlationId, the default headers include: # RequestId However, it is also completely acceptable to add your own custom properties to the message contract for correlation. There are several other built-in message headers that can be used to correlate messages. However, the header is still useful if you do not use sagas, for example for message flow analysis and debugging. It can also be manually specified using the SendContext.īear in mind that sagas default CorrelateById() only support messages where the explicit CorrelatedBy interface is implemented. If the message contract has a property named CorrelationId, CommandId, or EventId, the correlationId header is automatically populated on Send or Publish. In addition to the explicit CorrelatedBy interface, a convention-based correlation is supported. In this case, the order number is acting as your correlation identifier, it ties the messages together. For instance, you may have a message that says New Order (Item:Hammers Qty:22 OrderNumber:45) and there may be another message that is a response to that message that says Order Allocated(OrderNumber:45). So, what does correlated actually mean? In short it means that this message is a part of a larger conversation. If a new saga instance is created by the event, it will be assigned the CorrelationId from the initiating message.įor message types that have a correlation identifier, but are not using the CorrelatedBy interface, it is possible to declare the identifier for the message type and MassTransit will use that identifier by default for correlation. If a message implements CorrelatedBy, it will automatically be directed to the saga instance with the matching identifier. This is used by sagas as well, since all sagas have a unique CorrelationId for each instance of the saga. MassTransit provides the interface CorrelatedBy, which can be used to setup a default correlationId. In fact, most are setup by default if not specified by the developer. The headers on the message envelope provided by MassTransit already make it easy to specify correlation values. Since operations are potentially executing across hundreds of nodes, the ability to correlate different messages to build a path through the system is absolutely necessary for engineers to troubleshoot problems. In a distributed message-based system, message correlation is very important.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |