Why DocApps are bad

January 27, 2009 at 5:23 pm | Posted in Continous Integration, Development | 4 Comments
Tags: , ,

A recent comment on one of my posts pointed out that you could script DocApp installs using an unsupported ant task. This is certainly a useful facility however it doesn’t overcome the basic problem with Documentum Application Builder and DocApps – they don’t integrate well with source code control systems that are used to maintain all the other code and artefacts needed to develop a working system.

Think how you probably develop code for your system. You probably store your source code in a repository (Visual SourceSafe, Subversion, CVS, etc.). You probably have integrations in your IDE to allow you to automatically checkout and checkin code. You probably build your code automatically from the source code system. This is is all fairly standard development practice (hopefully!).

If you are a little more advanced then maybe you also package and deploy your application automatically and you store automated tests in your source code control system. The tests would be automatically executed whenever you build and deploy from your souce code control system.

Basically the source code control system is the lynchpin of your whole development effort. Using version control and labelling you can see how different releases have progressed and maybe track where and when bugs were introduced.

DocApps sit completely outside of this setup, you are effectively using a development docbase as an alternative source code control system – without all the benefits of a properly featured SCC! In an ideal world all your Documentum configuration assets would live in the source code control system – that includes things like type definitions. Now all the source artefacts for your development live in one place. Hopefully this is exactly what Composer will allow you to do.


January 22, 2009 at 2:51 pm | Posted in Performance | 13 Comments
Tags: , ,

This question comes up so many times on the forums it’s time to add it to the blog. It probably helps to understand the role of the Documentum Docbroker (or Connection Broker isn’t it amusing how the marketing people insist on changing the names for these things but the old names live on in the code!).


Most of this information is in the Content Server manuals but a few definitions:

Docbase/Repository. A collection of content files and metadata that is managed as a single entity. Usually consists of one or more files systems and a RDBMS. Can also include an XML Store (from D6.5) and other more esoteric options like Centera. Some people include the Full-text index as part of the docbase.

Content Server. A server-based process (or set of processes is you are on *nix) that provides an API for clients to access and control the underlying docbase. Each server will access exactly one docbase, but each docbase could have multiple servers possibly distributed to different machines and maybe other parts of the world.

Docbroker/Connection Broker. Each content server will be configured to project connection information (what IP address and port the server is on, which docbase it serves). When client applications want to connect to a server to access a docbase they first ask a docbroker for the connection details. If they receive connections details they then connect to the correct server. The details of this are all contained within the DMCL connect or DFC IDfSession. Note that clients are configured with which docbroker(s) to connect to not which servers to connect to.


In a simple out-of-the-box implementation you usually have 1 docbase, served by 1 content server projecting to 1 docbroker all on the same server, so I’ll continue this discussion on that basis although it is easily extensible to more complicated deployments.

If you get the above error message then you can conclude that the client application sucessfully connected to a docbroker and asked for the connection details for a docbase. The docbroker however did not know about any servers that served the docbase.

A couple of questions to ask yourself are as follows. First, is the content server for the docbase running? Use Task Manager or ps to check that there is a process running. Usually the process is called documentum.exe (or just documentum) but earlier versions of the windows software used dm_serverv4.exe. If you have a machine with multiple content servers possibly serving different docbases then you have a slight problem as you want to check if the content server for one particular docbase is running. In Unix this is easy as the full command line is available in ps, but in Windows it’s more difficult. Process Explorer, formerly from SysInternals but now owned by Microsoft, gives this information.

If you know the server is running then you need to find out why the docbroker doesn’t know about it. First of all check the server log especially the startup section – there is a DM_DOCBROKER_I_PROJECTING message that tells you which docbroker(s) the server is projecting to. Is it the docbroker your client is configured for?

It maybe that the server has tried to connect but has been unsuccessful e.g. due to firewall problems. There will be an error message in the log stating the problem. You then need to work out what configuration must be changed to allow the projection.

The content server is unnecessarily picky about which IP addresses it binds to and I have seen issues with docbroker and content server on a machine with multiple network adapters where the content server is binding to one adapter and the docbroker is binding to another. Even though they are on the same machine they are trying to communicate on different IP addresses.

By working your way through this troubleshooting process you should be able to resolve 9 out of 10 (or maybe 99 out of 100) examples of this problem

Create a free website or blog at WordPress.com.
Entries and comments feeds.