In this next post in our NServiceBus series, we learn how to coordinate processes involving multiple services using sagas. Read now!

NServiceBus Kata 4 - Long-Running Processes | Inventive

We now have a pretty solid way to send messages, publish messages and we've got those messages flowing over a reliable transport mechanism. Sending and publishing individual messages only gets us so far. We often need a way to coordinate complex processes which involve multiple services. For this NServiceBus has the concept of sagas which some might call process managers. 

Consider the bakery which is creating the cake for me to eat: when it starts making a new cake because I ate the last one it has a bunch of things it needs to coordinate. They need to preheat ovens, gather ingredients, mix ingredients, grease pans, fill pans, put pans in the oven, remember to take the cake out, cool it, ice it... the list goes on and on - no wonder cake is so expensive. Coordinating all these activities is complex in a distributed system, really in any system. There are a lot of corner cases that we usually fail to consider in a non-distributed system which become much more apparent when building out a process manager. What if we preheat the oven but then discover that we're all out of flour? In that monolithic system we might throw an exception and hope that somebody is monitoring for it in a log file somewhere. Realistically that's never going to happen. In the meantime nobody has shut the oven off and the bakery burns down. 

A saga allows us to store the state of a process, to react to messages as they come in and send new messages. We use this to coordinate the activities of the bakery. In our example above we can probably call the process "BakeCakeSaga". When messages come in relating to the order then we need to be able to find a way to look up the state and make modifications to it. NServiceBus implements this through a method called `ConfigureHowToFindSaga`. This function will provide a mapping from every message that interacts with the saga to find the saga data. For our example we'd probably use something like an order id. 

Let's build out a very simple saga which responds to just a few messages in our system so we can see how it works. Saga can get pretty complex but they are quite testable so that's nice.  

Create a saga which handles the messages `CakeOrderPlaced`, `CakeOrderCanceled`, `CakeOrderShipped`. Each of these messages will contain an `OrderId`, a GUID, which will be used to identify the saga as well as whatever information might be associated with those messages. For now just write out to the console when each of these messages is received - unless you want to bake me a cake which I will accept.

# The Solution
```
1. Add some mechanism to handle the persistence of saga data. For now we will just use the in learning persistence. In the various program.cs files add 

```
var persistence = endpointConfiguration.UsePersistence<LearningPersistence>();
```

2. Create messages classes in the messages project

```
namespace messages;

using NServiceBus;

public class CakeOrderPlaced : IEvent
{
    public Guid OrderId { get; set; }
    public Guid CustomerId { get; set; }
    public Date OrderDate { get; set; }
}

public class CakeOrderCanceled : IEvent
{
    public Guid OrderId { get; set; }
    public string Reason { get; set; }
}

public class CakeOrderShipped : IEvent
{
    public Guid OrderId { get; set; }
    public string ShippingReferenceNumber { get; set; }
}
```

3. Create a saga class in the receiver project

```
using NServiceBus;
using messages;
public class CakeOrderSaga : Saga<CakeOrderSagaData>,
    IAmStartedByMessages<CakeOrderCanceled>,
    IAmStartedByMessages<CakeOrderPlaced>,
    IAmStartedByMessages<CakeOrderShipped>
{

    protected override void ConfigureHowToFindSaga(SagaPropertyMapper<CakeOrderSagaData> mapper)
    {
        mapper.MapSaga(sagaData => sagaData.OrderId)
            .ToMessage<CakeOrderCanceled>(x => x.OrderId)
            .ToMessage<CakeOrderPlaced>(x => x.OrderId)
            .ToMessage<CakeOrderShipped>(x => x.OrderId);
    }

    public Task Handle(CakeOrderPlaced message, IMessageHandlerContext context)
    {
        Console.WriteLine($"Order {message.OrderId} placed");
        return Task.CompletedTask;
    }

    public Task Handle(CakeOrderCanceled message, IMessageHandlerContext context)
    {
        Console.WriteLine($"Order {message.OrderId} canceled");
        Data.OrderCanceled = true;
        return Task.CompletedTask;
    }

    public Task Handle(CakeOrderShipped message, IMessageHandlerContext context)
    {
        Console.WriteLine($"Order {message.OrderId} shipped");
        Data.OrderShipped = true;
        return Task.CompletedTask;
    }

}
```

4. Add a saga data class to the receiver project

```
using NServiceBus;

public class CakeOrderSagaData : ContainSagaData
{
    public Guid OrderId { get; set; }
    public bool OrderCanceled { get; set; }
    public bool OrderShipped { get; set; }
}
```

5. Modify the sender project's program.cs to send the messages adding a loop which sends all the different messages involved in the saga. 

```

bool continueMessages = true;
Guid orderId = Guid.NewGuid();

while (continueMessages)
{
    var line = Console.ReadLine();
    switch (line)
    {
        case "p":
            await endpointInstance.Publish(new CakeOrderPlaced { OrderId = orderId });
            break;
        case "c":
            await endpointInstance.Publish(new CakeOrderCanceled { OrderId = orderId });
            break;
        case "s":
            await endpointInstance.Publish(new CakeOrderShipped { OrderId = orderId });
            break;
        case "q":
            continueMessages = false;
            break;
        default:
            break;
    }

}
```

1. Run the applications and in the sender app try pressing some keys like `p` or `c` or `s` to see the messages being handled by the saga.

2. Try starting the applications in different orders and see how the saga handles the messages.

Notice that the Saga can be started by 3 different events. Why would a saga be started by a cancel message? You can't cancel an order which hasn't even been placed yet - right? Well it turns out you can. Without some serious hoop jumping through the order of message delivery it not guaranteed. So in fact orders can be canceled or shipped before we get the message telling us the order has been placed. It is sort of mind-blowing. 

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

Exciting times for me, I get to help out on an NServiceBus project! It's been way too long since I did anything with NServiceBus but I'm back, baby! Most of the team has never used NServiceBus before so I thought it would be a good idea to do a little kata to get them up to speed. I'll probably do 2 or 3 of these and if they help my team they might as well help you, too.

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 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

development

Insights

Work with us!

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