This is the second post in a series about Durable queue in Azure Service Fabric using WebJobs:

• Part 1: Introduction to Asynchronous Operations
• Part 2: Web API

Now let’s create another stateless service that will host the Web API. I used default Visual Studio template called “Stateless ASP.NET Core”. You can find how it configures Kestrel as an underlying application web server here.

This service/Web API will have a controller responsible to convert requests into queue messages and enqueue them. For the sake of demonstration, this would be an incidents management system (IcM):

• Read requests go through cache. High volume can be handled. Cache is populated from storage during cold start.
• Write requests go though cache as well and update it, then update storage. Implemented using HTTP verb PATCH to better support concurrency.

namespace DurableQueueSample.StatelessWebApiService.Controllers
{
  public sealed class IncidentController : Controller
  {
    public async Task Get(Guid incidentId)
    {
      var actorId = new ActorId($"GET+{incidentId}", Uri("fabric:/DurableQueueSampleApplication/ActorStatefulService");
      var actor = ActorProxy.Create(actorId);
 
      var incident = await actor.GetIncident(incidentId);
      return Ok(incident);
    }
 
    public async Task Patch(Guid incidentId, string name, string value)
    {
      var patchId = Guid.NewGuid();
      var patch = new IncidentPatch(patchId, incidentId, name, value);
 
      var messageContent = _jsonConverter.Convert(patch);
      await queueClient.EnqueueClient(queueName, messageContent);
 
      var url = _urlBuilder.BuildUrl(StatusController.GetStatusRouteName, new { patchId })!
      return Accepted(url);
    }
  }
}

Note that ASP.NET Web API doesn’t have a built-in method to return 202 Accepted so you would need to write yours own extension method, However ASP.NET Core does have a collection of them. We would need the one which accepts Uri without object.

Method Get() routes the request directly to the stateful service that hosts the actors that process the requests. While method Patch() enqueues the request, doesn’t wait for its processing to be completed, returns the control immediately after Azure Queue client acknowledges message reception. This way client browser also doesn’t wait, can check the status by following the provided url, i.e. /status/?patchId={patchId}. However, other clients, if try to retrieve the incident before the patch has been applied, might see outdated information. This the price for update requests asynchronous processing.

Here’s how the queue trigger function looks like:

namespace DurableQueueSample.StatelessWebJobsService.Functions
{
  public sealed class IncidentPatchFunction
  {
    [Singleton("{IncidentId}")]
    public async Task Handle(
      [QueueTrigger(queueName)] IncidentPatch patch,
      TextWriter dashboardLogger)
    {
      var actorId = new ActorId($"PATCH+{patch.IncidentId}", Uri("fabric:/DurableQueueSampleApplication/ActorStatefulService");
      var actor = ActorProxy.Create(actorId);
      await actor.UpdsteIncident(patch.IncidentId, patch.PropertyName, patch.PropertyValur);
    }
  }
}

Next time: we’ll create another, reliable actor service which will host the actors that handle operations on the incidents.