Wisdom SharePoint 2010 Integration Version 3 – Installation and Configuration

 

The feedback from users using version 2 of the Wisdom / SharePoint integration was that the installation process was complex and the configuration was inconsistent. With version 3 this has been addressed. The setup has been split into two MSI. The SharePoint Server MSI and the Wisdom Server MSI

To install the Wisdom Components you just run the MSI, nothing else.

To install the SharePoint components you run the MSI and this will create a folder with a PowerShell script and the WSP package (Plus some other dependency's such as the RBS MSI)

Just run the PowerShell Script :

If you look at your SharePoint solutions you will see Wisdom.SharePoint.Integration.wsp and you will have the following features :

Web Application Features

• Wisdom Record Centre
  Allows SharePoint users to navigate the Record Centre
• Wisdom Identity Provider
  Loads the Wisdom Identify provider in order to allow wisdom to determine the user.

Site Collection Features

• Wisdom Site Collection Settings
  allows the following to be configured
  • Wisdom Global Field Mappings
  • Wisdom Automatic Registration Rule Types
  • Wisdom Automatic Registration Rules

Site Features

• Wisdom Document Library
  Document Library with Wisdom features
• Wisdom Document Library - Ribbon Buttons
  EDRM Ribbon buttons, eg declare

Once these are active you will see configuration options at levels that you would expect. You can customise your auto declare rules at the site collection but use them on the site :

All configuration is done from SharePoint admin / settings screens such as :

Wisdom SharePoint 2010 Integration Version 3 – No longer all on one server.

 

The feedback from users using version 2 of the Wisdom / SharePoint integration included the fact that wisdom was required on the SharePoint server and SharePoint was required on the wisdom server presented a problem.

Wisdom on the SharePoint server added lots of unneeded components; such as Wisdoms Message queues, its services and the main web app. SharePoint on the Wisdom server creates an overhead for the Wisdom server and is a licencing concern. With version 3 you can chose to have ‘it all on one box’ or you can have Wisdom and SharePoint on their own servers.

The following diagram shows a typical environment :

To make this possible the Audit and Job Queue services have been refactored so they are not needed on the Wisdom SharePoint server. We have also made significant changes to the way the configuration works. You now have a configuration server and other servers requiring the wisdom API can load the configuration from the central server.

Wisdom SharePoint 2010 Integration Version 3 – Automatic registration / declaration of documents

 

With every release of the SharePoint integration the registration of documents has been improved.

The first release required a user to ‘chose’ the location for the document when registered in Wisdom. The user was presented with a picker :

The feedback we had from users was;

“We don't want to have to pick the file plan location”

“Users don't understand the fileplan”

The next release allowed the location to be ‘saved’ against a document library. This gave a one to one mapping.

This did work but it had to be setup on each document library.

The next release allowed the location to be driven from metadata and could be saved against the site :

The location can be derived from metadata on the site or list item. This allows unstructured SharePoint documents to automatically become part of a structured FilePlan and have retention policies applied to them.

This allows a user to register a document with the ‘Quick’ register option :

Or they can go via the wizard :

Although this did work some customers didn't want the users to have to ‘register’ or ‘declare’ documents. It should be automatic. The Wisdom Auto-Registration Feature allows documents to be registered or declared based on rules. Feedback from users was:

“Our SharePoint users don't want to have to click declare or register”

“We don't want to have to create custom code to do this”

“User should never see the eDRM or even know its being used”

For example, you can have all documents that are saved into SharePoint registered in Wisdom and once certain metadata requirements are met they document could be ‘declared’ .

This allows users / administrators to create workflows that could set metadata that would trigger the declare and the creator of the workflow does not need to use any extra actives or code.