Last week, I mentioned the importance of the tight integration between Office and SharePoint. It is one thing to say that most of the documents we have to upload to our SharePoint library were created in Microsoft Office. It’s quite another thing when we realize that we began creating these using Office 97 and these documents are currently in a number of different locations. In most cases, this comes down to a “you know the drill” moment. In this particular case, we found a Rosetta stone of sorts. One of our employees had an Excel spreadsheet that linked to the documents in their various locations. The spreadsheet also included numerous columns of information about the documents, some of which matched our metadata requirements exactly. Unfortunately, the spreadsheet had been poorly maintained and also included a few errors. With the help of a temporary list, a few VBA scripts and a few disposable workflows, we were able to update and correct the spreadsheet, and then upload it to a SharePoint list. Once in SharePoint, we ran a workflow that used the list values to update the document library metadata. It wasn’t pretty, but it worked, it saved time and it helped ensure accuracy. I realize there are products that can perform tasks like this, but when you only need to do this once, buying something doesn’t make sense.
Moving on to the opposite end of the Capture portion of the roadmap, we find one interesting on-ramp lane, Application Created Information. We have quite a bit of this content in our organization and even some in this particular project. The important thing to understand about this content is that it is already being created by the most efficient process we can imagine. In other words, this does not represent a problem we want SharePoint to solve. Instead, we are extending the reach of our applications to include SharePoint, by taking advantage of the powerful, albeit poorly documented web services interface that Microsoft provides. This represents an expensive proposition for us, but unlike a highly focused add-on product, this is a broad based solution that we can use in multiple applications. We are building this capability gradually; our first version can handle basic list and library operations. That means that our applications that create reports can also file them. While we can’t yet initiate a workflow, we can rely on SharePoint to handle that task until we finish v2.0 of our development effort.
In addition to the expense associated with building the interface library for our software development environment, will be buying some products too. We are currently evaluating Muhimbi’s PDF Converter for SharePoint, to create PDFs on SharePoint and inside workflows. We are also planning to integrate PDF manipulation capabilities into our in-house applications in 2011. That capability will enable us to automatically update PDFs stored in SharePoint. These two solutions will help us to bring content into SharePoint through non-traditional pathways. We may be driving on the shoulder of the on-ramp, but I think that still counts as capture.
Information Stories 