Creating a Centralized Document Repository with External Content Types

The last couple posts I’ve written have focused on using External Content Types (ECT), a feature delivered within SharePoint 2010 as part of the Business Connectivity Service.  This post continues that discussion with an example of creating a shared document repository across multiple projects within Project Server.

I discussed a different type of implementation of similar functionality in a previous post.  in that example, I used an attachment-enabled list to allow users to upload documents via the Project Detail Pages (PDP).  From a user perspective, this would involve navigating to each individual project within the Project Center, navigating to the correct PDP, and then uploading the document.  Similarly, to review the documents, you would have to navigate to each project.

This post is slightly different.  Suppose you needed to perform a batch upload – you had a couple documents for each project that you wanted to upload in a single interface.  ….or suppose that you needed to see all of these documents in a single library, despite the fact that they may be attached to different projects.

image

My guess as to the most typical usage model for this kind of implementation would be where the PMO performs an administrative function and batch uploads specific documents.  Those documents are then available for consumption by the various project team members from the PDP interface.

Create the ECT

Follow the instructions in this post to create the ECT.

Make sure to add a filter to the Read List operation as documented in this post.

Create the Document Library

From PWA, select the View All Site Content option under the Site Actions menu.

image

Create a document library.

image

Navigate to the Library Settings.

image

Within the Library Settings, choose the option to Create Column.

image

Configure the new field as depicted in the following illustration.  This will allow users to select the project name and tag the document with the project unique identifier.

image

Test the document library.  Navigate to the main document library and add a document.  Confirm that the document metadata includes the option to enter the project name.

image

Review the uploaded document to confirm that the ProjUID field is populated properly.

image

You now have a centralized document repository with project level metadata in the PWA site.

Adding the Documents to a Project Detail Page

Adding a filtered view of the document library to a PDP is now quite easy.  Create a new PDP and add two webparts: the query string filter webpart and the newly created document library.

image

Modify the query string webpart to pull the ProjUID parameter from the PDP URL.

image

Now connect the webparts so the query string filter webpart filters the documents in the library by the ProjUID field.

image

Add the PDP to the correct Enterprise Project Type, and you now have the filtered data surfaced within a PDP.

image

Advertisements
Creating a Centralized Document Repository with External Content Types

Centralizing Project Detail Page Information: Centralized Document List

In the last two posts, I have been exploring a simple, common usage model with Project Detail Pages that allow users to store centralized information in environments where not every project within Project Server 2010 may map to a specific project site.  Some potential use cases for this functionality may include:

In this post, I plan to further develop that concept with a centralized document repository.  Why would you want to develop a centralized document repository?  Perhaps the project approval document must be posted to the PM Information System before the project workspace is provisioned.  Perhaps some projects will never have their own dedicated workspaces and will exist only as document libraries on a shared site.

image

In this example, I will walk through how to create a central repository for approval documents.  Before going any further, I would strongly recommend reading this post on creating custom lists consuming PDP parameters within Project Server 2010.

As I developed this solution, my first thought was to create a document library, then add the ProjUID field to the document metadata.  I’ve successfully done this with External Content Types (ECT) and Business Connectivity Services, but received feedback that the ECT solution was too “clicky” for some end users.  (I’ll cover that as a potential solution in a future blog post.)  The challenge I discovered is that SharePoint 2010 document libraries do not allow customization of the main form using InfoPath. 

So I decided to go with an alternate approach.  Instead of using a document library, I would just use an attachment-enabled list.  Effectively that would deliver the same functionality as a document library and met all of my requirements.  The only minor hiccup was my apparently erroneous understanding that list attachments are not indexed by the search engine.  After a little research, I determined that this is somehow a commonly spread misunderstanding dating from SharePoint 2007.  Either it’s always worked and folks didn’t realize this….or it started working with a patch somewhere.  So let me set the record straight on this one….documents will be indexed within SharePoint even as attachments to list items.

To create the list, follow the same instructions as in the previous post, but create a custom list.

image

Add custom fields as appropriate.  Here again, I add the ProjUID field.

image

Modify the InfoPath form.  In this form, I add a default value to the Title, modify the Attachments label, delete all extraneous rows, and add a Submit button.

image

From there, I add it to a new PDP using the same technique as in the last post.  The end result is an interface for loading and reviewing approval documents for each project.

image

Centralizing Project Detail Page Information: Centralized Document List