This document describes how to consume messages from and send messages to non-NServiceBus endpoints via RabbitMQ in integration scenarios.
Access to the received native RabbitMQ message details
It can sometimes be useful to access the native RabbitMQ message from behaviors and handlers. When a message is received, the transport adds the native RabbitMQ client BasicDeliverEventArgs
to the message processing context. Use the code below to access the message details from a pipeline behavior:
class AccessToBasicDeliverEventArgs : Behavior<IIncomingContext>
{
public override Task Invoke(IIncomingContext context, Func<Task> next)
{
var userIdOnBroker = context.Extensions.Get<BasicDeliverEventArgs>().BasicProperties.UserId;
//do something useful
return next();
}
}
Custom message ID strategy
By default, the message-id
property of the AMQP standard is used to relay the message identity. If this property isn't set, the transport will throw an exception because NServiceBus requires a message identity to perform retries, de-duplication, etc., in a safe way.
For integration scenarios where the sender is not controlled, the receiver might need to employ a custom strategy that extracts a message identity from a custom header or part of the message body. This custom strategy can be configured by calling:
var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();
transport.CustomMessageIdStrategy(
customIdStrategy: deliveryArgs =>
{
var headers = deliveryArgs.BasicProperties.Headers;
return headers["MyCustomId"].ToString();
});
It is extremely important that the custom strategy is deterministic (it returns the same value when invoked multiple times for the same message), and that no two messages are assigned the same value.
Message type detection
The native message must allow NServiceBus to detect message type either via headers or message payload.