NServiceBus provides really nice customisation features for your recoverability functionality. We already saw how you can customise the immediate and delayed retries. In this post we'll look at implementing our own custom policy which allows us to make decisions based on the exceptions that are thrown in the message handlers.

The NServiceBus documentation on customising your recoverability policy is well explained and so I recommend you read their documentation first. 

Errors can occur while processing messages and NServiceBus has a few different features to help you recover from failures. Retries are an obvious way of recovering from failure and NServiceBus offers two types of retries.

In this post we'll implement a class that inherits from IRoutingTopology and that plugs into NServiceBus to create a custom routing topology. There is also the IDeclareQueues interface that we could also implement but I doubt I would ever need to. NServiceBus creates a bunch of queues in addition to the main endpoint queue, for things like retries and timeouts. I don't want to mess with these as they are important for how NServiceBus gives us the functionality that it does. So in this post we'll just be customising the RabbitMq artefacts beyond the immediate endpoint queues.

In this post we'll look at how we can customise the Direct Routing Topology. The source code is on Github.

Create a new solution folder and called it RabbitMqTransportCustomDirectTopology and add the four projects named as follows: Rabbit.Custom.ClientUI, Rabbit.Custom.Sales, Rabbit.Custom.Billing and Rabbit.Custom.Shipping.

In the first part we ported the retail demo using Msmq to RabbitMq, with both the Direct and Conventional Routing Topologies. All source code is on Github.

Now we are going to add a CancelOrder command and OrderCancelled event, as follows