Keivan Beigi, of DotNetNuke (DNN) posted in his blog that the one new feature that is receiving the most positive feedback during the MIX11 in Vegas, was the SharePoint Connector. Has this new, highly anticipated DNN 6.0 feature lived up to its hype?
What is the SharePoint Connector
First, a quick introduction to SharePoint and the Connector. SharePoint is regularly implemented as an Enterprise Content Management (ECM) solution, either as an intranet or as an extranet with known visitors. It requires an Internet Connector to deliver a public facing internet website solution. On the other hand, DNN is a much more cost-effective public facing Content Management System (CMS) solution with a greater degree of flexibility due to its open source deliverable.
As the name suggests, the SharePoint Connector is DNN’s feature for integration with SharePoint. Installing this feature into SharePoint delivers a one-way communication from SharePoint to DNN. In SharePoint terminology, the Connector is a timer job that can be configured to run on a specified schedule, via a Windows Communication Foundation (WCF) web service. It copies over files within a SharePoint document library to a folder within a DNN portal.
The Good
The SharePoint Connector provides a first-ever integration attempt between DNN and SharePoint. The timer job schedule is extremely customizable, and can be performed as often as every minute, or as little as every month. The logging for the timer job is excellent, as DNN’s logging usually is. However, this feature has gone one step further with storing the log, not only in DNN, but also in SharePoint. The log describes each file transferred, its success/failure status and reason. Additionally, the SharePoint Connector logging has a status filter to only display failed transfers, and can send an email notification for each failed transfer.
The Connector utilizes the SharePoint folder and view structures to transfer content. That is, all files within a certain SharePoint folder or view can be transferred to DNN. Thus, users can utilize the filter capability built into SharePoint views to transfer only certain files into DNN. The files transferred take into account the security configuration on DNN’s side. That is, if certain file types or sizes are not allowed into DNN, the transfer of that file will fail, and the timer job will continue to the next file marked for transfer.
The transfer of files is done via port 80 but default, but the WCF configuration allows for changing of several of these options, such as the port, the maximum file size allowed, etc. The configuration of the file transfer allows for selecting document libraries within a site collection. This allows for greater visibility of document libraries, than if this configuration were setup for sites.
The Bad
Shaun Walker, CTO, and co-founder of DNN stated that this is a Phase 1 for the SharePoint Connector solution. Hence, there are several key features left out from the current version of the connector. The most important one being that the connector is created for the last version of SharePoint 2007, and not the latest version, 2010. It also does not support the cloud version of SharePoint with Office 365. This is anticipated to be available Q2 2012.
The SharePoint file transfer can only be controlled from the Central Administration. This access is generally restricted to more technical folk, such as the network administrators of the company. In which case, content owners will have more difficulty transferring their content into DNN.
The connector duplicates documents from SharePoint, so that there are two copies of the same documents. This is not only a waste of space, especially in the case of larger documents, but also, changes to documents in DNN will be overwritten by the transfer. It may be difficult to distinguish and keep track of the documents that will be overwritten versus those managed in DNN.
The connector is only restricted to document libraries, and not the foundation of SharePoint content, lists. The documents transferred additionally, does not transfer the SharePoint permissions, metadata, versions or workflows.
Within the transfer configuration, only content from one document library can be selected for transfer into DNN. To transfer all documents from the entire SharePoint site or site collection, transfer schedules would need to be setup for each document library.
The Foreseeable Future
While the SharePoint connector is a great start to an integration of SharePoint and DNN, it has a ways to go before ensuring complete integration of these technologies. Shaun Walker has stated a possibility of the release of the connector for SharePoint 2010 as early as the Spring of 2012. However, DNN also needs to consider a release of the SharePoint connector for the cloud options of SharePoint.
Additionally, duplication of content in two systems is not the best solution for integration. Instead, a view should be setup to display content from SharePoint into DNN, utilizing the SharePoint API. This will enhance the difference between the content maintained in SharePoint versus that maintained in DNN.
For now, however, if you have or are considering SharePoint 2007 as your intranet ECM and DNN 6.x as your internet website CMS, the SharePoint Connector provides an excellent integration option. For information in configuring and deploying the SharePoint connector, refer to my next article:
Deployment and Setup of the DotNetNuke 6.0 SharePoint Connector