Aspects are new in D6. You can find an excellent post on this blog regarding the features and usage of aspects. http://doquent.wordpress.com/2007/09/26/new-in-d6-platform-aspects/ I will not repeat the information.
What I will do is talk about how we are using Aspects in our current implementation.
Scenario:
We are migrating about 50,000 documents from IBM Domino.doc to Documentum. We decided to build a custom application to do this. We have to make sure that all the meta-data from Domino.Doc is moved to Documentum. In addition, we want to keep track of the migration audit trail such as – Who migrated this document, when, what was the document’s audit history in Domino.Doc.
Approach:
We have several custom doctypes. But the parent of all these doctypes is a document called sp_document which has all the standard meta-data derived from Dublin-core and SGMS. Our initial approach in V5.3 was to create an attribute called sp_migration(2000 chars) and store the migration audit trail here. But this was problem because this was going to impact both migrated documents and the future documents. Future documents will have an empty sp_migration attribute which is not desirable.
Creating an aspect to hold the migration audit trail was a much better solution. We created the sp_document without the sp_migration attribute. We created an aspect “my_migration_aspect” with an attribute “migration_comments”. In our custom migration code, we attached the aspect to the newly migrated documents and set the migration history.
What do you need?
As of today, the documentation provided by Documentum for aspects is meager. Javadocs are missing for com.documentum.fc.client.aspects package. The tool you will definitely need to create aspects – “AspectCreator” tool. I got this tool from EMC during our Documentum Training session – “What is new in D6?” Unless D6 SP1 comes up with tools for aspects, you will have to get this tool from EMC.
I have tried ALTER of aspects from DQL. I got some parser exceptions. So you will have to depend on the “AspectCreator” tool.
Steps involved:
- You will have to create an Interface and Implementation class for the aspect you are creating. You can find the example code in DFC 6 Development Guide. Compile these and create separate .jar files. This step involves some simple programming.
- Update the .xml file provided with “AspectCreator” tool to specify the details of the aspect you are creating and the doctype you are allowing the aspect to be applied. I could not find any documentation for this.
VERY IMPORTANT: From trial and error, I learnt that if you are creating a STRING attribute, you have to specify the type along with the string length as STRING(2000) . If you don’t specify the length you will get a StringIndexOutOfBounds exception.
- Run the command line tool create.cmd provided with “AspectCreator” to create the aspect in the docbase. Make sure you update this .cmd file with the correct paths and parameters.
Some Gotchas:
I have faced some strange errors such as ClassCastException when running Aspect code from IDE (Eclipse). The same code ran fine when run from command line using ANT.
I will try to upload some sample code in my next post.
Good luck.
Ram
January 27, 2009 at 11:30 pm |
Hi Ram,
We are also planning to migrate content from Domino.Docto Documentum,
can you please provide some hint or share your experience?
January 28, 2009 at 5:00 am |
Hi Nishant,
Firstly you need to decide if –
1) you are going to fully automate the migration OR
2) you want the users to play a part in updating the meta-data, verifying the documents, etc.
Automation will work great if the folder structures and meta-data in Documentum and Dom.Doc are the same.
Secondly, you will need some mechanism to export the rich-text fields in Lotus Notes to a format that Documentum accepts. We converted those documents with rich-text fields to PDF. (We used a tool called N2PDF for that.)
We did not depend on vendors for this migration since vendors did not have expertise in both Lotus Notes and Documentum. We did the implementation ourselves. You will need people who know the internals of Dom.Doc, Lotus Notes programming and Documentum DFC programming.
1) Make sure you test extensively.
2) Test using production Dom.Doc documents to verify all possible scenarios
3) Know that you will still hit exceptional cases during actual migration. But your target should be to minimize these exceptions.
4) Become friends with your end-users. They will help you
Depending on the number of documents you have, you maybe in for a long-haul. We migrated about 65,000 documents over a period of 6 months.
To give you an idea, our implementation of the module took us around 6 man-months and testing took around 3 man-months (spread over a duration of 18 months working about 50% of the time).
Good luck.
Ram