Creating Azure WebJobs To Parse Message From Azure Storage Queues

• Login to portal.azure.com
• In the dashboard click Create a resource
  
• Scroll down the list and click on Storage
  
• Click on Storage Account
  
• Fill in the details,
  • Choose subscription
  • Select the resource group or create a new resource
  • Choose the name for storage. It must be unique
  • Choose the desired region
  • Leave the other options as default and click Review+Create
    
• After the validation is passed click Create
  
• It will take some time and the resource will be deployed successfully.
• After the resource is created, go to the resource and click on Queues
  
• Add a new Queue
  
• Add a name and press OK
  
• Click on Access Keys and copy the connection string
  

Running the WebJob

Now go back to the WebJob project and make some changes.

• Go to the app. config file in the project directory and paste the connection string in the following,
  • AzureWebJobsDashboard
  • AzureWebJobsStorage
  • The Code below is automatically generated by the project, you don’t have to write it.
    
• Change the name of the queue in the cs file with the name of your queue.
• public static void ProcessQueueMessage([QueueTrigger(“messages”)] string message, TextWriter log)
  
• Run the app, you will see the following console
  

Sending Messages to trigger the WebJob

1. Now go to the portal, and navigate to the queues.
2. Click on Add Message
   
3. Type anything a click OK
   
4. Now go back to the console and you will see the new Message there.
   

And that’s how you can use WebJob SDK to receive upcoming messages from the storage queue. Similarly instead of displaying a simple message you can do a heavy background task based on any trigger.

Working with Bindings and Triggers

We've seen a basic example of just reading a string of the queue and writing it out to the console, but let's take this a step further. I've created a User class here in my WebJobs project that just has a Name, an ID, and a Gender. And what I want to be able to do is get that particular user off the queue.

• Create a new User class as follows

  class User
  {
      public int ID { get; set; }
      public string Name { get; set; }
      public string Gender { get; set; }
  }
  

  
• So if we go back to our Function, we're going to change this from a string message to a User message. And that's going to cause the WebJobs SDK to try to deserialize some JSON that we're going to put on the queue into this class.
• Change the message from string to User
• The Code below is automatically generated by the project, you don’t have to write it.
  
• Create a Blob in the same way as a queue in the Azure portal.
  
  
• Now I'm going to add another thing here as an output, and I'm going to put a Blob output on this. Now for the blob, we have a variety of different types we can actually use here for the parameter, like any azure storage. This is a binding, a queue is a trigger, which means it will initiate this. This is a binding, meaning that we're going to just have some parameter here, and this binding is going to take care of connecting that up to the resource.
• Now go to the functions. cs and change the ProcessQueueMessage method as follows,

  public static void ProcessQueueuMessage([QueueTrigger("messages")] User message, [Blob("incomingusers/userlog.txt", FileAccess.Write)] TextWriter bidWriter, TextWriter log)
  {
      bidWriter.WriteLine($"New User added {message.ID} with Name of {message.Name} Having gender {message.Gender}");
      log.WriteLine(message);
  }
  

  
• And now that we have that, if we go back to our portal, remember, we can go to our queue, view that, and create a new message.
• Create a new message as a JSON user object and click OK.

  {
    "id": 1,
    "name": "David",
    "gender": "Male"
  }
  

  
• Now if we go look at our container over here and view the container, you can see there's my userlog.txt.
  
• If I click that, download it, and open it, you will see the data we stored in this.
  
  
• If we continue to send messages, then we'd write those to that log file. So it's a very powerful model with these triggers and bindings that allows us to write less code, to take advantage of event-based processing.

Similarly, instead of Blob storage, we can use tables to store our data.

Use Cases

• For running background tasks based on some triggers
• Can be used with websites unlike Azure Functions
• Can be used to write data to DB based on an event
• Can also be used to run continuously in the background