Mark Gerow, director of application development and business process at Fenwick & West The fact that many legal professionals consume and interact with most, if not all, of their digital content in Microsoft Outlook cannot be overstated. It follows that if you want to deliver data to your law firm community, do it through Outlook.
This article describes a method for presenting temporal data in Outlook calendars. With minor modifications, however, the technique described may be used to present Outlook data from sources as varied as SharePoint, SQL Server, XML, web services, or Excel. All of this relies on a protocol first released by Microsoft in 2003 called STSSYNC.
STSSYNC is a protocol originally introduced for SharePoint 2003 that allows calendars, contacts, and tasks to be synchronized between SharePoint and Outlook. When you choose the "Connect to Outlook" option in SharePoint 2003 or later you invoke the STSSYNC protocol handler in Outlook. The protocol essentially does two things:
1. It provides Outlook with information about a calendar, contact, or task list in SharePoint to be displayed in Outlook.2. The protocol causes Outlook to periodically synchronize data with a source list and to update a local copy of that list's data.
SYNCHRONIZING A SHAREPOINT TASK LIST TO AN OUTLOOK CALENDAR
In my experience, a calendar is the preferred means for viewing date and time oriented data — very few people know about, let alone use Outlook tasks. While out-of-the-box SharePoint can synchronize a task list to an Outlook task list, the scenario we'll explore is synching items from a SharePoint task list to an Outlook calendar. To accomplish this we'll need a custom web service that will respond to Outlook's data requests.
Because the STSSYNC protocol has been poorly documented by Microsoft, very little use has been made of it beyond the built-in SharePoint connectors. Most articles by Microsoft provide arcane descriptions of how it can be used to connect arbitrary data sources to Outlook, but seem to assume it will only be of interest to commercial software vendors and not to IT professionals.
The STSSYNC out-of-the-box implementation has real but limited usefulness. It can connect a SharePoint calendar, contact, or task list to its Outlook counterparts, but does not recognize SharePoint views and so cannot limit the synchronization to a subset of those items. Nor can the standard implementation link anything other than SharePoint calendar, contact, or task entries to their corresponding type in Outlook.
To realize STSSYNC's full potential for connecting disparate data sources we need to crack it open and get an understanding what is actually going on under the hood.
This article builds on two previously published articles. The first was published in 2004 by Stephen Toub, a Microsoft engineer, in which he described how to create a general purpose content provider for Outlook using the STSSYNC protocol. The second article, published by P. Creehan in 2006, builds on the first and updates it for Outlook 2007 and 2010. Neither article addressed the question of creating custom connectors for SharePoint lists, a topic we'll cover in this article.
The key insight of Toub's article is that Outlook expects the list provider to call the SharePoint "Lists.asmx" web service, and thus any web service that mimics Lists.asmx will also be recognized by Outlook, regardless of the source of the data it returns. Some of the data sources referenced in his code are no longer functional and have been removed from the .cs files here attached. The general framework presented in Toub's article, however, is just as useful today as it was when first written.
Creehan's article updated Toub's Lists.asmx design to work with Outlook 2007 and later. This update was necessary because Toub did not implement the Lists.asmx interface in its entirety, and while Outlook 2003 did not require a fully implemented interface, Outlook 2007 and later do.
The code from these two articles, along with a few modifications, forms the basis for a connector to display a SharePoint task list in an Outlook calendar. The steps to install and test all of the necessary code are described below.
INSTALLING AND TESTING THE CUSTOM TASK LIST CONNECTOR
Prerequisites. To follow my instructions below you will first need to download and install the source code provided by Toub, and the modifications provided by Creehan. Once you have a working site combining both authors code you are ready to add the custom task list connector.
1. Make sure you have access to a copy of Visual Studio 2008 or later.
2. Download and extract the sample application from the Toub article here.
3. Open the website extracted in step 2 above in Visual Studio (note that you will be prompted to update the project format to the current version of Visual Studio).
4.Make the modifications to the "WssListResponse.cs" class as described in the Creehan article.
Additional Modifications. In addition to the modifications required in step 4 of the preceding section, you will need to make two additional changes to get the sample application working with a SharePoint task list:
5. Add the "TaskListCalendarProvider.cs" class to the "Sample Providers" folder.
6. Modify the "CalendarProviderSettings.cs" class to remove the reference to configuration settings in web.config that won't work with ASP.NET 3.5 or that refer to sources that no longer exist. In addition you will add a reference to the new "TaskListCalendarProvider" class (see the modified CalendarProviderSettings.cs).
Note: you will need to modify line 51 of the above C# class to specify your SharePoint site and task list name.
7. Add a reference to the SharePoint Lists.asmx web service to the project and name it "ListsService."
Figure 1: Adding a reference to the Lists.asmx web service.
TESTING
At this point our modified Outlook calendar provider should run in Visual Studio. To test it, simply press F5 to start the application. You should see a page that looks like the following:
Figure 2: Home page listing installed calendar providers.
Clicking on any of the icons in the "View Events" column should display a list of events for the corresponding provider. For example, clicking on the "SharePoint 2010 Task List" view-events link displayed the following on my computer (results will of course vary depending on the data entered into the source SharePoint task list).
Figure 3: Viewing source data from a SharePoint task list.
Now, link the task list to Outlook.
Figure 4: Initiating the link.
The underlying link behind the highlighted icon is:
Notice the highlighted segments of the URL:
• "Stssync" tells Windows that Outlook should process this link;• Calendar indicates that this list will be synched to a calendar, rather than a task or contact view;
• http%3a%2f%2flocalhost%3a33879%2fodc_OLOutlookCalendarSample is the encoded URL of the custom provider site, not the underlying SharePoint site;
• %7B5996db53%2Dae0c%2D45be%2Db4c1%2D86ccbf61b0a7%7D is the encoded unique ID (GUID) of the TaskListCalendarProvider instance (each connection in Outlook must have a unique ID).
When you click on the link, you will see two dialogs in succession. First, you'll be asked to allow your task list provider to open Outlook.
Figure 5: Allowing our web service to open Outlook.
Click the "Allow" button to proceed. Next, you'll be asked wither it is OK to connect Outlook to this specific SharePoint list.
Figure 6: Confirming the link in Outlook.
Click "Yes". Finally, if all works as expected, you will see the linked calendar in Outlook:
Figure 7: The linked task list displayed in Outlook.
After successfully registering your linked list, adding, deleting, or changing tasks in SharePoint will automatically be reflected in the synchronized calendar in Outlook.
WHAT'S GOING ON UNDER THE HOOD?
Behind the scenes clicking on an STSSYNC link causes Outlook to add an entry to your linked SharePoint lists collection. You can see your current linked lists by opening the Account Settings dialog and navigating to the "SharePoint Lists" tab.
Figure 8: Outlook account information page.
Figure 9: Dialog showing linked SharePoint lists in Outlook.
Figure 10: SharePoint List Options dialog
The definition above contains enough information to tell Outlook the URL and name of what appears to be a SharePoint site and list, but is actually our custom web service. Whenever Outlook refreshes the synched list it will append "/_vti_bin/Lists.asmx" to the site URL and call the "GetListItems" method of that web service for the specified list (represented in Outlook by the GUID provided in the original STSSYNC URL). Our provider's "Application_BeginRequest" event handler in the Global.asax.cs file will intercept the call from Outlook and reroute it to "OutlookCalendar.asmx", where our SharePoint task list provider will be called. Next, our provider queries SharePoint to return all items for the source task list and formats the results to conform to an Outlook "event". Finally, Outlook receives the data returned from our web service and maps it to entries in the synchronized calendar.
PRODUCTION
In the example above we ran our custom calendar provider from within the Visual Studio environment. In this development configuration the synchronization process will only succeed when Visual Studio is running because the URL sent to Outlook includes a port assigned dynamically by Visual Studio. When you're ready to go live you'll need to install your application on a production IIS server that is accessible to all of your Outlook users.
OTHER SCENARIOS
The STSSYNC protocol requires a web service that behaves like the SharePoint Lists.asmx web service. As long as that requirement is met, any data can be returned assuming it's formatted correctly. For example, data stored in SQL Server (such as that from Aderant's CompuLaw docketing application), web services (e.g., LexisNexis Interaction), XML, or Excel all could be displayed through Outlook when appropriately formatted. This opens up many opportunities to present actionable data to users who may use Outlook as their primary (if not sole) data access tool.
CONCLUSION
Although Microsoft has done a poor job of explaining the architecture of the SYSSYNC protocol, a bit of research will show that it provides a way to link Outlook to SharePoint via a call to the Lists.asmx web service. Toub (2004) showed that a custom web service masquerading as Lists.asmx allows any source of data with a time dimension can be displayed as an Outlook calendar. Creehan (2006) provided updated source code to address the more stringent requirements in Outlook 2007 and later. Combining Toub's and Creehan's code forms the basis of a general purpose web service to present any time-based data, including that stored in a SharePoint task list, as an Outlook calendar.
Fenwick & West uses a custom web service and the STSSYNC protocol to make task lists more visible and usable for legal professionals. IT no longer has to coax busy individuals to a SharePoint site to manage their tasks. Rather, task data is represented in a tool they use throughout the day: Outlook.
A browser or device that allows javascript is required to view this content.
Mark Gerow is director of applications and business process at Fenwick & West. Email: mgerow@fenwick.com.You must be signed in to comment on an articleSign In or Subscribe">
No comments:
Post a Comment