Inside Documentum

Troubleshooting weird DCM messages

This came up on the ECN forum today and the message is so obscure (but quite common) that I thought it worth writing up the troubleshooting notes.

The original post is here. The poster was trying to create a Change Notice or Change Request in Documentum Compliance Manager (DCM) and got the following error message in a dialog box:

The System can not complete your request. The action you have chosen is no longer valid because of a change in repository

This seems to be a generic message that DCM pops up whenever an ‘onexecutiononly’ pre-condition check fails.

What’s a pre-condition?

A pre-condition is a framework built into Documentum WDK (the framework that DCM, Webtop, Taskspace, WebPublisher, etc are built on) that allows menu options to be programatically turned-on/turned-off/greyed-out/hidden in the browser interface. To give an example a developer may have created a component to display the contents of a folder and for each entry there can be different menu options available such as View, Edit, Check-out, checkin, Create PDF rendition and so on. Now if a document is not checked out it doesn’t make sense for the checkin option to be available. In fact it would be just confusing if that selection was left available (WDK applications tend to be confusing enough as it is). So a pre-condition is a piece of code that can be run for each item which will return either true or false to decide whether a menu option is available.

What’s an ‘onexecutiononly’ pre-condition?

With great power comes great responsibility! Imagine you have 100 objects in a folder and you have 40 or 50 menu options for each one (not untypical). That’s 4,000 – 5,000 pre-condition checks. If the pre-condition code just does calculations and checks based on information available or cached on the application server then generally this is not a problem and your UI should remain pretty responsive. However if your pre-condition runs a query against against the content server, however ‘fast’, or does an object fetch (e.g. using IdfSession.getObjectBy…()) then you are going to suffer some pretty sluggish UI performance.

The WDK references do warn about this in the section on pre-conditions however it seems that this warning was not heeded in DCM 5.3 (naughty EMC). Generally navigating around DCM5.3 is pretty miserable for most productions users and the best that can be suggested is to upgrade to DCM 6.x (by the way if you absolutely have to stay on DCM5.x but can bear some development and testing effort to alleviate the pain then there are some code-based possibilities).WDK 6 introduced a new pre-condition setting – onexecutiononly – which was taken up by the DCM developers to ‘fix’ the performance problems they had introduced.

‘onexecutiononly’ means that the pre-condition is not evaluated when the list of objects is rendered onto the screen but only when the user selects the menu option in the user interface. As a result you no longer have 1000s of pre-conditions running when rendering the interface. Of course in a way this rather ‘neuters’ the power of the pre-condition because now we could have, for instance, check-in available for documents that aren’t checked out. If we try to checkin the document the pre-condition will return false and we will get a warning message on the screen. Typically like the one the poster saw when trying to create a change notice or change request. In that particular case there are likely to be some checks in the pre-condition code for a newchangerequest or newchangenotice action and they have ‘failed’. At the time of writing the problem hadn’t been fully resolved so I’ll update this entry if any new information comes to light.