When designing Content Management System for an organization, the architects inevitably spend time designing the Taxonomy for the content. It is enormously important from the business stand point to organize the content to be able to logically access it the way we would find paper based files in the huge locked away cabinets (this very line exposes the disconnect).
Now, I am here to question the ROI on this.
Often times it becomes necessary to know which Docbases a Docbroker is aware of. One of the typical scenario’s that this becomes necesssary is when you are at a client’s site and the connection to docbase is not happening and you need to be doubly sure that the docbroker is not just up, but it knows of the docbase you want to connect to. And ofcourse, if you need any health check scripts, this comes handy.
Anybody who worked with Documentum’s DTS know that it comes with variety of issues. One of the challenging ones I had to face was to do with performance. Here are some pointers that I learnt from this process:
DTS is multi-threaded:
Its exciting to know that DTS is multi-threaded and that it can take advantage of a dual CPU Servers. But listen to this - threading is limited by the plug-in and/or application being used to perform the transformation. If there are 2 documents being processed by DTS and they both use the same plug-in or application, then the processing is *serial*. If they use different plug-ins and applications, then the processing is concurrent. With MS format documents dominating in numbers in most organizations, multi-threading is not truly used.
Its always been a challenge to debug LDAP-Documentum integration in any given Documentum implementation. This article is put together to share some of the debugging techniques I used over time to identify and resolve the related issues.
