Once the documents are migrated I need to update the migrated list/library items. What I don’t want is to keep one set of “preserved” fields and another set of SharePoint fields. The SharePoint fields, as you probably guessed, set the author and editor as the individual doing the migration (or impersonated member) and the created and modified dates being the date of migration.

Updating list items is a pretty easy thing to do in SharePoint’s Client Object Model. The following code accomplishes this task.

“ctx” is my ClientContext, though that is probably self-evident. You may also note that I only process items whose content type is my custom content type “migratedDoc” which is instantiated as “migType.” Only the migrated documents will have this content type.

eRoom documents do not have Titles, so I set a title based on the file name. You can leave Title blank – it isn’t a required field. Continuing through the code you will notice that I check that the names of the editor and author exist in the LDAP (ctx.Web.EnsureUser(sAuthor)). The update of the list/library item will fail if you try to use an editor or author that doesn’t exist.

I don’t really want to have a custom document library – the SharePoint default document library is just fine. So to get the result I want I need to reassign all the migrated items to the standard “Document” type. List items content types have a Name property. Unfortunately you can’t change it – it is read only. What you can change is the ContentTypeId and changing that value changes the content type of the list item. In the code above “docType” is local instance of the “Document” content type.

I said at the beginning of this article that I would explain why I wanted to keep the “Document” content type in addition to the creating a custom content type. The reason is that you can’t assign a list item to a content type if that content type isn’t in the list. That’s also why you can’t move a document from one SharePoint library to another unless its content type is in the target library as well.

Next I want to remove my custom content type from the list altogether. But to do that, I have to make sure that all those extra fields that are in the custom content type are set to null – which I do before changing the content type. The order of resetting these fields and reassigning the content type doesn’t matter. What does matter is that if these extra fields are not set to null, you will be unable to remove the content type from the list.

After processing all the list items I can now remove the custom content type from the list. Easy, two lines of code:

But that still doesn’t remove the custom fields from the list. More code is needed.  Incorporating the delete of the custom content type you have this.

And that’s it! The library looks like the default document library with only the “Document” content type as desired.

A long time ago I posted this blog.  I had not realized it was over a year ago, but I will continue on with more information around the Export.  I chose to use VB6 as it was the easiest way to start working against eRoom’s API’s.  John and I discussed whether we should attempt to migrate against the eRoom database tables or use its API’s.  It was decided to go down the path of using the API’s which should provide more flexibility going forward.  Though I do still like the idea of migrating from the database directly.

The design of the export piece is fairly simplistic.  Start at the top of the eRoom structure and walk each branch outputting all associated metadata into a well formed XML document.  The goal was to have as much data as required to recreate it all again in another eRoom instance.  [Note, we have not actually written a Load module for going into eRoom.]

For the most part, in the code, every object can be treated as an IERUItem.  This helps with creating helper functions as we can simply pass this object type about.  The next important step is to determine the properties that are part of IERUItem by which you can further derive information.  By doing this you open up a host of new goodies to delve into.

For example is this item a container.  To find out check the property isContainer (which is missing from API help document).  A container is a way of grouping other objects together.  Kind of like a folder.  If a room is being exported, first the groups and members are put into the XML, followed by properties relating immediately to the room, then a container element is identified.  The Exporter takes a depth first approach, so a list of all items in the container are identified and the process continues.

One thing to note, a visual debugger is your friend.  The API documentation is good up to a point.  Then you realize that some object properties were left out of the documentation or property values may not be quite what you expected them to be, like properties may not be instantiated if they are not relevant to the object.  Once the gaps are filled in it becomes quite intuitive working through eRoom structures.

Currently, the user can export all of the communities or facilities, or selected rooms.  The design thought running behind this was to be in the position of exporting rooms to the repository of choice.  In other words, if marketing and legal have all their content within the same facility but would like them to be in separate repositories, this can be accommodated.  Actually it can be accommodated in a couple of  ways.  At the export setup, you can export specific rooms to be designated for specific repositories.  All of the necessary metedata will still be exported (i.e. users, groups, etc.) with each room.  The result is multiple export.xml files.  Then at ingestion time, the user would ingest each export.xml and associate it with the appropriate repository.  The other method would be to export all rooms and handle the repository association at ingestion time.

Some thoughts around improving the Exporter Tool is around further investigation into the eRoom XML Query interface.  This opens up more options for different programming languages and different thoughts around the overall export.  Of course, it could open up more gotcha’s as well  The next exciting installment around eRoom migration will be around the transformation tool.  Now that we have all this wonderful XML, what do we do with it?  This is were things really start to get interesting as what will the eRoom XML output be transformed into?

So who else has been looking at their eRoom environment wondering when and how they are going to migrate away from their legacy system?

