Notes SharePoint Blog

Part 1 of this article [link] describes how SharePoint Content Types might be useful when migrating multiple Notes “document types” to a single SharePoint List, Document Library, or InfoPath Forms Library.  Now we will take a look at how this can be accomplished using our tool, Notes Migrator for SharePoint.

First a recap of the Content Type features in the Notes Migrator for SharePoint documentation:

• To assign the Content Type of a SharePoint item, simply add a Text field named “ContentType” and map the appropriate input data to it.
• The ContentTypes property in a Source DataDefinition field indicates that the data field should only be migrated SharePoint for certain Content Types.  Leave this property blank to always write the field, regardless of content type.

The following example walks through the steps needed to create a SharePoint list using Content Types and then migrate Notes content to it:

Our example Notes database is a fairly typical Notes document library except that it has three types of documents in it:  Tech Notes, Code Samples, and FAQ Documents.  The “document type” is really controlled via a DocType field (not separate forms as described in Part 1).  All documents contain standard fields such as “Subject”, “Category”, and “Product”.  Code Sample documents contain an extra “Language” field and FAQ Documents contain “FAQ Type” fields.

On our SharePoint site we created a corresponding List with three content types similar to the ones we had in Notes:

• Content type “Tech Note” has columns “Title”, “Product”, “Details”, “Url” (a “link” field).
• Content type “Sample” inherits from “Tech Note” and adds column “Language” (a choice field).
• Content type “FAQ” inherits from “Tech Note” and adds column “FAQType” (a choice field).

Note: I intentionally designed the Notes “FAQType” field to have a slightly set of choices than the WSS “FAQType” field so we can demo data massaging.

In the following screen shots, notice that certain columns only apply to certain Content Types:

For the migration job itself, I selected all the data fields, including the DocType field as well as fields that were specific to certain document types, in my Source Data Definition.  Nothing unusual here, except that I did a little “data massaging” along the way:

• The “Product” column is really the Categories item with an alias.
• The “FAQType” column is a Formula column that massages the data during migration: 
  @If(FAQType=”How To” | FAQType=”Problem”;”Solutions”;FAQType)
• The “OnlineLink” column is a Formula column that computes the URL to the document on the Proposion web site.

In our Target Data Definition, we added a SharePoint field called “ContentType”.  We can map any source column we want to this field, and the Content Type for each new document will be set accordingly.  In our case, of course, we will map the DocType column to this field.

For the “Language” and “FAQType” fields, which are only for certain Content Types, we specified the content type in the ContentTypes property of the Target Data Definition field definition.

The result of running this migration job is a SharePoint List populated with mixed types of content:

Content Types are a very powerful way to express the concept of “document types” or “business objects” in SharePoint. 

In the Notes world, it is quite common to design an application that has multiple types of documents in it.  Even though Notes databases are unstructured and (by design) lack any type of schema, good Notes developers usually adopt certain patterns and practices that impose some order in their applications and usually this includes establishing distinct, meaningful document types.

From a development perspective, this is largely driven by the different Forms used to create Notes documents.  A great example of this is a standard Notes mail database, which has Memos, Tasks and Calendar Entries.  If you want a business application example, think of Customers, Customer Contacts, and Sales Reps in a CRM database.  Each of these “document types” has different fields in it and each is created with a different Form. 

While Notes Forms has several other uses (for example, to display a pop-up dialog), the Form used to a create a document becomes the de facto “document type” in most cases.  An application may contain one or more Views or Folders for each document type (for example “All Tasks by Priority” or “Open Tasks”).  But it is also common to design a View or Folder that shows multiple document types together (for example showing Customers and Customer Contacts together in the same view).

A common variation on the above pattern is to use different forms to express extended document types (what object oriented developers would call “sub-classes”).   An example of this would be an application that had both Customers and Government Customers.  While a Government Customer is a type of Customer, it has additional fields and may have additional data validation rules, different security, etc.  You could easily imagine a View that shows “all customers” together without making any distinction, but when you opened a Government Customer record you would see something different than if you opened a “plain” Customer record.

The notion of defining different document types is not limited to Notes applications.  QuickPlace sites have several different default “Page Types” and users can create their own custom Page Types with additional fields.  Similarly Domino.Doc libraries can be extended with both custom Document Types and custom Binder Types.

So how do these concepts translate to the SharePoint world and how do you you deal with them when migrating?

When migrating a Notes application, a QuickPlace site or a Domino.Doc library to SharePoint, developers typically do one of three things.  Note that each of the following choices apply equally well whether you are migrating to a SharePoint List, Document Library, or an InfoPath Forms Library:

1. Split different document types into a different Lists.  You could easily run one migration job that moved all Customer records to one list and another job that moved all Sales Rep records to a different List in the same SharePoint site.  This would be a particularly good idea if, for example, you wanted Customers to have a “Rep” field that was a Lookup field from the Sales Rep list.  It is less clear, however, that it would be good to split up Customers and Government Customers this way as you probably want them to stay together.  Notes Migrator for SharePoint allows you to select records by View or by Formula; if you can not find a View that selects the documents you want you can use a Formula such as: FORM = ‘GovernmentContact’
2. Merge different document types into a single uniform List schema.  For example, you could migrate all Customers to a single Customers list and discard the extra fields that was in Government Customers (a “least common denominator” approach).  Or you could include all the “government” fields in your new Customer definition and just leave these blank for the records they don’t apply to (a “grab everything” approach).  You might even add a new “Customer Type” field that recorded whether or not it was a Government Customer in Notes.
3. Use Content Types.  The pattern of using Forms to express document types in Notes applications maps almost perfectly to SharePoint “Content Types”.

There is a lot of information on the web about Content Types.  I like Andrew May’s blog [link].  The Microsoft SDK documentation [link], which can be pretty intimidating to read, introduces Content Types this way:

Content types, a core concept used throughout the functionality and services offered in Windows SharePoint Services 3.0, are designed to help users organize their SharePoint content in a more meaningful way. A content type is a reusable collection of settings you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way.

One of the reasons Content Types seem so intimidating to new SharePoint developers is that they are used for so many things.  Not only are they used to express which document types contain which fields (the important part for people migrating content), they can also be used for the following:

• Custom user interfaces
• Templates for creating new documents
• Workflow rules
• Microsoft Office integration
• Inheritance from “base” Content Types
• Reuse across multiple lists in a SharePoint site

The good news is that using Content Types for simple things (i.e., defining multiple structured document types in a single list) is actually pretty simple.  In spite of what some of the literature implies, you do not need to be a developer or create features or even use XML to create document types.  I believe that as people come to understand them better, they will become more widely used.

Notes Migrator for SharePoint has the ability to set content types in migrated documents based on the Form that was used in Notes, or whatever other criteria you want to use.  Part 2 of this article will discuss how we make that happen and will include a working example.