Dissecting the Work Management Service Application Part 1: Intro

SharePoint 2013 and SharePoint Online Wave 15 (from Office 365) have been here for quite some time now, and you might, or might not be aware of the Work Management Service Application (WMA) which is included in both twin-sister editions. I find it actually interesting that there is almost no information on the Internet about the WMA, other than end-user info how to use it with Out-of-the-box features.

Since I had a chance to implement some WMA-based use cases for my customers recently, I will start with a series of the blog posts – expected five to seven, where I will dissect the WMA, explain the general principles, deep dive into the APIs (yes!) and say something about the provider model.

We all know the situation that we have and keep our tasks in different systems. SharePoint tasks lists, Project tasks, Exchange tasks, tasks from different LOB and ERP systems, or personal task management systems like “Remember the Milk”. And even inside one system, tasks can be scattered throughout different locations – just think of many tasks lists in SharePoint. This can get very difficult to track and cope with. Work Management Service Application in SharePoint 2013 and SP Online gathers the tasks from different sources (aka “Providers”), and displays them in a unified task list inside the SharePoint MySite.

WorkManagementApplicationHi

What this basically means, is that SharePoint is through the refresh process aggregating tasks from the different locations in different providers, and displaying them in the MySite. Now, I used some SharePoint WMA lingo here, so let’s see some definitions.

Providers are different tasks content sources, like SharePoint, Project Server or Exchange. SharePoint WMA is based on a “provider model” architecture, what basically means, that in theory we can aggregate tasks from different providers, or write our own providers. In practice, in SharePoint 2013 WMA, there are three providers implemented: SharePoint itself, Project Server and Exchange Server. There is a provider model interface, and APIs for creating new providers, but this is not supported at this moment.

Locations are different places inside providers where the tasks can be located. Think of the multiple tasks lists across the SharePoint Farm.

Refresh is a process of aggregating tasks from different locations in different providers by a WMA.

Prerequisites

In order for Task Aggregation to work, there are few services which needs to be up and running (fully configured) in your farm:

  • Work Management Service Application (obviously)
  • User Profile Service Application
  • MySites
  • Search Service

UPA is, as in many situation, a cornerstone which must be up and running for other services. MySite is needed from one side to display the consolidated tasks, and from other side it is used as a tasks cache (I’ll come to that in one of the future blog posts where I’ll deal with the refresh process).

Search Service is used as a vehicle for the aggregation process, which actually aggregates tasks from different locations.

mytasks

OK, I believe this is enough for the intro. The next few posts will deal with:

  • WMA APIs
  • WMA Object Model
  • Tasks Queries and tasks
  • Task views
  • Pinning tasks
  • Refreshes
  • Working with Exchange Tasks
  • Custom providers (unsupported)