In Azure Bits #2 – Saving the Image to Azure Blob Storage, we were able to save our image to Azure Blob Storage and verify that this all went according to plan after re-publishing our site to Azure.
In this Azure Bit, we will take a look at the Azure Queue service and we will place a message in the queue to signal that our newly-uploaded image is ready to be processed.
The first thing we will need to do is to create our IQueueService/QueueService to abstract the interaction with the Azure Queue service. We’ll just need one method for now.
We’ll need to know the queue name for our Azure Queue and we’ll need the Blob Storage Connection string, so I’ll go ahead and add the ImagesQueue name to our appSettings in web.config.
Finally, here’s the initial skeleton of QueueService. You’ll see that I went ahead and fetched the connection string and queue name in the constructor of QueueService.
Wiring the Controller
Now, let’s jump into our HomeController and call the IQueueService’s method to add the message to the queue. We’ll first need a concrete implementation of IQueueService. Here again for sake of demo, I am just creating a QueueService directly and skipping Dependency Injection.
Serializing the Message for the Queue
One important thing to note is that messages that are posted to Azure Queue service have a maximum size of 65k. If you recall from the first Azure Bit, I mentioned that we would use the UploadedImage class as the payload of our Azure Queue message. However, if we just push the UploadedImage directly to the Azure queue, we will get an Exception since the Data property will almost always exceed 65k as it contains a full byte array copy of the image. We do not even need that copy of the image in our Queue message. The UploadedImage class contains the Url where the image is stored in Azure and that’s all we need to get our original image for processing. There are numerous ways we could deal with this Data property, such as using a separate object to upload to the queue that didn’t have this property, removing/replacing the byte array before saving, etc. What I have chosen to do instead is simply indicate that the Data property should not be serialized by replacing the Auto property we had for Data with an explicit property and backing field and then adding the [NonSerialized] attribute to the backing field to indicate that we do not want this data to be included in the serialization process. You’ll also need to add the [Serialized] attribute to the UploadedImage and Thumbnail classes as we will ultimately be posting the UploadedImage to the queue service in the form of a byte array which we will serialize shortly.
Adding the Message to the Queue
Now that we have the outer plumbing in place to insert the UploadedImage into the Azure queue, let’s revisit the AddMessageToQueueAsync method on QueueService where the actual interaction with the Azure queue takes place. First, we get the queue via a private GetQueue method (more on that below). Then, we serialize the object that will be the payload of our Azure message (in our case, the UploadedImage). Finally, we create the actual message for the queue and call AddMessageAsync to insert it into our Azure queue. The private GetQueue method of QueueService bears some explanation. To get access to a queue or to create one, you first have to access your storage account and use that to create a CloudQueueClient and then finally, you can use the queueClient to get a reference to a specific queue by name. Additionally, you can request that the queue be created if it does not already exist by calling the queue.CreateIfNotExists method as I have done here.
Extension Method for ByteArray
If you tried to compile now, you’d find that the SerializeToByteArray method does not exist. This is an extension method that I added, along with a complementary Deserialize method, to a static ByteArrayExtensions class. We’ll use the Deserialize method in Azure Bit #4 when we read the message from the queue and need to re-hydrate it as our UploadedImage.
The Final Result – Message in the Queue
At this point, you should be able to run the application and select an image which gets uploaded to Azure Blob Storage and you should have a message sitting in your Azure queue telling you that the image is uploaded and waiting for processing. There are a couple of ways to view what’s in your queue without having to actually fetch it. As of this writing, Azure Storage Explorer seems to have issues with byte array messages and just gives errors when I try to view them there. Probably the most convenient place to get a quick look into whether my message made it or not is via the Server Explorer directly in Visual Studio.
You can see here that my message was inserted into the queue. Additionally, you can view the contents of your Blobs in Server Explorer to verify that the image itself is in Azure Blob Storage. Go ahead and publish your latest to Azure by right-clicking on the web project in Solution Explorer and choosing “Publish..”.
In Azure Bit #4 – Adding the Azure Web Job, we will create an Azure Web Job that pulls our message from the queue and gets it ready for processing.
Originally published: 2015/06/16