As mentioned in a previous article, SharePoint development is moving in a whole new direction. The vast majority of the solution-based abilities have some form of representation in the App Model.

There are, however, some notably missing functionalities. One such functionality is the infamous timer job. In previous versions of SharePoint, the timer job was used for a variety of purposes, ranging from data cleanup to asynchronous tasks. With its disappearance, developers will have to get creative to enable similar functionality. To paraphrase Cher’s 1998 hit song, Do You Believe in Life After Timer Jobs?

The problem
As many who have created third-party integrations can attest, we are living in an increasingly asynchronous world. It is unreasonable to think that every function can be performed in a single request, particularly in the collaboration and publishing spaces. Additionally, user expectations demand speedy interfaces regardless of work being performed behind the scenes. Without some form of asynchronous processing, those goals are virtually unachievable.

The resolution(s)
While asynchronous processing through a service layer and JavaScript is certainly possible, there will always be some sort of server-side code involved when discussing asynchronous processing. These solutions will assume that server-side code is part of your Remote Web.

Back to basics
In its most basic form, asynchronous processing is nothing more than each system calling the next in line when processing is completed. Since that is the case, asynchronous processing in SharePoint simply requires that the back-end system be aware of and be able to communicate with the remote Web.

The inherent problem with this method is the fact that your back end likely does not have SharePoint credentials. Leaving the endpoint exposed, particularly if it is available outside the firewall, is a large security risk and explicitly against the app requirements set forth by the Office Store.

There is, however, a simple way to both secure the endpoint and maintain compliance with the Office Store requirements. Digital Signature Algorithm (DSA) is a form of cryptography that allows you to generate signatures based on a byte array. That signature can then be appended to the URL and used to verify that the request is from a valid caller and has not been tampered with en route. Therefore, you are authenticated with the Public/Private key pair and you can use an app-only context to gain access to SharePoint.

Traversing the firewall
With the emphasis on the cloud growing, the firewall begins to add some complexity to the basic asynchronous design described above if one of the systems happens to reside outside the firewall. If exposing the remote Web to the Internet is not an option, a Windows service or other scheduled task system is almost certainly required to complete asynchronous processing.

There are two basic possibilities for how to implement this within a Windows service. While both methods include polling, one can be thought of as a “push” and the other as a “pull.” Regardless of which method you choose, it should be behind the firewall and have the ability to make DSA signed calls to the remote Web as described in the previous section.

When implementing a “pull” Windows service, the system will maintain a list of known incomplete operations and poll the third-party system for the completion of those items. The major piece of functionality missing in this method is the ability to create or update an item outside of SharePoint and have the information flow into SharePoint. This could be severely limiting for functionality such as a lead-generation system, where an external form is filled out and the lead is managed in SharePoint.

In the “push” implementation, a queuing system, such as a Windows Azure Service Bus queue, is used. Since Azure queues are used exclusively via outbound HTTPS calls, there is no problem with the firewall. In this method, the processing application would place a message on the queue using a predefined contract, and the Windows Service would be polling the queue for new items. The benefit to this method is that the processing application can put any item out onto the queue, so there is no limitation for externally created or updated items as there is with the “pull” method.

The question remains: Do you believe in life after timer jobs? The timer job idea is not dead, it is just simply not SharePoint. There are a number of ways to develop similar functionality, the ones listed here are just a few. If you have additional ideas, tweet me @brprigge with #IBelieve.

Brian Prigge is SharePoint architect at video data platform provider Ramp.