During MIX11 in Vegas this past April I talked to a lot of people about DotNetNuke and the upcoming version 6 release. The one feature that seemed to get the most positive feedback was integration with SharePoint. The eyes seemed to light up as soon as I would mention that we would be integrating with SharePoint in our upcoming release and they would want to know more.
In this post I’ll go over some of the features and the reasoning behind some of the decisions that were made during design and development. Hopefully this will help you have a more in-depth understanding of this powerful tool.
When you purchase DotNetNuke 6 Enterprise you will receive a WSP SharePoint extension as part of your package, it installs a SharePoint timer job as well as a new UI section in SharePoint’s Central Administrations. This extension will allow you to select as many folders or views from any document library in any of your SharePoint portals and have them synchronized with any folder on any of your DotNetNuke portals. Here are some of the highlights.
Avoid That Firewall
One of the main use cases of this feature is for companies that use SharePoint as their document repository or Intranet and DotNetNuke as their publicly facing website. In most environments this means that the SharePoint server lives in the trusted zone while DotNetNuke is located in the DMZ and available to the public. We know that asking you to poke a hole in your firewall to allow DotNetNuke to talk to your SharePoint server is asking to much and that is why all communications between the two servers are initiated from the SharePoint server. Your DotNetNuke server will never attempt or even need to talk to the SharePoint server. Documents are always pushed from SharePoint to DotNetNuke. This means you can start using this feature without modifying your security policies as long as your SharePoint server can access your DotNetNuke server.
One of the main requirements was to allow user to filter the documents they want to transfer to DotNetNuke based on a wide range of filters and rules. After reviewing some of our options we decided to go with SharePoint’s built in views for filtering. This provided us with a number of benefits.
- You can use the Create View UI which you are likely already familiar with.
- You can use the views that you have already created and do not need to maintain two different sets of filters.
- It drastically reduced the effort required to build the filtering and related UI features. This gave us substantially more time to spend on our core features.
There are many companies with thousands or even hundreds of thousands of documents in their SharePoint servers. That's why when we sync your documents we make sure we only transfer documents that have actually been added or modified, we use many different metrics to provide the fastest differential while still guaranteeing that modified files are still synchronized. This means your synchronizations will be extremely fast and efficient even if you have thousands of documents configured for synchronization.
Many more features make up DotNetNuke’s SharePoint integration that weren’t explicitly mentioned here but I hope this post will serve as an introduction.
If you have any questions or comments please feel free to hit the comment sections.