Amusingly MOSS

...It's funny how difficult some stuff is when it really shouldn't be

  Home  |   Contact  |   Syndication    |   Login
  29 Posts | 0 Stories | 34 Comments | 0 Trackbacks

News

Twitter












Tag Cloud


Archives

Post Categories

Monday, October 19, 2009 #

So we landed on a solution.  It's not ideal by any stretch, but it does accomplish the purposes we set out to meet, and it does give us a (small) step in the right direction in terms of moving the client to using Oracle UCM as the sole company-wide content repository.

To recap, here's the skinny on what we're facing:

  • There is a mandate in the company to move all "content" to Oracle UCM (a content unification measure)
  • There is a significant amount of content in SharePoint (in the form of lists) that needs to make its way into Oracle UCM
  • Business users do not want to stop using the SharePoint interface for data entry (not to mention get all the "for-free" stuff that comes with SharePoint, such as alerts, content approval mechanisms, permissions, and workflow).
  • It is not feasible to move all of the lists over at once (we have a 3-week scope to move "something" over from SharePoint to UCM)

We came up with two approaches that had varying payoffs and risks.

  1. The Simple Approach

    Seeing how it was very important to keep all of the existing functionality in SharePoint in whatever solution we devised, we first thought of "replicating" list content to the UCM from SharePoint.  This approach involved writing a custom workflow that would fire on list item update, and would intelligently call a checkin function in UCM.

    This "simple" solution wouldn't come without risks - the first (and most obvious) one being that we'd have duplicated data that needed to stay in sync.  After thinking about the implications, we found that this risk wasn't terribly bad.  Since no content contribution happens on the UCM-side with this implementation, there's no harm if SharePoint goes down - there just wouldn't be any new data.  If the UCM goes down, syncing the data would mean saving the items again (a solution acceptable by the client).

  2. The UCM-Heavy Approach

    This approach was quite a bit more aggressive in terms of planning, execution, and support, but yielded a much bigger step towards migrating the list content from SharePoint to UCM.

    The plan was to "switch out" standard SharePoint CrUD (and other) functionality for custom functionality that manipulated UCM content directly.  The idea was that all point-foward content would be manipulated directly in Oracle UCM through the SharePoint interface.  We felt that if we could nail this approach that we'd set a good proof-of-concept for migrating other content to UCM from SharePoint.

    This approach was monstrously invasive.  It involved re-writing a lot of stuff that comes for free with SharePoint, and was therefore expensive and risky.  However, the payoff of making such a big step towards UCM would be a huge win for the client.

The Accepted Solution

It will probably come as no surprise to many of you that we landed on solution #1.  What killed solution #2 was that UCM doesn't have an OOB way to handle broadcasting alerts based on permissions (on the item level) when content was created or updated.  Sure, we could write a workflow to sorta-kinda handle it in UCM, but we didn't have the time or budget for it.

Next time, I'll tell you a little about how we're going about implementing solution #1, and what sorts of challenges are cropping up.

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati