Documentum 6.7 Upgrades and Hardware Changes

With Documentum 6.5 SP3 going out of support this year (August 31, 2012), we’re running several Documentum upgrade projects for clients this quarter. Unlike in the past where upgrades promised fantastic new functionality, this round of upgrades is trending more towards maintaining supported configurations and upgrading to new hardware. In addition, rather than simply upgrading the OS, companies are virtualizing servers and rolling out 64-bit hardware wherever possible.

Documentum xPlore Deployment – Lessons Learned from Pharma Implementaion

We’re working with a large Pharmaceutical company to install Documentum xPlore as a replacement for FAST.  We’ve just finished the QA environment deployment, and we’re planning for the Production deployment in mid-April.  For this post, we are going to discuss the cutover strategy as well as some lessons learned from the project.

Documentum – EMC World – Momentum 2012 – Early Predictions

Once again TSG is attending EMC World in Las Vegas – May 21-24.  For those interested, early discounts are still available at http://www.emcworld.com/momentum.htm.  While not much is known at this point in time about the final agenda list (or who the opening/closing acts are), this post will try to take a guess at the dominant themes based on the Momentum Conference Agenda.

Documentum Migrations – Interview with OpenMigrate Product Manager

For this post, we interview Todd Pierzina, Product Manager for the TSG OpenMigrate product in regards to his thoughts around Documentum Migrations as well as other migrations for SharePoint or Alfresco.

Documentum 5 vs. 6, Databases and Dates: Does Anybody Really Know What Time It Is?

When EMC revealed Documentum 6 a few years ago, they made a subtle—yet important—change to the way Documentum would store dates and times in the database. While most clients would never even notice the change, some of us would. In particular, when it becomes necessary to access the underlying database tables, like OpenMigrate can when preserving modification dates, confusion can be the order of the day.

Documentum Workflow Manager, BPM, and Licensing

We just finished a new 6.6 Documentum install for a client and ran into something slightly unusual.  During the installation, we were not able to install a workflow template from an existing archive, a routine install activity.  In the past, we could always move workflow templates between repositories using Application Builder and Installer and create new templates with Workflow Manager.  While Documentum Application Builder and Application Installer became unsupported with the release of Documentum 6.0, Composer was introduced as a replacement.  Up until recently, Composer supported the archival and deployment of workflow templates.  Most of our Documentum clients were surprised to learn that the 6.6 release of Composer does not allow workflow templates to be archived without having Process Engine, a component of the Business Process Manager (BPM) suite, installed in the repository.  This post will discuss this issue, as well as our thoughts on possible future Documentum licensing around workflow tools.

Documentum 6.6 Upgrade – Character Encoding Fail – Part II

This week we are urgently reminding clients, as part of their upgrade evaluation, to look seriously for character encoding issues in regards to their current Documentum content and the affect on upgrades.

Documentum Compliance Manager (DCM) 6.5 Upgrade Thoughts

Many Documentum Compliance Manager (DCM) 5.3 users are reaching a decision point on upgrading to DCM 6.5.  The typical driver is primary support for DCM 5.3 expired on 12/31/2009 while DCM 6.5 will be supported until 08/31/2012.  Typically DCM is used by companies operating in regulated industries (ex: pharmaceutical manufacturing) to meet regulatory requirements around managing their documentation (SOPs, Specifications, etc.) electronically.  The product consists of extensions of the current core Documentum client application, originally WorkSpace and currently Webtop, along with other software integrations to provide required features for document control including dynamically applied watermarks (PDFAqua), electronic signatures, security, lifecycle and other additions to the typical Documentum client.  Given reliance on Webtop, some common issues with DCM include:

• Its tendency to lag behind in release dates compared to the rest of the product stack, evident with the late release of the 6.5 version
• The general difficulty clients have had in upgrading between major releases.

This post will discuss some of the things to look for when considering the upgrade to 6.5.

Documentum 6.5 Upgrade – Character Encoding Issues

Special Note:  Anyone that is planning an upgrade from Documentum 5.3 to 6.5 should look closely at this note as some types of upgrades (clone or in-place) could result in content that was retrievable from 5.3 not being available in 6.5.

This post was developed based on recent work for a major pharmaceutical client.  The client, on Documentum 5.3, was developing a consumer interface application leveraging Lucene.  As we mentioned in a previous post, the client chose Lucene over FAST based on benchmarking results for over 150,000 documents.

Background

For the application, the client was leveraging OpenMigrate with DFC 6.5 to retrieve content and metadata for nearly 1,000,000 documents from their 5.3 docbase to be indexed in Lucene.  Per the product release notes, using DFC 6.5 to access a 5.3 repository is a supported configuration.  An issue was identified when around 5,000 documents failed to migrate.  In reviewing the error logs from OpenMigrate, the DFC call IDfSession.getObject() to retrieve documents from the repository resulted in errors.  After reviewing the stack trace, it was apparent that the error was being thrown from within the DFC code.  The team was surprised by the error since the documents were able to be retrieved without a problem using client applications working with a 5.3 DFC, such as Webtop and Samson.  The DFC error messages that were encountered are shown below:

Documentum Health Check

For many clients, one of our first projects is a Documentum Health Check.  This is typically a 2-3 day project where one of our technical architects will visit onsite to review all the different components of the Documentum environment.    We encourage this type of project as it allows us to be more pro-active with identifying possible issues rather than re-active when issues surface.  This post will describe the typical activities of a Documentum Health Check engagement as well as typical findings to give readers an idea of things to monitor in their own environments.