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. Continue reading ‘Documentum 6.7 Upgrades and Hardware Changes’
Archive for the 'D6' Category
We stumbled across a pretty vague reference in the cross-product dependency guide for Documentum 6.7 SP1 (on page 245) for Webtop (emphasis ours)
“Note: Documentum Collaborative Services 5.3 DAR is installed with Content Server 6.7 SP1 repository so Webtop 5.3 & 5.3 SPx will work with Content Server 6.7 SP1. If Documentum Collaborative Services (formerly Documentum Collaborative Edition) 6.7 SP1 DAR is installed with Content Server 6.7 SP1 repository, Webtop 6.7 SP1 is required.” Continue reading ‘Documentum Webtop 5.3 running on Documentum Content Server 6.x’
We had a client last week struggle with a DM_DFC_E_BAD_CLASS when deploying Webtop and our OpenAnnotate product along with our DFC based OpenContent. The issue arises from the CLASSPATH having the file “dfc.jar” added to it. We thought we would document the thoughts here for other client’s reference.
Tags: D6, Documentum, Documentum Upgrade, OpenMigrate
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.
Continue reading ‘Documentum 5 vs. 6, Databases and Dates: Does Anybody Really Know What Time It Is?’
Unveiled with D6 in 2007, Documentum Foundation Services (DFS) was the service-oriented replacement for the Documentum Foundation Class (DFC) and the Microsoft specific Primary Interop Assembly (PIA) including lingering components of the original Documentum API still embedded within the DFC. With the announcement at EMC World that the new development environment will be a REST based API built on the DFC, Documentum customers might be wondering about the future of DFS. This post will discuss the different web services approaches and present some TSG thoughts on the subject of the DFS as well as the upcoming REST API.
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.
Often times Documentum users, frustrated with Webtop Search or Advanced Search will request “Can we just have a Google Search?”. This post will provide input to Documentum developers on how to best address this ongoing request. While this post is specifically focused on Documentum developers, lessons learned about interface design apply to our Alfresco and SharePoint readers as well.
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.
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:
Every couple of months we like to step back and offer a “What’s next” post in regards to our thoughts on what Documentum customers should be considering with their implementations. For this post, we will highlight our thoughts based on a thorough review of EMC World and our client briefing discussions. Continue reading ‘Documentum – Top 12 Tips’
Though-out EMC World, one of the main themes in many of the product presentations (xCP, MyDocumentum…) was a focus on configuration versus customization. As a buyer of Documentum software, it is easy to see why configuration can be better than customization as it: