Pattern for long running tasks invoked through ASP.NET

I need to invoke a long running task from an ASP.NET page, and allow the user to view the tasks progress as it executes.

In my current case I want to import 开发者_运维问答data from a series of data files into a database, but this involves a fair amount of processing. I would like the user to see how far through the files the task is, and any problems encountered along the way.

Due to limited processing resources I would like to queue the requests for this service.

I have recently looked at Windows Workflow and wondered if it might offer a solution?

I am thinking of a solution that might look like:

ASP.NET AJAX page -> WCF Service -> MSMQ -> Workflow Service *or* Windows Service

Does anyone have any ideas, experience or have done this sort of thing before?

---

I've got a book that covers explicitly how to integrate WF (WorkFlow) and WCF. It's too much to post here, obviously. I think your question deserves a longer answer than can readily be answered fully on this forum, but Microsoft offers some guidance.

And a Google search for "WCF and WF" turns up plenty of results.

---

I did have an app under development where we used a similar process using MSMQ. The idea was to deliver emergency messages to all of our stores in case of product recalls, or known issues that affect a large number of stores. It was developed and testing OK.

We ended up not using MSMQ because of a business requirement - we needed to know if a message was not received immediately so that we could call the store, rather than just letting the store get it when their PC was able to pick up the message from the queue. However, it did work very well.

The article I linked to above is a good place to start.

---

Our current design, the one that we went live with, does exactly what you asked about a Windows service.

• We have a web page to enter messages and pick distribution lists. - these are saved in a database
• we have a separate Windows service (We call it the AlertSender) that polls the database and checks for new messages.
• The store level PCs have a Windows service that hosts a WCF client that listens for messages (the AlertListener)
• When the AlertSender finds messages that need to go out, it sends them to the AlertListener, which is responsible for displaying the message to the stores and playing an alert sound.
• As the messages are sent, the AlertSender updates the status of the message in the database.
• As stores receive the message, a co-worker enters their employee # and clicks a button to acknowledge that they've received the message. (Critical business requirement for us because if all stores don't get the message we may need to physically call them to have them remove tainted product from shelves, etc.)
• Finally, our administrative piece has a report (ASP.NET) tied to an AlertId that shows all of the pending messages, and their status.

---

You could have the back-end import process write status records to the database as it completes sections of the task, and the web-app could simply poll the database at arbitrary intervals, and update a progress-bar or otherwise tick off tasks as they're completed, whatever is appropriate in the UI.