CODEWITHSUNDEEP
asp.netwcfasynchronous
RKP
RKP

Reputation: 5385

Dealing with Long running processes in ASP.NET

I would like to know the best way to deal with long running processes started on demand from an ASP.NET webpage.

The process may consist of various steps (like upload files to the server, run SSIS packages on them, execute some stored procedures etc.) and sometimes the process could take up to couple of hours to finish.

If I go for asynchronous execution using a WCF service, then what happens if the user closes the browser while the process is running, how the process success or failure result should be displayed to the user? To solve this, I choose one-way WCF service calls, but the problem with this is I need to create a process table and store the result (and error messages if it fails in any of the steps and which steps have completed successfully) in that table which is an additional overhead because there are many such processes with various steps that the user can invoke from the web page and user needs to be made aware of the progress (in simplest case, the status can be "process xyz running") and once it is done, the output needs to be displayed to the user (for example by running a stored procedure).

What is the best way to design the solution for this?

Upvotes: 0

Views: 2530

Answers (3)

Tim Rogers
Tim Rogers

Reputation: 21713

As I see it, you have three options

  1. Have a long running page where the user waits for the response. If this is several hours, you're going to have many usability problems, so I wouldn't even consider it.
  2. Create a process table to store the results of operations. Run service functions asynchronously and delegate logging the results to the service. There can be a page that the user refreshes which gets the latest results of this table.
  3. If you really don't want to create a table, then store all the current process details in the users' session state, and have a current processes page as above. You have the possible issue that the session might timeout, or the web app might restart and you'll lose all this.

I can't see that number 2 is such a great hardship. You could make the table fairly generic to encompass all types of processes: process details could just be encoded as binary or xml and interpreted by the web application. You then have the most robust solution.

Upvotes: 2

Pablo Santa Cruz
Pablo Santa Cruz

Reputation: 181280

I think you are in the right track. You should run the process asynchronously, store the execution somewhere (a table), and keep status of the running process in there.

Your user should see a pending display label while the process is executing, and a finished label with the result when the process finished. If the user closed the browser, she will see the result of her running process next time she logs in.

Upvotes: 1

Jagmag
Jagmag

Reputation: 10356

I cant say what the best way would be but using Windows Workflow Foundation for such long running processes is definitely one way to go about it.

You can do tracking of the process to see what stage it is at, even persist it if you have steps where it is awaiting user input etc.

WF provides a lot of features out of the box (especially if your storage medium is SQL Server) and may be a good option to consider.

http://www.codeproject.com/KB/WF/WF4Extensions.aspx might help give you some more insight into the same.

Upvotes: 1

Related Questions