by
Mark Jones
| Dec 27, 2011
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.
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 seperate 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.
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!
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.
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.