Enterprise Content Management

Armedia Blog

Archive for the ‘Documentum’ Category

To D6 or "Deep 6"

October 16th, 2009 by bhunton

Most of us in IT can think of many things we would rather do than upgrade systems and software; for example, maybe take a nice trip to the dentist, or perhaps volunteer as the test subject in an IRS agent, audit training class.

If you finally have your Documentum 5.3 environment rolling along with good performance, then you probably don’t want to think about an upgrade, even though your current installation has been out of normal EMC support for a year. You may find yourself in Hamlet’s shoes, asking yourself whether to “Deep 6” the upgrade or to “take arms against a sea of trouble” and go for it. Wow! That really ravages the Soliloquy but you get my meaning.

I have been technically involved in Documentum upgrades since version 2. None have been trivial. EDMS 98 to 4i was tough because of the major changes in architecture. In 4i to 5, you had new WDK based clients, and the classes moved from dmcl to DFC. Web services were introduced. EBS still worked but it was in the gray area of support. What has happened to your custom Documentum applications? Did you have to build an interop so dmcl could still work in the new DFC world? Did you rewrite them? Maybe now is the time.

Fulltext Indexing switched from Verity to FAST. If you had millions of indexed content objects in Verity, you had to make a decision whether to blow the index away and start completely over, or to migrate it. Is your migration still running? Did you choose the mode unwisely? Oh, you use NAS instead of SAN? Ouch!

RightSite 4i went away too, leaving EMC customers with tens of thousands of broken anonymous links to repository content that required tedious labor to convert. Some of them have purchased Armedia’s Ligero which provides an easy solution to the problem of converting legacy RightSite links, as well as providing a very nice web content publishing/caching application.

The beat goes on, and we are well into the D6 product life cycle. The upgrade from Documentum 5 to 6 presents major challenges even in simple installations. Significant changes were introduced with version 5 that have come to fruition in D6. If you have a relatively simple Documentum installation, under version 5 you could probably ignore the global registry, ACS and BOF, even DFC properties up to a point. In D6 you have to pay close attention to them, because they are fully integrated. Their configuration can greatly affect your performance.

Then there is the move away from the simplicity of Tomcat, toWebLogic, to JBoss for the method server and ACS. How’s your heap? Then there are the new Documentum Archive (DAR) installations that replace the Docapp Installer. Then there is UCF, and, and…

And if all that is not enough to make your head spin like Linda Blair’s, there’s the sheer mass of the new installation binaries that must be downloaded from EMC then heaved to your host server. Do you have the additional storage and database space to handle it? Did I tell you that you need to go through repository sizing estimates again? Did I tell you that when it comes time to do the migration and upgrades you need to build into your schedule significantly more time to complete.

Your time is up! Documentum 6 is well beyond first ship date. It provides great features, functions, and flexibility. It is a suite of over 100 products and features designed for medium to very large enterprises. You need experienced architects, engineers, and integrators to design and build your system and to plan your upgrade. You need Armedia to get you through it.

TwitterFacebookLinkedInStumbleUponPinterestGoogle+DeliciousDiggPrintFriendlyShare

High Volume Server (HVS) Part1

September 21st, 2009 by dselvakumar

After hearing so much about EMC Documentum HVS, we decided to look under the hood to understand what the hype was all about.

What is HVS? Made broadly available in version 6.5 (you need to purchase the key) it is a generic term that refers to 3 broad areas of enhancements namely 1) Lightweight SysObjects (LWSO) 2) data partitioning and 3) scoping & batching.

This article will serve as an introduction to LWSO and the next article will deal with data partitioning and then batching & scoping. Stay tuned as the final post will deal with findings from base testing these enhancements.

LWSO share common attributes between parent objects providing the following benefits:

  • normalizes the object model,
  • reduces metadata storage space, and
  • enhances repository scalability.

It is important to note that LWSO are subtypes of shareable types which are subtypes of dm_sysobject. Many LWSO can share the same parent type.

