Friday, March 28, 2008

Documentum Training, Day 3

This took a while for me to post but here it is. And finally my notes for the Tech Fundamentals training for Documentum, day 3. This was a 3 day course. This will be followed my notes from the 2 day System Administration course. These are mostly just raw notes. Not intended as entertaining literature :-) Again, there are a lot of comparisons to Livelink here as that's the world I come from and understand as it pertains to ECM. Of course, I've also tinkered with Alfresco but nothing serious (yet).

Yumm. More free coffee.

Day 3

DocApps are self contained packages of repository objects. It used to be you had to write everything down that you did in QA then carefully moving everything to another repository (production for example). Now you have DocApp archives to handle migration. Excellent. This is something that was always missing from Livelink. Moving a form template in Livelink from QA to production is (still is?) a manual, scary process.

Use Document Application Builder (DAB) to create objects, lifecycles and other things. If you are writing your own application with WDK, then these objects would need to be created with DAB first. In version 6 this can be done in Composer. Not all features are included in Composer (yet). The new Composer tool is in Eclipse so we're all working in one tool. WDK is also in Eclipse but is a separate tool for programming and customization.

As I see it, aliases are sort of like a variable. Sounds like a parameter to me. Either way, it's a dynamic placeholder in a bigger process. Aliases go inside alias sets. And, they can be affected programmatically using DQL or DFC. Nice. These are basically just like Maps. That's interesting. Livelink has a similar dynamic variable ability within workflows. But, I think that's about it. Aliases in Documentum can be used across object types.

Pointer to documentation: Server fundamentals reference. Good for looking up how the server rules work.

I am really pleased with custom types in Documentum. The fact that when you create a "custom type" you can have dynamic attributes is a blessing. I am muy impressed. I could not do that with Livelink attributes out of the box 2 years ago.

Finally. Workflow. In my experience, this is where the ECM's bread is buttered. Can it hold up the Livelink workflow engine?

Workflow packages. Documentum supports multiple packages and a choice of mandatory or optional (using ProcessBuilder, BPM). Otherwise, it's mandatory packages. The built-in workflow package is content-centric. I liked the trainer's Star Wars reference for mandatory packages. If you don't have ProcessBuilder installed, just treat it as "this is not the document you are looking for" :-) I'm pretty certain we will use ProcessBuilder. I can't see a reason not to. I'd much rather have the extra options it offers rather than just the built-in engine.

Workflow forms uses XForms. w00t. And, it's part of the Application Builder. Thankfully not as "weird" as Livelink's. However, we don't get to do any forms here. That's another class. Hopefully my group can figure this out with taking the class.

Another thing I want to figure out is workflow reporting in Documentum. In Livelink, that was also weird and needed improvement. In Livelink, if you had 1000 open workflow instances, reporting against them was very hard to do. I like the availability of expressions making dynamic workflow designs easy in Documentum. However, I can see why they have a 4 day business process class. The reason they have all this power is the acquisition of the ProcessBuilder. It's truly full featured like other BPM's. Has Livelink changed to a BPM yet? Hmm..Will have to ask around.

Finally, we finished up with workflow. I love it (so far).
Then we did lifecycle. OK. Simple enough.
Then we did presets...easy. and useful.
That's all for day 3.
One more post on this will be my from sys admin class.

No comments: