Comments on: Old Documentum Architecture Habits are Hard to Break

By: Robin East

Robin East — Tue, 02 Sep 2008 12:48:00 +0000

Chris, your 3rd point is an interesting one. I suspect that deprecating docbasic is not quite the same thing as supporting documentum’s own legacy code. D6/6.5 provides a DMCL/API layer as part of DFC and there is no reason why that won’t continue to be provided for the forseeable future (I pity the developer who has to convert the object replication code into Java!); it’s just you won’t get support if you log calls when trying to develop against the unsupported API.

What are the alternatives? Well I’ve been playing round with jython as documented on my blog. It could do with a dctm package to make it really as ‘user-friendly’ as docbasic or iapi. Maybe I’ll start one some time but right now I don’t have the time (anyone else?)

By: Pie

Pie — Mon, 21 Jul 2008 15:17:22 +0000

Chris, I agree with you 100%. A book could be written on the junk DNA in Documentum and some of the older ECM systems.

-Pie

By: Chris Campbell

Chris Campbell — Mon, 21 Jul 2008 14:24:58 +0000

No mention of the “junk DNA” that is still floating around in the workflow sequencing? With more emphasis on TCM in this iteration, I’m surprised that an update to the core objects hasn’t been done. My number one gripe to this today is the fact that dm_activity doesn’t have an instance object. Workflow objects, workitems, packages, and even queue items have instances, but not activities?!? Oh, the things I could do if only these shackles were removed!

A close second is the lack of a two-way referencing workflow objects. Often it’s just one-way or you have to construct methods to find out the relationship between a package and a workitem. (Note to self: consider constructing a custom database view to take care of this problem.) Call me lazy, but I’d be a happy guy if I could get all the workflow info I needed without having to fetch and query ten objects to get what I need.

There’s something to be said for backward compatibility, but at some point you need to cut the purse strings. I think the move to a lightweight sysobject is a HUGE step in the right direction. Personally, I like the way it’s designed and from Victor’s talk at EMC World, it seemed to me that the design also encouraged people to make the change willingly.

One last thing, before I turn this comment into it’s own mini-blog. In the 6.5 documentation that I’ve peeked at, is the first mention that Docbasic is being deprecated. It’s only one sentence, but carries a lot of weight. So much of 6.0 and 6.5 still runs on Docbasic to handle behind the scenes stuff that I’m wondering how EMC is going to pull this off. As much as I love Docbasic (and it’s a guilty pleasure to quickly script something in Docbasic) that little bit of software is the definition of Junk DNA. How do you get rid of Docbasic? Do you replace it and with what? That might be something to look at…

By: Pie

Pie — Sat, 12 Jul 2008 11:59:25 +0000

James, I agree with your points. I added the trust piece. I work with many organizations that have a limited staff and they can’t separate duties as much the average security person would like. For them, trust is important because they don’t have a budget to spread the duties out.

The key is validation. The concept of a key that validates the log entries is a good one that should be investigated. If purges are strictly limited from the log, you could have your validation as a simple check could see if an entry was missing or altered.

-Pie

By: James

James — Sat, 12 Jul 2008 10:24:20 +0000

Laurence, my comment isn’t about trust but more about security practices that should be about least privilege, separation of duties, etc.

I could “trust” someone to have access to both accounts payable and accounts receivable but that still doesn’t make it a good idea….