When LWSO have a parent object the object is called unmaterialized (or dematerialized) LWSO.
Unmaterialized LWSO will have identical values for all the attributes of its shared parent.
LWSO get converted from unmaterialized to materialized when certain actions such as checkout, link, unlink, or etc are applied to the LWSO.

A materialized object does not have a parent and can become a parent for another LWSO object. Materialized objects are full SysObjects and are called private parent if they do not have any child LWSO. Materialized objects can be converted to unmaterialized objects by re-parenting them. Re-parenting maps LWSO i_sharing_parent attribute back to a sharable parent converting the object to a unmaterialized object.

Documentum provides the following for the manipulating LWSO:
DQL:

  • MIGRATE TO LITE (converts a dm_sysobject to LWSO),
  • CREATE SHAREABLE TYPE,
  • CREATE LIGHTWEIGHT TYPE.

DFC: IDfLightObject, IDfSession, IDfPersistentObject.

In the next article we will explore data partitioning and its implementation in the HVS.

TwitterFacebookLinkedInStumbleUponPinterestGoogle+DeliciousDiggPrintFriendlyShare

Retention Policy Consolidation

June 28th, 2009 by cschassler

One of the often overlooked challenges of electronic records management is the control and maintenance of retention policies.  This is particularly difficult if you are faced with a large number of members in your organization’s different record series categories.  Managed separately this means one retention policy for each individual record type.  If you only have a few different types of records to manage this is not such a big problem but it is especially difficult when you are dealing with hundreds of different types.  Additional complication comes in when you are managing permanent records that need to be archived to another organization such as NARA (National Archives and Records Administration). 

Careful consideration should be taken when creating an electronic retention policy design because trying to manage and control hundreds of retention policies that can have the tendency to change can become unmanageable very quickly.  The support and maintenance cost along with the compliance risk can eliminate your ROI and create a solution that fails to meet the goals for which it was designed.

One way to simplify and try to reduce the overhead associated with managing so many different policies is to group schedules together within your series according to their function or another applicable categorization scheme and their dispositions. 

The following basic strategy is an example of how this can be accomplished:

  • Create “buckets” representing the high-level record series areas.
  • Group record series members within the “bucket” into categories based on function and comparable disposition schedules.
  • Define and assign a common disposition strategy to each functional area that is representative and compliant for all record series members.

This concept is probably better understood using a simple example, lets use the following scenario as an illustration:

  • You have 5 different high-level record series groups.
  • Each series group has 100 individual members.
  • The schedule for each member ranges from temporary dispositions of 1 month to 10 years to permanent records with a duration of 25 years or more.
  • Each of the record series contain members that share a common purpose or function.

Using this example some basic consolidation steps would be:

  1. Define each high-level record series group as a separate “bucket”.
  2. Within each bucket you can create categories based on function such as whether the members are administrative, case related, procedural, etc.
  3. Within each of these sub-groups you would start to combine your applicable members based on corresponding disposition schedules.  For example, within a record series “bucket” if you have 25 members that are administrative records and they have temporary dispositions with durations ranging from 3 months to 5 years you can create a single retention policy with a disposition strategy of destroy/delete after 5 years and include each of these members under the policy.  By doing this you only need a single policy that can apply to 25 members instead of having 25 separate retention policies.
  4. Follow a similar process for each high-level record series and you can turn, what was in the case of our example, 500 individual retention policies into a number that is much more manageable making it easier to control and disposition your formal records.

Some items to take into consideration when consolidating retention policies are:

  • Work with your records managers and any outside agency, such as NARA, you archive records to before implementation, make sure you have their buy-in for the initiative.
  • Identify the special record series members and handle them separately with their own policy as needed to help reduce compliance risk.
  • When grouping record series members within a retention policy based on disposition schedules be wary of regulations that can be applied, it is generally best practice to only hold certain records for as long as necessary and no longer.
  • Designing an automated process for declaring formal records which will reduce workload and provide a better user experience for your records contributors/managers.  If you have or choose to implement an automated formal records declaration process you can provide more flexibility and room for growth by using an XML file or table to map the individual record series members to their applicable location in the formal file plan where the retention policy has been applied.
  • Consider structuring/restructuring your formal file plan after the consolidation strategy and apply your retention policies at the applicable level and allow the policy to be inherited by all formal records within that section of the file plan.

