Documentum D2 – Thoughts on the Content Library Use Case

We recently helped a client with a difficult implementation surrounding the “Content Library” function released back in April with D2 as a primary client.    The use case is focused on managing project deliverables for large-scale multi-year projects.  This post will describe some of the client’s struggles and our overall thoughts.

D2 – Business Issues with the controlled nature of project documentation and deliverables

In contrast to the typical Content Library use case discussed by EMC, our client’s use case involved maintaining approximately two decades of  project documentation. The organization of information was built upon a legacy structure with minimal property (metadata) values, instead using deep and complex folder structures.

Some of the D2 usability issues with our particular use case included:

• The D2 interface and had a performance impact of displaying the large number of cabinets and folders.  This was similar with Webtop.
• Navigating deep folder paths was limited: Project folders can contain multiple sub-project folders
  • Moving between D2 iframes can cause the adjoining frame to reset causing the user to have to browser back down the folder path again
  • D2 has a default limit for displaying folders and documents, it can be increased but resulted in a performance impact
  • A folder may contain a large number of documents and since they cannot all be displayed, the user must use the widget filter to find the documents they are interested in
• Searching for large number of documents
  • quicksearch –  given the large number of documents, the search would product too many results and was difficult to filter/navigate.
  • advanced search – client wasn’t happy with a “build a search” approach due to the time to create a search. We highlight the build approach in a D2 video in the learning zone.
• D2 is unable to display a custom property on a check-in widget
  • This forces the user to check in the document, navigate to it and then update the properties on it; very inefficient for the large volume of documents.  A better approach is to require properties to be added as the document is being uploaded.  See a demonstration of how this is accomplished HPI add documents in our learning zone.

D2 – Technical Issues

Our client struggled with a variety of different technical components.  For background, this diagram from the D2 4.1 architecture white paper from EMC shows the deployment location of the D2 components.

As presented above, the multiple D2 components result in longer deployment timelines and often significant troubleshooting efforts.  This complexity is also discussed in our earlier blog post on why D2 has not replaced Webtop and in a post from Scott Roth on his experiences with installing D2.

For our client, the complexity results in:

• Ongoing issues with D2 DAR installations due to a non-dmadmin install owner.
  • We recommend clients utilize the default dmadmin install owner whenever possible.
• Continued struggles with the stability of the JMS – hangs and has to be restarted
  • As a proactive measure, the client implemented a weekly restart process for the Documentum stack
  • The D2 web application requires a restart after the JMS is restarted to prevent caching issues
  • We open an SR case with EMC for each occurrence to help root cause the issue.
    • Root cause determination has proven very difficult since the JMS hang has not been predictably reproducible.
• Various user and document session time outs
  • session management and time outs are configured and adjusted in multiple locations
  • large file transfers can result in time outs if they exceed the 5 minute transfer connection limit

The following sections summarize additional areas of complexity for the ongoing management and customization of D2 for our client.

D2 – Complexity of Deployment

Some of the items our client struggled with in regards to deployment included:

• Java Dependency on the Client
  • A Java Applet is used for content transfer, including bulk export of folders and content
  • HTML5 transfer can be used for content transfer, but not bulk export of folders
  • Specific Java versions are required for both D2 4.2 and 4.5; auto-updates can install unsupported releases and the correct Java needs to be re-installed
  • IE9 must use the Java Applet since it cannot handle the HTML5 transfer
• Lock box configurations control the encryption of the communication between D2 and other Documentum Modules
  • The lockbox must be configured on the Content Server, Web Application Server, and ACS and BOCS servers
  • Simple in concept, but its easy to slightly miss-configure.  Administration should ensure the same password is used in the lock box steps or configuration utility
  • Administration should ensure the library files to encrypt and decrypt communications are stored in the proper directories in the JMS, Web App Server, ACS, and BOCS
• D2 utilizes a custom DFS framework, D2FS, that interacts with the JMS, this is unlike the application architecture of WDK apps such as Webtop
  • Unlike the DFC API, which interacts with the Content Server, the D2FS API interacts with the JMS
  • JMS Components run the D2-API methods that are installed as part of the D2 DARS; runs the plug-in jar files for C2, O2, D2-Bin, D2-RPS, and D2-BOCS
    • Within the D2 D2FS API Javadocs is a listing, similar to the DFC, describing all the classes available for customization of D2
  • The JMS Encrypts and decrypts D2 communictions
  • As part of an upgrade or patch, older files need to be deleted/removed from the JMS
• WAR file components include DFS and application components
  • The D2 and D2-Config web applications are built by the D2 Install Application, the WARs are then transferred to the web app servers for deployment
  • Additional D2 plugins must be included in the WAR build. These are the C2 (PDF overlay/watermarking), O2 (email), D2-Bin (recover files), D2-RPS (retention), and D2-BOCS
  • D2 application configuration files can be included in a deployment on installed separately.
    • In order to simplify deployments, our client does not include a configuration in the WAR.
  • DFS (Documentum Foundation Services) SDK is required to build the D2 and D2-Config WARs
    • D2 utilizes the DFS SDK to include lib files in the WARs it is dependent on the DFS libraries.
