I recently worked through a project which required us to move a Windows Service to Azure. The Windows Service was a queue listener pointed at an Azure Service Bus which received messages then processed them against other APIs or directly against a database. Most of the code was copy/paste, but I did run into a few gotcha's that took some debugging, digging, and diligent research.
We considered the following:
- Functions
- Worker Role
- WebJob
While each of those options could have worked, there differences in pricing, deployment, and complexity lead me to choose WebJobs to solve the problem. With a WebJob, you benefit from the functions living inside an existing App Service container. This consolidation worked well since the old Windows Service ran on the same Server as an app which was recently migrated to Azure. There is a WebJobs SDK package which makes converting an existing Console Application easy. This Service didn't seem to convert so easily so I just created a new project from the Azure WebJob template which comes preloaded with the SDK.
First Gotcha : Service Bus Configuration
In order for Service Bus to work, you have to go beyond instantiating the ServiceBusConfiguration.
Many of the MS docs will get you that far, but what they sometimes miss is that you need to pass the config into the new JobHost for it to register correctly.
Second Gotcha : Deserialization
BrokeredMessage's are deserialized automatically and when you call GetBody<T>, be sure to use the same type (namespace specific) that the message was serialized with.
message.GetBody<UserRoleMessage>()
Most of the time this will mean you can reference a shared library such as a nuget package containing your contracts/message classes.
Third Gotcha : Access Rights
In our Windows Service, the Queue was configured with a connection string which had access rights setup for Listen and Send - no Manage permissions. After deploying the WebJob, we would receive authorization errors saying that the client didn't have sufficient permission required to process the message. It was asking for Manage permissions? Through some digging, I found that if you don't specify AccessRights on your Function.cs methods, it will assume it needs everything. Simple fix, just add that to your ServiceBusTrigger attribute:
WebJobs are fun to work with and are a nice feature within the Azure portal. The logs are a great way to get simple visibility around when they are running tasks, how they are handling results, and help in debugging changes.