Note: Download artifacts discussed in this article from Here.
Please note that this article applies to SharePoint 2010 On-premises. Architecture discussed in this article won’t supported in the SharePoint 2010 Online but it can be easily adapted in the SharePoint 2013 Online with new support for custom managed properties. Although architecture discussed in this article can be easily applied in SharePoint 2013 On-Premises, there is better option with Cross-Site Publishing and Content by Search with the Enterprise CALs.
Last October I had demonstrated No-code Search solution at SharePoint Fest Chicago to build corporate knowledge center showcasing how you can rollup policy documents from different departments designed as Site Collections from your organizations to centralized location in SharePoint 2010 On-Premises farm. I had promised attendees that I will post detailed blog entry on how to build no-code Policy Center and architecture behind it. Although it took me almost 6 months to complete, I really hope it’s not too late.
Here is the detailed step by step blog entry on how to design policy center. Alternatively you can download 50 page visual case study from sky drive.
The goal of this article is to demonstrate step by step no-code solution to build corporate policy center in SharePoint 2010 on-premises environment using SharePoint 2010 Enterprise Search, Managed Metadata, and Enterprise Content Type features.
Whole premise of this sample case study is to show case how easily you can build very complex knowledge center or centralized policy center by standardizing policy documents definition using enterprise content type across all departments in organization, allowing business users to tag documents using managed metadata, and surface & rollup policy documents using SharePoint 2010 Enterprise search technologies to the centralized policy center.
An Organization would like to build corporate policy center rolling up all the published policies from the different organization departments.
High level architecture and requirements of “Centralized Policy Center” are as following
- Corporate Policy Center conceptually represented as a Centralized solution and hosted on the root site collection. All the department policies made available to the centralized location for employees to consume.
- Policies will be available in a read-only view on the Centralized Policy Center for employees.
- Each department Policy library is hosted at the top level site of department site collection.
- Policies are created by departments and published by members of department steering committee to the policy center. Optionally it can be approved by department steering committee and allow members of departments to publish policies.
- Document-specific Metadata drives policy search as well as the various views & categorization of policies. Some of the metadata are – Effective Date, Department Name, and Applicable To
Final Solution Preview
Final Corporate No-code policy center would look like as below. Although this site or screen is not branded, it provides much cleaner view and allows users to filter policies based on refiners. By default, when user visits this page, it would show all the policies across all the departments. User can use refiners to further filter policies by department or audience it’s applicable to.
As many of you know, having decentralized authoring/hosting of Policy documents in different department site collections like HR, Legal, IT and serving those documents as centralized policy center is one of the most common pattern required by Corporate Intranet. Typically in large organizations, corporate SharePoint intranet information architecture consists of various site collections for each departments like HR, IT, Legal, or Finance.
Here are the major approaches of traditional data access methodologies and their limitations in SharePoint 2010. You can also refer my article and presentation – SharePoint 2010 Data Querying Options – Server OM vs. Client OM vs. REST vs. LINQ vs. Search API and ChDevSPUG SP2010 Developer Introductory Presentation on Slideshare
- Server Side APIs
- SPList, SPQuery, and SPDataQuery
- LINQ to SharePoint
- Client Side and Remote APIs
- CSOM and REST APIs
- SOAP APIs and WCF Services
- Targeted at List or Library
- Scoped at the Site or Site Collection
- 5000 List Items threshold
- CSOM has slow performance over the network
- Data Aggregation and Rollup would require complex custom programming
One of the biggest challenges in SharePoint 2010 is rolling up documents across multiple site collection using SharePoint APIs. Many of the OOB SharePoint APIs like SPDataQuery or Content Query Web Part are great rolling up information at the site collection level but things get grim as soon as you have requirements to roll up information across site collections. Although there are third party content query web part available from Lighting Tools to rollup information across site collections, there isn’t much options except Search.
Historically Enterprise Search has been one of the most overlooked feature for SharePoint data access method. Since Search crawls every dark corner of your SharePoint farm, conceptually Search Index has all the data you are looking for across multiple site collections and using Search API seems like no-brainer solution to rollup information across multiple site collections. This article will follow Search philosophy to rollup policies from different department site collections to centralized location as Policy Search center. Unlike SharePoint API options, Search would also allow you to design your solutions with No-Code approach and can rely only on browser customizations.
Some of the major benefits and limitations of Search as Data access method are below:
- Major Benefits
- Perfect for Data Rollups and Data Aggregations across Cross-farm, Cross-Web Application, or Cross-Site Collection
- Can query across large data corpuses (because it query against index)
- Queries are fast even with large data corpuses (because it query against index)
- Most scalable data access solution out there, All other techniques are mostly SQL-based (because it query against index)
- Major Limitations
- Content needs to be in the indexed (dependency), Avoid this option if real time data access are requirements
- Requires advanced search service administration and configuration (dependency)
- Improve search by tagging with metadata (to be effective)
Policy Center Detailed Architecture
Niks Policy Center is designed with no-code solution methodologies of SharePoint 2010. With the technologies like Enterprise Content Types, Managed Metadata, Document Libraries, Enterprise Search, and Out of box Search web parts, policy center not only allows departments to post policies in secure document libraries defined with enterprise level policy content types but also allows them to tag mandatory information to allow search to roll up policies at the centralized location.
One key thing is to keep in mind that Policies available at the centralized location would be dependent on Search crawl frequency. Plan to configure incremental crawl more frequently in SharePoint 2010 Enterprise Search Administration every few hours to ensure the freshness of policy center documents are available at the centralized location.
Here is the detailed Policy Center Architecture:
Detailed description & data flow described in above diagram for Policy center architecture are as below
- “Company Policy” Content Type defines the structure of department policy document libraries. This content type consists of two managed metadata fields – Policy Department and Applicable To, which would allow users to tag documents with proper categories while uploading policies
- Department Policy Document Libraries designed to use “Company Policy” Content Type which would allow department steering committee to upload policies as policy content type
- Department steering committee will upload Policy documents as “Company Policy” content type and tag policies to specific Department and other metadata
- Enterprise Search crawls department policy document libraries and make policy center data available through search interface
- Enterprise Search crawls “Company Policy” content type associated with policy documents and make it available through search interface, This would allow us to search policies based on Company Policy content type
- Enterprise Search crawls Policy managed metadata from term store associated with the policy documents and make it available through search interface, This would allow us to search policies based on Policy Managed metadata
- Centralized Policy center home page displays list of all the company policies through Search web parts. This page consists of two major search web parts – Core Search Results web part and Refiners web part. Core Search results web part is configured to filter all the policies for “Company Policy” content type. Refiners in the refiner’s web part would further filter search results in Core Results web part based on user selection. E.g. if user selects “Policy Department = HR”, it would further refine Core Search Results with managed metadata = HR
Implementing Solution – High level script to build Policy Center
Here are the high level steps to implement no-code policy center solution using SharePoint 2010 technologies like Enterprise Content Type, Content Type Hub, and Enterprise Search. Please download visual case study from my sky drive for detailed visual step by step guide.
- Activate Search Service and Search Service Application
- Provision Site Collection – Enterprise Search Center at http://sp2010vm/sites/search using Enterprise Search Template
- Activate Managed Metadata Service and Content Type Hub
- Activate Managed Metadata Service and Managed Metadata Service Application
- Provision Content Type Hub Site Collection at http://sp2010vm/sites/cthub using Team Site Template to define Enterprise Content Type architecture
- Configure Managed Metadata Service to use cthub as Content Type Hub
Design Data Source Architecture – Policy Content Type
- Create Content Site Collections – Three site collections based on team site – HR, Legal, IT
- Add New Terms in Term Store – New Group – Corporate, New Term Sets – Department and Employee Groups
- Define Enterprise Content Type in Content Type Hub
- Create Content Type – Company Policy in the Content Type Hub
- Add Columns
- Title (Required)
- Description (Optional)
- Effective Date (Optional – Date and Time)
- Policy Type (Required – Choice – Corporate, Department)
- Policy Department (Required – Managed Metadata – Department)
- Applicable To (Optional – Managed Metadata – Employee Groups)
- Publish Content Type from the Content Type Hub – Company Policy Content Type
- Consume Content Types from Content Type Hub in three main site collections – HR, Legal, and IT
- Run timer job – Content Type Hub, Content Type Hub Subscriber to publish content types right away
- Create new document library – Policies and Apply Company Content Type as Content Type in all three site collections
- Upload Sample Policies on all three site collections document libraries
Design Data Query Architecture – Search for Policies
- Crawl Content from Search – Full Crawl on the default content source
- Verify searching Policies from the Search Index from Search Center
- Using word – policies, it should return everything including policy documents & document libraries
- Using content type – ContentType:”Company Policy” – it should return all the policies, no doc libraries
- Using content type and search – ContentType:”Company Policy” AND Site:”sp2010vm/sites/IT” – it should return only IT policies
- Ensure Crawl Properties are included in the Index
- Effective Date (found 1)
- ows_Effective_x0020_Date(Date and Time), No Mapping
- Policy Type (Found 1)
- ows_Policy_x0020_Type(Text), No Mapping
- Policy Department (Found 3)
- ows_Policy_x0020_Department(Text), No Mapping
- ows_taxId_Policy_x0020_Department(Text), owstaxIdPolicyx0020Department
- Policy Department(Text), No Mapping
- Applicable To (Found 3)
- Applicable To(Text), No Mapping
- ows_Applicable_x0020_To, No Mapping
- ows_taxId_Applicable_x0020_To(Text), owstaxIdApplicablex0020To
- Effective Date (found 1)
- Run Full crawl on default content source to populate crawl properties and default managed properties
- Create Managed Properties for Custom Columns and map managed metadata properties to text crawled properties – Select all the check boxes – Allow this property to be used in scopes, Reduce storage requirements for text properties by using a hash for comparison, and Add managed property to custom results set retrieved on each query
- EffectiveDate – ows_Effective_x0020_Date, Date Time
- PolicyType – ows_Policy_x0020_Type, Text
- PolicyDepartment – ows_Policy_x0020_Department, Text, Multiple Values
- ApplicableTo – ows_Applicable_x0020_To, Text, Multiple Values
- Run Full Crawl on default content source to populate managed properties
- Verify searching Policies from the Search Index by managed properties – ApplicableTo:”Contractors” or PolicyDepartment:IT, it should return results
Design final Solution – Centralized Policy Center
- Configure Corporate Policy Center to demonstrate rollup across multiple site collections
- Policy Center view is made of 4 search web parts – Refiner Panel, Search Statistics, Search Core Results, and Search Paging Web Parts.
- Add Refiner Panel and configure properties to return specific categories
- Add Search Statistics Web Part – No Settings changed
- Add Core Results Web Part and configure properties with updated XSL for simplified UI – Set Append to Text Query – ContentType:”Company Policy”
- Add Search Paging Web Part – No Settings changed