Documentum’s out of box Webtop allows for its administrative users to manage groups, and the users that belong to each group, while within Webtop’s user management section. As a default, the groups and its users are presented in a datagrid along with individual descriptions, if provided. Sometimes, however, clients will find it useful to expose additional user information on the datagrid (such as an email) to accompany the name and description columns already implemented. Such a task is possible with a few tweaks to the GroupList component and its dependent files.
Posts Tagged 'Webtop'
Tags: Administration, Column Preference, Customization, Development, WDK, Webtop
Tags: Consistency, data integrity, Documentum, OpenMigrate, portal, PUMA, Webtop
TSG has several clients using Documentum as a repository and a custom front end application for consumption of the records or renditions of records. In most cases there is a mechanism in place such as SCS (Site Caching Services) or TSG’s OpenMigrate PUMA (See CIS Case Study for more details). While a typical Documentum application (ex: Webtop) provides a “one stop shop” for authors and approvers, the interface can be challenging when “consumers” are just looking for quick search and retrieval. This solution provides improved performance, business continuity, and ability to add documents from other systems. One potential risk to using a cache of documents and metadata for search and retrieval is the integrity of data. Publishing techniques are designed to accurately cache records; however there are uncontrollable circumstances that may result in a mismatch. Continue reading ‘Documentum to Portal Consistency Checker – Proof of Concept’
Documentum Client for Outlook, Notes Connector, iPhone and other thoughts on Content Management and EmailPublished December 4, 2009 Alfresco , D6 , D6.5 , Documentum , ECM Landscape , HPI , Open Source , OpenInterchange , Tech Tip 2 Comments
Tags: Alfresco, Documentum, Documentum 6.5, Webtop
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?).
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 firstname.lastname@example.org. 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 email@example.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:
- extend email ingestion to a any email device or platform
- stay in “Email Mode” and save indexing for later
- Avoid desktop integration
- Have one index application
- Save $$$ by leveraging Open Source
If you have any questions – please contact us a http://www.tsgrp.com/forms/contact-us.jsp
Tags: Alfresco, Documentum, Migration, OpenMigrate, Webtop
In the content management world, users often require an “all-in-one” interface to help them assemble batches of related documents, tag them with metadata , then import them into the underlying Content Management System. Traditional web-based interfaces, such as Webtop or Web Publisher from Documentum, Explorer or Share from Alfresco, don’t offer this functionality out-of-the-box.
Could TSG’s OpenMigrate open source migration framework fit this need?
OpenMigrate is typically used in a batch mode, especially in high-volume situations. And while the browser-based Administrator does allow for interactive configuration and execution of migrations, the actual tagging of documents with metadata is outside of its realm.
To bridge this divide, TSG is pleased to announce the availability of the new OpenMigrate Bulk Load Interface for download.
The OpenMigrate Bulk Load Interface provides a highly configurable user interface which enables the user to easily manage documents and import them into a variety of targets. The interface is built on top of the Spring framework making it extremely easily maintainable, customizable, and configurable.
To learn more about this versatile new entry in the OpenMigrate toolset, please visit www.tsgrp.com.
Tags: D6, Documentum, Documentum 6.5, Documentum Upgrade, EMC, WDK, Webtop
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.
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.
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.
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.