0

I am trying to find the appropriate way to setup a long running api task using Asp.Net Web API. The tasks I am running could take up to 3 minutes to complete. I have found several links such as QueueBackgroundWorkItem or this post here but am unsure on a few things.

Question:

So I guess I am most confused about the overall structure for this and the appropriate way to even go about it. My task seems to long to use a QueueBackgroundWorkItem but I don't want to implement a fire and forget API call.

What I would like:

I would like to be able to fire a web API task, return a OK response, but continue to poll for the returned data after firing the task. I just have no idea how to even begin implementing a queue system or even how to poll for that data from the Web API.

Other Information:

  • Using .Net Framework 4.5.2
  • Front end is asp.net MVC web app
  • Web API method is called through an AJAX call on my front
  • Currently send about 30 requests at a time with a long time out. Then as they return I update my UI with returned data from the API.

My current code:

This is what I am doing now which works fine. The only issue is I have to set the timeout to some ridiculous amount on my UI application. Which is why I am trying to find the correct way to implement a long running task/polling/queueing mechanism for long running tasks. Overall just unsure what is out there for solving the problem below.

public NewProjectLogDTO CreateProject(string modelNumber, string orderName = "")
    {
        try
        {
            string EplanPort = ConnectToEPLAN();
            SetContext(modelNumber, orderName);
            AddSchematicToDB(modelNumber, orderName); //accesses DB
            ExecuteCreateProjectAction(); //Really long running task about 3 minutes long
            DecreasePortCounter(EplanPort);
            AddMacrosToDb(modelNumber, orderName); //accesses DB
            return GetNewProjectLogFromContext(modelNumber,orderName); //return data from long running task
        }
        catch (Exception ex)
        {
        }
    }
Selthien
  • 1,178
  • 9
  • 33
  • 1
    You want to offload the work to an external process. There are tools available for you to use. Check out [Hangfire](https://www.hangfire.io/). You could use [SignalR](https://dotnet.microsoft.com/apps/aspnet/signalr) to return an update when there is one back to the client. Do not try to have the web process execute the long running task, web requests should be short lived. – Igor Sep 23 '20 at 18:16
  • Yeah I was actually thinking of using SignalR for the communication aspect. Hangfire looks interesting. Is the Pro version worth the cost? Not sure if I really need batching capability. Could you point me to some articles on how to use SignalR with a web api and MVC? Was having trouble finding any good articles over it. – Selthien Sep 23 '20 at 18:22
  • Sorry, my helpfulness stops after the comment above. I can't tell you about what version to get or point you to material for implementing SignalR outside of the link I had already shared. – Igor Sep 23 '20 at 18:26
  • You do not need to pay for Hangfire. There are plenty of ways to code up your own automated task, such as a Windows Serice. One easy and free solution is to use TopShelf which makes it super easy to turn a basic console app into a constantly running Windows Service. http://topshelf-project.com/ – Casey Crookston Sep 23 '20 at 19:42
  • @CaseyCrookston Currently what we do is use console apps for constantly running / scheduled tasks. How could I pass the data for the long running task to the windows service from my web api project? How would my API project be notified when the task is complete? Would I have to do all this through statuses within a database and query it every so often? – Selthien Sep 23 '20 at 21:39
  • 1
    @Selthien this is a perfect question to ask over at https://softwareengineering.meta.stackexchange.com. This site is for very specific code questions. The Software Engineering site is moe for broad how-do-I-architect-my-app type questions. – Casey Crookston Sep 24 '20 at 15:33
  • 1
    You sometimes see this as a number of API endpoints. You initiate the job and rather than returning "200 OK", you will return a "201 Created". That resposne may contain an ID or a URL (or both!) which you can use to enquire about the status of that job. The response from that endpoint might be "OK" with a message of "running" or "processing" and eventually "finished" or "errored". If you then need to return data a final endpoint might be called to obtain all the information. This means each call is fairly short, and you do not need to have long time-outs on the requesting service. – Craig H Sep 25 '20 at 11:05

0 Answers0