EMC eRoom is going away.  It has been marked as End of Life (EOL) so what next?  EMC Documentum have 2 options: EMC Documentum Collaboration Services; EMC Documentum Centerstage.  Armedia’s immediate goal is to support Collaboration Services, then Centerstage but why stop there?  Why limit a client’s choice.

Armedia’s eRoom migration story is in 3 acts (and yes, I have been listening to some test pieces that I used to play in my brass banding days – check out Year of the Dragon by Philip Sparke).

Act I – The Export

Getting the content out of eRoom into an understandable format.  Of course, its not just the content, there is  a large quantity of metadata in eRoom as well.  Act I – The Export deals solely with interrogating eRoom and generating a document detailing everything about eRoom.  From communities to Files.  From eRoom Setup to databases – we mean everything.  The result: a well-formed XML document

Act II – The Transformation

As with any classic performance, after the captivating opening, Act II deals with getting to know the characters.  In this case, the transformation gets to know the XML document and gains a deep understanding of the objects held within.  The transformation is responsible for also generating a secondary XML document. This is formed to support the ingestion to a new Content Management System (CMS) and / or Collaboration System.  Currently the supported transformation is for EMC Documentum Collaboration Services.  This can easily be extended due to the flexible architecture of this utility and is simply a case of transforming XML.

Act III – The Load

The closing act is the build up to the dramatic climax which leaves the audience going “WOW!”.  eRoom Migration aims to achieve the same “WOW!”.  Now that the XML has been transformed you can sit back and let the load run automatically.  That’s it.  By using the ingestion engine of Caliente! loading all the content and metadata is simple.  Just let eRoom Migration take care of everything for you.  The only thing it does not do is say “WOW!” – we leave that to you.

Over the next few weeks I plan to talk in more detail about the approach taken and dig deeper into the 3 different pieces of the migration effort.  For those eRoom users, what do you see yourselves using in the near future?

Migrating CAD engineering drawings poses its own set of unique challenges. AutoCAD and MicroStation drawings can internally have references to other drawing files that exist within the content management system (or file system). When moving these files over to a new system, care must be taken to ensure these references are maintained.

Sword CADtop is a tool that provides users access to CAD drawings that are stored in a Documentum repository directly from within AutoCAD or MicroStation. It gives the user the ability to check in/out drawings, browse, search, view documents and attach reference drawings that exist in the docbase. CADtop maintains reference information by updating the links within the drawing and storing this information in a registered table.

CADtop also provides an import tool that can be used to migrate documents into the Documentum system. It handles importing of documents of multiple types, such as .pdfs, .docs, .tifs, etc. along with the drawing formats, .dwg and .dgn. It is a very simple to use command line tool, but it has its limitations. It can only handle importing up to around 5000 files at a time. However, this can be overcome by creating a batch script to automate the copying of sets of files to a temporary directory and running the import tool.

The import tool uses an XML configuration file to determine the object type, folder path to import from and cabinet/folder to import to. However, those are the only properties you can set. The import tool has no way to attach meta-data from a database to content files being imported. A way around this is to make sure each file has a unique name, then import the files, then using a DFC script, update the properties of all the objects in the docbase from an XML file (for example). This works well as long as all the filenames are unique in the first place, or not drawings with references. If filenames are not unique, then you would have to rename the files, which means the filenames will no longer match the drawing’s internal reference links.

The import tool provides you with a switch that lets you run it in attach reference mode. This allows you to pass an Excel file which consists of a table of parent object IDs, child object IDs and reference filenames, so that you can resolve references within drawing files after they’ve been imported into the docbase. Thereby allowing you to use a tool such as Caliente (Shameless Plug™) to import the drawings into Documentum and update the properties. Then create the Excel file with all the references and run the CADtop import tool to attach them.

The end result will be that when you open one of these drawings through AutoCAD, CADtop will automatically pull out all the references from the Documentum repository and display them, just as in the legacy system.

It’s simple.  The new Content I/O Suite.  Armedia’s Content I/O Suite allows users to collect information from all of those billions of sources, migrate it to the centralized repository in the company, and then, if needed, deliver that information to the different web portals that may need to view the information later.  In fact, it can even send the information to multiple repositories all from the same interface.  So what if Human Resources uses Documentum, and Accounting uses Laserfiche, and some departments have their own collaborative eRoom set up, but you just merged with another company who uses SharePoint and FileNet.  What if one user could capture the information coming in from the website, or through email, or through regular snail mail, and deliver it into the appropriate system, without that one user ever having to be trained in each of those systems?  Sounds too good to be true, doesn’t it?  Check it out at http://armedia.com/products/suite/.

-Kristin Evans