Documentum – Upgrading to Documentum 7 in Three Weeks

Many of our clients have end of year deadlines for projects. One of our newest clients contacted us with an unprecedented challenge – could we upgrade them from 32-bit Documentum 6.5 SP1 to 64-bit Documentum 7.0 Patch 12 by early December given availability of certain funds.  This post will present the project and some best practices in regards to the upgrade.  Continue reading

Documentum Client for Outlook, Notes Connector, iPhone and other thoughts on Content Management and Email

One of TSG’s manufacturing clients is currently evaluating Alfresco for control and management of project related documentation.  (Proposals, CAD, Specs….).    In working with the client on proof of concept efforts this week, we came across a typical requirement for storing email and attachments easily within Alfresco.  In the Documentum world, many of our clients typically choose the Documentum Client for Outlook, Notes or some other 3rd party product that integrate within the email client.  For the manufacturing client, the requirements and approach was slightly different.

What about my iPhone?

Blackberry, Palm, Web-based Email, Gmail and iPhone, along with all kinds of other connectivity offerings for this global company, are all part of the equation.  It wasn’t really an option to pick one email client and offer integration from only that platform.  Also, from an IT perspective, integration into a desktop application like the Documentum Client for Outlook requires additional desktop support (not a positive).

‘Email Mode’ versus ‘Index Mode’

Another point consistent with the different email platforms was that a person in “email mode” was just looking to work through all their emails (first thing in the morning or after lunch) and didn’t really want to stop and index items into Documentum or Alfresco.  Notes and Outlook connectors, even with swanky drag and drop, can still require specific attributes (Client) and detail about files (what is that attachment?).

Consistent Indexing

One last point is in regards to the logic/screens behind indexing.  Does it make sense to have one indexing applications for emails, another for regular documents and perhaps a third for fax or scanning?  This is particularly true when custom lookups (client, job number) might require logic to look up and insure indexing is correct.

Easy Solution – How about the Forward button?

An elegant solution for the client was to leverage the Forward button from whatever email tool (iPhone…) to forward on the email to alfresco@client.com.  This way, we could technically say that email integration was available from any email device and kept the user in “Email Mode” rather than jumping into index screens.  A back-end process would monitor the email box and, based on the user id, place it in his (or another  group/individual) workflow inbox for later indexing.    The client also liked the idea of blind copying (BCC) the alfresco@client.com to save content and email threads going out as well. 

OpenInterchange  was built as an open source tool email tool for Documentum with this approach in mind.  By leveraging HPI for consistent indexing and some slight tweaks for Alfresco, the client was able to:

  1. extend email ingestion to a any email device or platform
  2. stay in “Email Mode”  and save indexing for later
  3. Avoid desktop integration
  4. Have one index application
  5. Save $$$ by leveraging Open Source

If you have any questions – please contact us a http://www.tsgrp.com/forms/contact-us.jsp

Documentum Upgrade – Understanding Impact of WDK Development

It has been TSG’s experience that the biggest effort in most Documentum upgrades is the compatibility of customizations made to Documentum interfaces (Webtop mostly).  While many of our clients choose to develop custom interfaces that migrate easily leveraging HPI or OpenContent, this blog post will only address Webtop customizations.

As detailed in our Planning Guide for Documentum Upgrade to 6.5 we recommend building an inventory all of the customizations made to core Documentum products before beginning the upgrade process.  When Documentum users upgraded from the 5.2.5 platform to 5.3, the smaller WDK customizations were simple to upgrade, but the larger ones were more difficult and time consuming.  With the move to D6 the same is true.  The complication factor depends heavily on what features the customization leveraged and if those features were modified in D6.   Below are typical customizations that should be reviewed prior to upgrading to D6.

Migrating Menu Customizations

In D6 menus are managed in XML configuration files and not in a JSP as in 5.3.  All menu customizations would need to be upgraded for D6.  EMC provides a set of steps to manually transform a JSP file to a properly formed XML by replacing tags from the JSP file with new XML tags. 

Documentum Composer

With D6.5 going forward, AppBuilder is no longer supported for Aspect and privileged BOF.  Documentum Composer is a new Eclipse-based IDE and allows for a well-defined plug-in model and a standard IDE with support for D6 features such as aspects and the Documentum Foundation Services.

Migration of Documentum 5.3 AppBuilder docapp archives can be deployed in the D6 environment with Composer.  Documentum Composer is capable of performing this migration by importing a 5.3 docapp and then exporting it as a Documentum Archive (DAR) which can be deployed with Composer.

composer

 Right Click Menu

The ability to right click menus is new in D6.  However, if there are custom menu options that apply to the files being selected, a new customization to add this menu option to the right click menu should be considered. 

Keyboard Shortcuts

This is also a new feature in D6, like the right click menus, it allows for the option to enhance the customizations to enable keyboard shortcuts to launch custom components.  There is a moderate level of effort required to add keyboard shortcuts to the defaults including an XML definition and a reference in the JSP.  This feature can be disabled entirely from the XML configuration if no keyboard shortcuts are desired.

Streamline View Customizations

The Streamline view is removed from D6 and any customizations to the streamline view will be lost upon upgrading.  The most common place to migrate these customizations is to the right click menu.  If the customizations were more comprehensive, a significant amount of development effort may be required to redesign the changes in the new interface.

Content Transfer Applet Removed

Earlier performance enhancements to UCF content transfer were discussed.  These modifications brings changes to the WDK and the potential for upgrade difficulty with specific types of customizations.  Any customization that leverages the content transfer applet will no longer be supported in D6.  This could potentially be a complex effort to modify such instances to use the UCF file transfer utility instead. 

Datagrid changes and additions

One of the most heavily modified components in D6 is the Datagrid. Enhancements allow for mouse and keyboard selection, right click menus, fixed column headers, and resizable columns.  Upgrading any WDK customizations that contain Datagrids will likely require some rewrite.  There is an option to disable all new Datagrid features from the app.xml, but this is not recommended since this will eliminate many of the improved D6 features.  Almost all of these upgrade efforts are contained at the JSP level and simply require updating tags to refer to the new D6 features.

Global Registry Considerations

Unlike previous versions, D6 requires one repository to be designated as the Global Registry.  This will be the central location use to store common objects used by all repositories such as SBOs, BOCS, and user settings.  If a Global Registry is already implemented, it can be used with a repository upgraded to 6.5.   When performing an upgrade to D6, all TBO and SBO objects need to be evaluated and a strategy to migrate them to the Global Registry defined.

Changes to DQL

There have been several minor changes to the behavior of DQL statements and execution.  It is unlikely that this will cause conflicts in customizations, but to ensure a smooth upgrade, any customized DQL queries in code or configurations should be evaluated.

  • Maximum accepted string lengths is now governed by maximum defined in the underlying rational database
  • The POSITION keyword is no longer supported
  • CHANGE…TYPE can now be used outside custom object types
  • Enhancements to the date literal allow for addition date formats.

If you have any questions or other input, please comment below.