Learn how to use a message queue to send messages reliably using NServiceBus and C# applications. Read the blog post now!

NServiceBus Kata 1 - Sending Messages | Inventive

Our goal is to very simply demonstrate reliable messaging. If you're communicating between two processes on different machines a usual approach is to send a message using HTTP. Problem is that sometimes the other end isn't reachable. Could be that the service is down, could be that the network is down or it could be that the remote location was hit by a meteor. HTTP won't help us in this case - what we want is a reliable protocol which will save the message somewhere safe and deliver it when the endpoint does show up. 

For this we use a message queue. There are approximately 9 billion different messaging technologies out there but we're going to use NServiceBus. NServiceBus is a .NET library which wraps up a lot of the complexity of messaging. It is built to be able to use a variety of transport such as  RabbitMQ and Azure Service Bus.

We want to make use of NServiceBus and a few C# applications to demonstrate reliable messaging.

I like cake but I feel bad about eating it because it's not good for me. So in this kata you need to command me to eat cake. I can't refuse a command to eat cake so I can't possibly feel bad about it.

Create a sender application which sends a message to a receiver application. The receiver application should be able to receive the message and write it to the console. The sender application should be able to send the message and then exit. The receiver application should be able to start up and receive the message even if the sender application isn't running.

# My Solution
1. Create a new directory for the project

```

mkdir kata1

cd kata1

```

2. Create a new console project for the sender

```

dotnet new console -o sender

```

3. Create a new console project for the receiver 

```

dotnet new console -o receiver

```

4. Create a new class library for the messages

```

dotnet new classlib -o messages

```

5. Add a reference to the messages project in the sender and receiver projects

```

dotnet add sender reference ../messages

dotnet add receiver reference ../messages

```

6. Add a reference to NServiceBus in all the projects

```

dotnet add sender package NServiceBus

dotnet add receiver package NServiceBus

dotnet add messages package NServiceBus

```

7. Create a new class in the messages project (and remove Class1.cs)

```

namespace messages;

using NServiceBus;

public class EatCake: ICommand

{

    public int NumberOfCakes { get; set; }

    public string Flavour { get; set; } = "Chocolate";

}

```

8. Update Program.cs in the sender project to send a message

```

using messages;

using NServiceBus;

Console.Title = "NServiceBusKata - Sender";

var endpointConfiguration = new EndpointConfiguration("NServiceBusKataSender");

// Choose JSON to serialize and deserialize messages

endpointConfiguration.UseSerialization<SystemJsonSerializer>();

var transport = endpointConfiguration.UseTransport<LearningTransport>();

var endpointInstance = await Endpoint.Start(endpointConfiguration);

await endpointInstance.Send("NServiceBusKataReceiver", new EatCake{

    Flavour = "Coconut",

    NumberOfCakes = 2 //don't be greedy

});

await endpointInstance.Stop();

```

9. Update Program.cs in the receiver project to be an endpoint

```

using NServiceBus;

Console.Title = "NServiceBusKata - Reciever";

var endpointConfiguration = new EndpointConfiguration("NServiceBusKataReceiver");

// Choose JSON to serialize and deserialize messages

endpointConfiguration.UseSerialization<SystemJsonSerializer>();

var transport = endpointConfiguration.UseTransport<LearningTransport>();

var endpointInstance = await Endpoint.Start(endpointConfiguration);

Console.WriteLine("Press Enter to exit...");

Console.ReadLine();

await endpointInstance.Stop();

```

10. Add a message handler to the receiver project

```

using messages;

public class EatCakeHandler :

    IHandleMessages<EatCake>

{

    public Task Handle(EatCake message, IMessageHandlerContext context)

    {

        Console.WriteLine($"Cake eaten, NumberOfCakes = {message.NumberOfCakes}; Flavour = {message.Flavour}");

        return Task.CompletedTask;

    }

}

```

In this next post in our NServiceBus series, we’re looking at how to extend our system to publish messages. Read the blog post now!

NServiceBus Kata 2 - Publishing Messages | Inventive

In the previous kata we sent a message from one application to another. This is a common pattern in messaging systems. In this kata we're going to look at a different pattern: publishing a message.