This information is an example of how retention policies can be simplified but in practice it is best to err on the side of caution.  Make sure you have the right people involved and do not put yourself at risk.  The goal is to reduce your overhead while minimizing risk and maintaining compliance.  You probably made a significant investment in your electronic records management solution and you need to be sure to keep the protection and savings that a solid design provides.

TwitterFacebookLinkedInStumbleUponPinterestGoogle+DeliciousDiggPrintFriendlyShare

Producing Quality Given Time Constraints

June 6th, 2009 by jbowling

The schedule is an ever present aspect of application development. Engineers must constantly balance producing quality work against given time constraints. This is why most engineers are constantly searching for tools and techniques that allow them to deliver more quality work in less time. Techniques, like software patterns, focus on the quality aspect of the software while many tools focus on productivity. When an engineer finds something that allows him/her to both increase productivity as well as improve the quality of work delivered, it deserves special attention.

Code Generation is writing code that writes code. When used properly, it can dramatically reduce coding time. It also stands to reason that a greater degree of thought goes into the generated code and that it is likely of higher quality than an equivalent body of hand written code.

In layered software development, one area that is ripe for code generation is the data access layer. The DAO/DTO pattern is a well known and used in the industry. Couple that with the fact that most data stores provide self-describing features for the data structures and it provides a perfect opportunity to utilize code generation.

Enter Armedia CodeGen. It generates DAO’s and DTO’s for Documentum types. It utilizes DQL within the DAO’s for optimal performance (see Rahul Raina’s May 24th, 2009 blog article). It generates JUnit test cases to verify the CRUD (create, read, update, delete) frunctionality for the generated DAO’s. Having test cases to verify/validate the data access code verifies the code is in sync with the objects and their attributes in the repository. It is highly unlikely that a project hand-coding data access would afford the time to write test cases for the data access layer.

In a Documentum application with a large number of custom types, Armedia CodeGen can dramatically shorten development time, while providing more consistency and quality than will be achieved by hand-coding. For a limited time, the Armedia CodeGen is available as a free trial. Visit http://www.armedia.com/products/generator.htm and follow the forum link.

JB

TwitterFacebookLinkedInStumbleUponPinterestGoogle+DeliciousDiggPrintFriendlyShare

Reveille RealTime for Documentum?

May 6th, 2009 by A.J. McClary

You may have heard of the Reveille Management Console for Documentum D5/D6 and Reveille for Captiva InputAccel – the only solutions that can proactively and automatically monitor, diagnose and repair your DCTM/Captiva installation, but what is Reveille RealTime (RRT), how can it help you (and when can you get a live a look at it)?

With this latest offering from Reveille Software and Armedia, RRT adds to the Reveille Management Console for Documentum, bringing a new level of performance and experience monitoring. With RRT in the DCTM Webtop and Taskspace application environments, you can now measure and track EACH and EVERY user’s performance and know instantly if your system is delivering your Service Level Agreements (SLAs) and if there are problems brewing with your installation. With RRT you can now see problems down to the finest of details –such as “how long is it taking EACH of my users (and ALL my users) to login in to my environment” and “what is the average time for document check-in for all my users and who are the specific users that are not seeing good performance and not meeting my SLAs.” With RRT you also get the great Reveille ability to not only diagnose a problem, such as the job queue is stalled, but proactively fix those problems.

Interested in a demo of Reveille RealTime? We will be at our booth, #122 at EMC World and we also have a Webinar for Reveille RealTime on June 2. See the website for details!

TwitterFacebookLinkedInStumbleUponPinterestGoogle+DeliciousDiggPrintFriendlyShare
Copyright © 2002–2011, Armedia. All Rights Reserved.