• DARs and hardcoded install owner
  • The basic D2 deployment includes 3 DAR files: D2-DAR.dar, D2Widget-DAR.dar, Collaboration-Services.dar
    • Plug-ins for D2 require deployment of up to an additional 5 DARs
  • Our client used a different Install Owner than dmadmin and this has caused an issue with deploying D2 4.5.
    • Deploying the DARs resulted in ACL and object ownership being changed from the Install Owner to dmadmin leading to a mix of ownership for DAR related objects.
    • This causes an issue when installing a DAR using a nondmadmin file that overrides the default dmadmin owner, with mixed ownership, these DAR installs fail
    • In order for the DARs to install successfully, anything where dmadmin is made an owner of the object, the owner must be manually corrected to our client’s Install Owner name

D2 – Complexity of Troubleshooting

The complexity our client experienced while troubleshooting included:

• Multiple Logs to check and review for outages, performance, or user reported issues
  • D2.log, D2-Config.log, D2-JMS.log, server.log and web application server logs
• Multiple repositories in one Content Server/JMS instance
  • When one repository becomes unresponsive in D2 but others are available, restarting the JMS and web app server impacts all hosted repositories
    • The root cause for the unresponsiveness has been difficult to identify
    • The JMS and web app server should be restarted together;
      • just restarting the JMS can lead to issues with D2 reporting errors, just restarting D2 often doesn’t resolve the issue
• After a restart or upgrade, users need to clear the D2 cache on the local client machine to prevent D2 error messages
  • When users encounter errors, they have been instructed to do a hard reload in the browser – Ctrl+F5
  • The hard reload purges the browser cache and prevents users from getting errors after a restart of the D2 web application server

D2 – Complexity of configuration

The complexity of configuration our client experienced included:

• D2 Applications provide context for the users
  • D2 uses an Application construct in order to group D2 configurations together, for example the D2 example HR Sample Application available on the EMC Download site.
  • Configuring a D2 application can explode into an examination of the business processes for a set of users. If this activity was not planned or the BP doesn’t fit into the configurations of a D2 application, the D2 web application may be difficult for users to adopt.
    • This is particularly an area of concern our client is experiencing. They require a broad Webtop-like D2 application in order to accommodate their legacy Documentum data. Many configurations, such as Folder Import, require specific configurations which identify rules for filing, security, and functionality based on document metadata values.
• Parent / child configuration dependencies are common in configuring D2
  • Many configurations are dependent on a prior configuration existing in the D2-Configuration for a D2 application
  • An example is one our client encountered when trying to configure Folder Import. The folder import requires an Autolink configuration and Security configuration.
• Enabling configurations / Caching configurations
  • The dashboard matrix for D2-Config allows a config to be very focused or very broadly applied.
  • There is not a default configuration akin to a “Webtop” configuration. D2 requires discussions and decisions on what to configure as a default or more specifically for a D2 application
• Troubleshooting configurations
  • The dependency issues can be difficult to understand and troubleshoot, for example why is a menu item is not displaying for a specific user group for a specific D2 application
  • D2 4.5 now offers a way to export the specification so it can be compared to other exported specifications

D2 Development Limitations

During the rollout of D2 the client discovered specific limitations to developing add-ins for widgets and D2.

One was a custom feature built for Webtop, Folder Move Confirmation. Due to the D2FS service architecture, it was not possible to replicate the function in D2 as it was not possible to interrupt the move process and prompt the user to continue or cancel.

A second example is maintaining attribute filter values in a doclist widget.  The widget is triggered to reload a list of documents after the user performed an action on one of them. Unfortunately, on the reload the filter entered by the user was lost. The user must then re-enter the filter information to reduce the number of documents displayed in the widget.

• D2 4.5 APIs
  • D2FS Java API
    • Unlike Webtop, D2 relies on a custom version of the DFS built specifically for D2.
  • SOAP Services (legacy)
• D2 External Widgets
  • Must be a separate web app accessed via a D2 iframe
  • Limited cross-communication is available between iframes
  • Limited event listeners must be used

Summary

The key takeaway from our work with D2 is discovering its architectural complexity and the issues if everything isn’t addressed.  Complexity included installs and configuration for the Content Server, Java Method Server, Web Application, Plug-ins and repositories. These should be carefully planned for and addressed. The complexity of D2 necessitates planning the deployment with careful thought to D2 configuration and on-going maintenance and troubleshooting. On the positive side, D2 does provide an opportunity to configure many actions based on business process and document metadata however the business must be aligned with it in order to utilize this capability.

We are interested in hearing more about your thoughts on D2, please leave your comments below.

For additional information, please find these related D2 articles in our blog.

• Why has D2 failed to replace Webtop
• D2 – What are some of the Limitations
• Documentum Webtop Migration – xCP, D2 and other thoughts
• Documentum D2 4.0 – Initial TSG Review
• Documentum D2 4.0 – Risk Mitigation Strategy
• Documentum D2 and EMC Professional Services
• EMC World 2012 – May 23 – More on D2