It is great being able to send a message from one system to another - you can instruct a remote system to take some action which you don't know how to do. For instance sending an email. In a large system lots of processes will likely result in an email but if you can centralize the logic around how to send an email it makes it very easy to do things like change email providers as that functionality is isolated and independent. 

If you looked at my solution for the first Kata then you might have notice that I named my message `EatCake` this is named in the imperative form. This is a common pattern in messaging systems and is, I think, remarkably helpful to understand the command pattern. When you issue a command you know exactly who or what you're commanding and in the same way the command is sent to a known endpoint. 

Sometimes, however, you don't have a particular target in mind and you just want to let other systems know that you have done something. In this case you can publish a message. Unlike a command you don't know who is going to act on it - it may be nobody or it may be multiple people. In a messaging system we call this an `Event`. 

Let's extend our cake eating example to imagine some consequences of what might happen if I happily reported that I had eaten cake: `CakeEaten`. Finding out that the cake had been eaten the bakery might start baking more cake assuming that I'd want more (very likely). My gym might free up a treadmill knowing that my cake-induced guilt might drive me to run until I'd burned off the delicious butter-cream. It might also be of interest to my wife who can text me and see if I enjoyed the cake. I don't actually know who would be interested in the event so it is the responsibility of those who are interested to subscribe to the event.

Using the solution to the first kata as a starting point extend the system to publish a `CakeEaten` message. Subscribe to the message in the sender and write out a message to the console. Also create another new project similar to the others and have it subscribe to the message.

# My Solution

1. Create a new message in the messages assembly

```
namespace messages;

using NServiceBus;

public class CakeEaten : IEvent
{
    public DateTime EatingFinishedAt { get; set; }
}
```

2. Modify the Hander in the receiver to publish the new event. Notice that we have access to a `IMessageHandlerContext` which we can use to publish messages.

```
using messages;

public class PlaceOrderHandler :
    IHandleMessages<EatCake>
{
    public async Task Handle(EatCake message, IMessageHandlerContext context)
    {
        Console.WriteLine($"Cake eaten, NumberOfCakes = {message.NumberOfCakes}; Flavour = {message.Flavour}");
        await context.Publish(new CakeEaten
        {
            EatingFinishedAt = DateTime.Now
        });
    }
}
```

3. Modify the sender to subscribe to the event by adding a Handler to the project.

```
using messages;

using NServiceBus;

public class CakeEatenHandler :
    IHandleMessages<CakeEaten>
{
    public Task Handle(CakeEaten message, IMessageHandlerContext context)
    {
        Console.WriteLine($"Uh oh, somebody ate a cake at {message.EatingFinishedAt}");
        return Task.CompletedTask;
    }
}
```

4. Optionally modify the sender to remain running so that it can receive the message. This is done by adding a `Console.ReadLine()` at the end of the `Main` method.

```
using NServiceBus;

Console.Title = "NServiceBusKata - Sender";

var endpointConfiguration = new EndpointConfiguration("NServiceBusKataReceiver");

// Choose JSON to serialize and deserialize messages
endpointConfiguration.UseSerialization<SystemJsonSerializer>();

var transport = endpointConfiguration.UseTransport<LearningTransport>();

var endpointInstance = await Endpoint.Start(endpointConfiguration);

Console.WriteLine("Press Enter to exit...");
Console.ReadLine();

await endpointInstance.Stop();
```

Pause here and ensure that when running the sender and receiver that you see both a message sent and published.

5. Create a new project to act as a second subscriber or receiver

```
dotnet new console -o anotherReceiver
dotnet add anotherReceiver reference ../messages
dotnet add anotherReceiver package NServiceBus
```

6. Add a subscriber class to the project

```
using messages;

using NServiceBus;

public class CakeEatenHandler :
    IHandleMessages<CakeEaten>
{
    public Task Handle(CakeEaten message, IMessageHandlerContext context)
    {
        Console.WriteLine($"Awesome, somebody ate a cake at {message.EatingFinishedAt}. Time to bake another");
        return Task.CompletedTask;
    }
}
```

