RMA is typically slow and recently we were asked to make it faster and explaining the WDK stack is not why we were brought in. The application consisted of custom everything (menu items, functionality, workflows, lifecycles, alias sets, object types, complex security model, yada yada yada) that extended RMA. The environment is Documentum 6.5 SP2 on Solaris with Oracle and Web Logic is the Application server.
We started by reviewing the application’s design and certain use cases that manifested the performance issues.
Here is a collection of what we did that would either confirm our suspicions or give us another starting point:
It was year 2004, when I was first introduced to EMC Documentum. As I first fired up the DAB IDE, I felt man this IDE is Unintuitive, slow and cryptic. Apart from learning the DFC API’s in Documentum, getting accustomed to DAB itself was an excruciating experience. Finally after three years Documentum Composer came as a savior.
I liked Documentum Composer for 3 main reasons:
Anyone who has ever attempted a data migration knows that there is no such thing as ‘a smooth transfer of power’, as it were. From learning both the legacy system and the new system, business processes, data clean-up, data mapping, deciding between existing tools and creating new ones, there is a lot to keep track of to ensure that what you have at the end matches what you started with.
Migrating CAD engineering drawings poses its own set of unique challenges. AutoCAD and MicroStation drawings can internally have references to other drawing files that exist within the cms (or content management system). When moving these files over to a new system, care must be taken to ensure these references are maintained.
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 Documentum 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.
Good day, all. For all who are celebrating Memorial Day, we wish you the best & pass along our respects to our servicemen and women of past & present.
Today’s topic will cover some simple advice on how to extract more performance out of your Content Server by simply changing the way you ask it questions in your code. Documentum offers plenty of advice on how to trim & tune your Content Servers, but the simplest advice that goes the longest way is: Use DQL.