.NET on AWS – Queuing with SQS (Part-2)

Introduction

In previous post, we started with basics of Amazon SQS, typical use cases and need for queuing mechanism in a solution. We then discussed how our .NET applications can benefit from this managed service for offloading tasks to some background processes. We also setup an SQS Queue and installed related NuGet package in our .NET solution.

Following diagram is a reference to our solution design, we are building.

Today, we’ll cover how to publish messages to the SQS queue from our web-api application (Publisher) to SQS queue.

Connecting with Queue

For publishing purposes, we need two pieces of information about our queue and those are the region and queue URL which we can get from AWS web console from our SQS queue details page.

I’ve created following section in appsettings.json file for these settings related class SQSSettings and use it in Porgram.cs to read these settings from json file to be used later in application as shown below:

Publishing to the Queue

We need some setup before we actually publish messages to the queue. So, what is the message structure we want to publish to the queue is defined as following Event class

This is the payload, our web-api application will be sending to AWS SQS.

In order to deliver this payload to queue, we’ll encapsulate this functionality using an interface as follows:

This way, we have an abstraction and we can add a different implementation later if we want to use a different queuing service such as RabbitMQ or Microsoft Azure etc.

Following is the implementation of the interface

As you can see that this class is using objects from AWSSDK.SQS package we installed in previous post.

In the constructor, we are injecting some dependencies and configuring an SQS client and queueUrl as shown below:

And the PublishEvent method is as follows

I’ll not go into much details of this code as it is self explanatory. However, let me know if you have some questions.

Note that, we can also add some meta-data as MessageAttributes to our message. This meta-data is not encrypted and is not used in message hash generation but can be useful in many cases.

Also, I added the following to the Program.cs to wire up this service via Dependency Injection:

Next, we’ll see where and how this service is actually used in our web-api application.

Updating Controller

We have an existing controller in our web-api application which is currently implementing a REST api to allow CRUD operations on the Notes entity.

Now, we’ll update the controller’s methods code to use the SQSEventPublisher service to send messages to SQS.

Injecting the SQSEventPublisher to Notes controller

We’ve wired up the service with DI framework earlier and following code shows the injection setup in the constructor:

Now, we have service injected via constructor injection, we can use it in controller’s methods.

Publishing Message to SQS Queue

The following screenshot shows, how we can send an Event payload to SQS using eventPublisher service we implemented earlier:

Next, I used Postman tool to make a call to this endpoint which shall also publish an Event as message to SQS:

Viewing Messages using AWS Console

We haven’t implemented the consumer part yet, but for now, we can use AWS web console to check that the message was sent to the SQS Queue:

We can go into details of the queue by clicking it and poll for messages as shown below:

Further selecting the message and clicking View details button, we can see the message payload and other information such as Attributes as shown below

As you can see that it contains the data as expected. Now, this process will be repeated for other controller’s methods to send messages to SQS as needed.

I’ve already updated other Notes Controller’s methods with similar code and you can check the details from git repository. I tested controller API using postman and following is the screenshot of SQS queue showing messages sent when those controller methods were executed:

Solution Update

At this point, we’ve implemented the publishing part of our solution

In the next post, we’ll focus on the consumer part (.NET worker service) and conclude this series about SQS.

Summary

In this post, we continued with the message publishing part of our solution and successfully implemented it. We learned about the necessary settings to connect with SQS queue for publishing purposes and also how AWSSDK.SQS nuget package make it very easy to interact with SQS.

We updated the Notes controller code to use an SQSEventPublisher service to push messages to queue and those messages were indeed received by SQS. We then inspected the message details using AWS SQS Console.

In next post, we’ll focus on the implementing the Consumer part, which will poll messages from SQS queue and process them.

The source code is available from this git repository.

Let me know if you have some comments or questions. Till next time, Happy coding.