7. Update the Program.cs to initiate NServiceBus

```
using messages;
using NServiceBus;

Console.Title = "NServiceBusKata - AnotherPublisher";

var endpointConfiguration = new EndpointConfiguration("NServiceBusKataAnotherReceiver");

// Choose JSON to serialize and deserialize messages
endpointConfiguration.UseSerialization<SystemJsonSerializer>();

var transport = endpointConfiguration.UseTransport<LearningTransport>();

var endpointInstance = await Endpoint.Start(endpointConfiguration);


Console.ReadLine();

await endpointInstance.Stop();

```

1. Start the receiver and the another receiver then the sender - ensure you see messages flowing correctly

2. Start services in different orders and see which messages might be lost

Sending and receiving messages and publishing messages should now be working great. But to get this example going we've made some simplifications which we'll have to address in the next kata.

NServiceBus Kata 3 - Switching Transports

In this next post in our NServiceBus series, we’re switching out the LearningTransport for the RabbitMQ Transport. Read the blog post now!

NServiceBus Kata 3 - Switching Transports | Inventive

In the previous article we looked at publishing messages and the one before that sending messages. But in both cases we cheated a little bit: we used the LearningTransport. This is effectively just a directory on disk. It cannot be used as real world transport. Let's change out this transport for something more production ready.

One of the really nice things about NServiceBus is that it abstracts away a lot of the mess of dealing with transports. You can spend less time fiddling with plumbing and more time getting to the nitty gritty of building business value. We have a lot of options for transport and the ability to write new ones if needed. The official supported transports are 

Each of these has advantages and disadvantages which you can read about in some detail in the documentation. In a production environment I'd push heavily towards Azure Service Bus but it has a major disadvantage: no local emulator. There is a github issue open to add an emulator which has been open since 2018. Normally I'd grumble a bit about how this is never going to be solved but actually the team has dedicated resources to building one out and think they'll have one ready by the end of 2024. Only you, dear readers from the future, know if this came to fruition.

For now we're going to take advantage of the interchangeability of transports and switch out the LearningTransport for the RabbitMQ transport. This can be run with a container on docker. 

Take the solution developed already and switch out the learning transport for the RabbitMQ transport running inside of a container. Everything should continue to work as it did before but now using RabbitMQ.

# My Solution

1. Download and run the RabbitMQ container

```bash
docker run -d --hostname nsbkata --name nsbkata-rabbit -p 15672:15672 -p 5672:5672 rabbitmq:3-management
```

2. Install the RabbitMQ transport package in all the projects
```
dotnet add sender package NServiceBus.RabbitMQ
dotnet add receiver package NServiceBus.RabbitMQ
dotnet add anotherReceiver package NServiceBus.RabbitMQ
```

3. Modify the endpoint configurations across all the projects swapping 

```
var transport = endpointConfiguration.UseTransport<LearningTransport>();
```

with 

```
var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();
transport.ConnectionString("host=localhost");
transport.UseConventionalRoutingTopology(QueueType.Quorum);
```

4. It is generally best that you take control of creating queues for NServiceBus but tooling is provided. Install that tooling 

```
dotnet tool install -g NServiceBus.Transport.RabbitMQ.CommandLine
```

Next create the queues for the endpoints (and the delays queues)

```
rabbitmq-transport delays create  -c "host=localhost"
rabbitmq-transport endpoint create NServiceBusKataAnotherReceiver -c "host=localhost"
rabbitmq-transport endpoint create NServiceBusKataReceiver -c "host=localhost"
rabbitmq-transport endpoint create NServiceBusKataSender -c "host=localhost"
```

1. Run the sender, receiver and anotherReceiver projects. You should see the messages being sent and received as before.

2. Log into the RabbitMQ management console(running at http://localhost:15672/ with credentials `guest`/`guest`) you should see the queues created and in fact a message processed

Browse our blog for the latest information and insider tips on everything development, website, software, and marketing related. Start reading now!

Blog - Development, Migration, and Website Tips & Tricks | Inventive

user experience

Insights

User Testing for Bad Dogs

Work with us!

Tell us a little bit more about your project or idea!