I am building a provider-hosted app for SharePoint (O365) which is hosted in Azure. I do all of my logic through CSOM, more specifically using an MVC web project. At the moment, I have some branding logic being executed by the application after an AJAX call to a controller action.

If I have a lot of subsites in my hierarchy, this can take a very long time to execute, which is bad because, while the app will still process my request, leaving the page from which I called the action will prevent me from having any feedback concerning the completion of the task. This is of course because the state of the request is tied directly to the callback of that request in the calling page. This also means that someone could very well launch the request, refresh the page, and then launch it again, since I have no way to tell if a previous request is still executing. Furthermore, 2 different users could launch the same request, resulting in 2 simultaneous executions of that request's logic. Both situations can result in some nasty concurrent modification errors on server side artifacts.

So, what I need is to find a way to check if a certain request is already running, and if that is not the case, launch one that is stateful and asynchronous. The best example I can think of is simply SharePoint O365's own long running tasks mechanics: time intensive tasks (such as installing an app or creating a new site collection) can get launched from a page, and any subsequent refresh or access to that page will display the task as currently running, an even sometimes provide the possibility to cancel it (such as in an app install). The state will also get updated on its own (such as when the site collection creation finishes), which I am not sure is the result of client-side polling or some other mechanic I do not know about.

I have seen some solutions that seemed promising, like using Windows Services directly on Azure or this poor man's timer job, although none seem to fulfill all the requirements I listed above and/or seem complciated to implement for what I wan to do. I have a feeling that Timer Jobs could potentially help, but I wanted to have your advice on the situation.

Thanks for your input

1 Answer 1


A simple solution would be upon the first request to your long running task to write a stutus started to a persistent storage e.g. azure table storage. The key could then be username_webid. Upen subsequent request you can check if the long running task is started and maybe provide a progress if your task updates the table row.

Im surprised if the OfficePNP project doesn't include something like that as it seems very like a common requirement.

  • Since I am on SharePoint, I actually thought about persisting the request status in a List that would live in my app's own App Web. I could also look into Azure table storage to see if it is a possiblity. I would of course prefer if an existing system would take care of that for me. In that regard, I agree with you: it's something that is crucially missing, especially considering it is implemented by SharePoint itself.
    – Phil Gref
    Commented Oct 12, 2014 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.