The Least of Many Evils

I have a production install this Friday, and I’m trying to put together everything for the turnover. One problem with Documentum’s Application Builder (DAB) tool is that it doesn’t install everything–especially permission sets–that I’m using heavily for this app. So I’ve spent the last few work-days looking at various ways to manage the move from dev to qa to prod. I’ve done this a bunch of different ways over the years, and no approach has been completely satisfying.

• API/DQL Scripts — Documentum comes with tools like isql and sqlplus for interactive sessions using a SQL-like language or the underlying DMCL API. Both tools will take files as input, and every platform has these tools. The good is offset by the bad–no control structures. It’s a matter of faith (and luck) that the scripts will do the right thing when run on a partially-configured system.
• Real Programs — I’ve written some smart programs to assess the state of the docbase and do the right thing. Languages like perl and python can make for some sophisticated scripts, the latter even using the Java API (DFC) within Jython. Greater control comes at the cost of greater complexity, a good thing when there’s time to test. Not having that, I’m reluctant to go into full-blown development mode.
• Manual Creation — The ultimate fallback position is to print out my spreadsheets and build everything outside the docapp first in the administrator tool. It allows me to be the ultimate control structure which in theory needs minimal debugging. I don’t really want to spend my entire Friday night with a flaky web application and a docbase that’s had more work with less positive effect than Joan Rivers. The upside is I’m less likely to need that special shampoo after this kind of Friday night date.
• Dump and Load — Another tool can serialize (or in python-speak pickle) any Documentum object and even pulls out all related objects for reinstantiating in context. It’s not good with large docbases, and it has a history of bad behavior when running over Sybase. Worst of all, it often brings too much context; all kinds of other things will come along for the ride that will require removing by one of the other methods elaborated here.
• dm_procedure — I’m not a docapp alchemist, but I do know that it can run snippets of client code called dm_procedures before and after various stages of installing a docapp. Unlike every other approach, this one integrates the execution into installing the docapp. I like the turn-key approach since ideally I should be handing this over to an application support group rather than doing it myself. That either requires me documenting the pants off the install or having something simple and mostly foolproof. The enormous downside is that these code snippets are done in docbasic, a dumbed-down version of Visual Basic that includes functions to use the DMCL API. Those functions take string arguments that are concatenations of method names, identifiers for sessions and objects, and plenty of arguments. Doing DMCL in perl is painless with variables embedded in strings, but in docbasic it’s a real pain

I’ve done all of these things before, usually with more time and never with wonderful results. I refuse to just choose the least of many evils though; before calling it a day I started looking into calling the Java API (DFC) from within docbasic.

I’m not a huge fan of the DFC; it has some of the things I hate about Java in spades: unwieldy long names, class and method proliferation, and it attempts to be helpful to beginners at the expense of the flexibilty experts need. There are a few good things about DFC programming; an IDE like Eclipse brings some nice debugging and program-by-numbers features like code completion. It’s also getting harder and harder to find other API programmers, so the DFC has become my Lingua Franca with other, newer Documentum people.

Of course the IDE stuff doesn’t work for Java embedded into docbasic code. I’ll take a few hours tomorrow to see if docbasic takes some of the drudge out of DFC programming like Jython does, add a few generic dm_procedure/docbasic/DFC templates to my library, and at least know why never to do something like this again if it doesn’t work.