DocRead Architecture Design

DocRead for SharePoint is the only policy management software that integrates straight into SharePoint and allows compliance professionals to distribute and track their policies and procedures.

DocRead can distribute, process, track and report on reading tasks for 1000’s of end users at a time. To cope with volume an enterprise architecture was designed and implemented. This article gives a quick overview of the main components in that architecture.

Farm Level Solution Packages

When DocRead is installed it adds 3 Farm-Level Solution Packages (WSPs), as follows:

• Collaboris.Readership.Solution. Deploys binaries and features required for DocRead.
• Collaboris.JQuery.solution. Deploys JQuery libraries.
• Collaboris.Readership.Charting.Solution (2010 only). Deploys the DocRead Charts.

Security

DocRead re-uses exactly the same security model that is configured for the SharePoint Web Application. For example, if a customer is using claims-based authentication with Active Directory, DocRead will simply use that to authenticate and authorise access to DocRead application pages.

DocRead also uses two SharePoint Groups to specify the DocRead Administrators and Publishers (users who can distribute documents with DocRead). To configure these a user with 'Full Control' will need to do this.

DocRead web parts are also installed - at a customers discretion - by a user with 'Contribute' permissions on a web part page.

All of the Reading Tasks, scheduling information and Reading Receipts are stored in a separate SQL Databases stored and maintained on a customers site (see section on 'DocRead Data' below).

One final point to mention, DocRead doesn't require any connection to the Internet or to Collaboris Servers. The installation is entirely stand-alone inside an organisations internal Network and can be protected by a Firewall if required. (Although, the SharePoint Servers still need access to the DocRead databases).

SharePoint Features

DocRead utilises SharePoint Features at all levels in the SharePoint hierarchy. This means that the administration can be managed and delegated all the way from Farm to individual Document Libraries, giving an organisation maximum control over where and who can use DocRead.

Notification Scheduler

The Notification Scheduler runs as a Windows Service and is responsible for sending emails to users who have reading tasks assigned, overdue or completed. The scheduler can be installed on a standard Windows Server and doesn't require SharePoint. To understand the reasons behind the design of the Notification Scheduler, please read 'Why don't we send DocRead e-mails using SharePoint?'

DocRead Data

DocRead stores all of its data in a separate SQL Server database, not in one or more SharePoint Lists. We have taken this approach for a few reasons :

• Performance - As we needed to build DocRead to scale to hundreds of thousands of reading tasks (and associated certificates), we knew that this would be well beyond the boundaries of a SharePoint list.
• Availability of data - One awesome feature within DocRead is its ability to show a user their reading assignments across the web, site collection and web application. For example, it's really easy to place a DocRead web part onto the MySite and display a users' reading tasks. This means that if a user is required to read a document that is stored in the Collaboration Web Application and also those stored on the corporate intranet then this all works with no extra effort.
• Security - As all the data is stored in an isolated SQL database this adds one extra level of protection.
• Future-Proof - If you ever decide to move away from SharePoint, by storing proof of when your employees read your policies in a totally isolated DB you won't lose this data when you remove SharePoint.
• Reporting - As the DocRead database is all in SQL Server this makes reporting much easier and faster than if it were stored in SharePoint lists. As the data is centralised, its very simple and efficient to bring information about many documents and users regardless of where they are stored n the Farm topology!

SQL Databases used

For performance, scalability and security reasons DocRead requires two databases. The databases are created from a purpose built screen in Central Admin. Administrators can control, server and naming. Databases are as follows :

• DocRead Database. Stores tables related to the management of tasks, users, documents and receipts.
• DocRead Scheduler. Stores scheduling information to support sending emails.

Logging

DocRead processing information and errors are saved to the DocRead database. This information is exposed via a page in Central Administration for diagnosis. In addition to this, the Notification Scheduler can be configured to log to a file on the server where it is installed.

Reporting

DocRead uses an elegant enterprise level reporting solution built by Telerik. Since version 1.5, all of our reports are authored using 'Telerik Report Designer' and reside on the file-system of each WFE. Now that we have moved to this approach, in a future release, we will be releasing further tooling and guidance on how customers can also author their own reports using Telerik Report Designer.

Please Note: If you already use an earlier version of Telerik Reporting, then installing DocRead will automatically upgrade the reporting components to the version it uses (usually the latest). If you do not wish this to happen, then the reporting functionality is optional.

Installation

DocRead is installed via an MSI package, which essentially adds and deploys 3 Farm-level Solution packages (WSPs) to your SharePoint farm.

Scheduled Timer Jobs

DocRead does the majority of its processing in the background, this ensures that we have minimal impact on your Web Front Ends. To support this 4 SharePoint Timer Jobs are provisioned, as follows:

• DocRead Audiences Sync Job. Runs every 4 hours. Synchronises DocRead Audiences, with SharePoint Audiences and groups.
• DocRead Readership Processing Job. Runs every 2 hours. Creates and Deletes Tasks in the DocRead database.
• DocRead SharePoint Sync Job. Runs Daily. Notifies DocRead about any deleted Sites, Libraries or documents.
• DocRead Worker Job. Runs every 15 minutes. Notifies DocRead about changes in a particular sub site. (Only has anything to do if someone chooses ‘Synchronise site tasks’ from the site).

The intervals with which Timer jobs can run are configurable by a SharePoint Admin to suit your needs.

User Interface

All Administration Pages are developed as standard SharePoint Application Pages. Also, a set of web parts can be placed within any web part zone. JQuery libraries and AJAX calls are utilised to offer slick performance and usability.

You may also find this article interesting, which covers some of these issues : How does DocRead differ from workflow

To read in-depth, step by step User Guides, please visit the Learning Centre.