Change Destination with TBO

thomas.hasler

I am quite new to Documentum i need some help.

The idea is that the users work with a few views and check in documents in that views. But i want to put the documents in some kind of data pool and only link them in the several views.

Example:

I have a Cabinet /Data where all the Documents should be saved.

The users work with views like

/Projects/Projectnumber/Projectname

Whenever a user checks in a document in this structure, the document shoud be saved in /Data and only the link should be in /Projects/Projectnumer/Projectname...

Can somebody help me out?

Chris_Campbell

What you're asking for is fairly simple, the only catch is to make sure that it's done properly. I'll divide my answers into two messages: the first dealing with the specific problem, and the second dealing with the strategy that you're currently using.

At first glance, you'd think that you would want to override doCheckin. As we say in Texas, that's like closing the barn doors after the horses have gotten out. The link to your desired folder when the document is first created or imported. That's going to be overriding doSaveAsNew. Once the link is established (ie "link,session,obj_id, folder_ specification|alias") for your document, you never have to worry about it again.

This is going to be your best approach if all your documents are currently in your /Data directory and you want to automatically handle any new stuff coming in. Now, if you want to get fancy and have documents automagically link to the correct project folder, you're going to need to base the file location on an alias or through a document attribute read in as a variable. Aliases can be very easy to use and change. Using a document attribute is a bit more difficult, but I personally find them much easier to use and control.

Me thinks that document variables are going to be the best bet for you if you need to automagically put things where they need to go, especially if your directory scheme is going to be /Projects/Projectnumber/Projectname. Projectnumber is a variable and so is Projectname. If it was me, I'd create a custom document type off of dm_document (i.e. acme_project_document) and make two custom attributes: Projectnumber and Projectname. Since you've already decided to make a TBO, this shouldn't be a problem. Just make sure that on importing your new documents that you make these custom attributes required. From there your TBO code could look something like this:

<![CDATA[class MyTBO extends DfSysObject { 
protected IDfId doSaveAsNew(boolean shareContent, boolean copyRelations, Object[] extendedArgs) throws DfException { 
IDfId newId = super.doSaveAsNew(shareContent, copyRelations, extendedArgs); 
String projnum = getString("Projectnumber"); 
String projname = getString("Projectname"); 
link("/Project/" + projnum + "/" + projname); 
return newId; 
} ]]>

(I did that totally on the fly... so don't cut and paste okay? I'm sure it's got plenty of mistakes, but that's the gist of it.) That'll do what you want pretty much. You'll have to code your own exceptions, like what if the folder doesn't exist, etc. There's various ways to pull this off, hopefully this will give you some ideas on how to do it.

Chris_Campbell

Methodology

This second message is about your methodology. Your stated goal is to have a "data pool" where all the documents live and then link them to views so users can easily find/view them. The repository itself is a data pool. If you were to look at the actual file structure of the documents you import, they're all put in a single file folder which then branches according to r_object_id. To make another "data pool" and then create links to folders is a bit... well, antiquated. Now you may be limited in what you can do based on your product version and the products that you have purchased from Documentum, but you may want to consider another way of thinking.

The newer versions of Taskspace, Webtop and (perhaps) Centerstage should allow you to do some dynamic filtering. You can leave all the documents in your "data pool" but instead of putting them in folders, let the interface do the work for you. With your two custom attributes you created, you can use those as a basis to quickly filter out/filter in the documents you want. Even in version 5.3, you could base a view off of the advanced search, click go and get what you need. 6.5 does give you more Ajax-like ability to make the interface much quicker, dynamic and look nicer. If you ever need to revamp your folder structure... well, that's easy. No folders to reorganize. If those attributes happen to be repeating, then you can have documents be shared across projects.

Now, if you like using folders (and there's a case to be made for that) you might want to consider just dropping the central "data pool" idea altogether. It's much easier to deal with documents without having to worry about all their links. Having all those files in one cabinet/folder doesn't really give you that much of an advantage. You can create the same view by doing a full-text search on your custom type and all sub-folders. If the default security is based on folder security, then having one data pool is really going to create a lot of issues regarding ACLs. Why not just put the document in the project name folder? I guess I'm just curious as to your reasons for a "data pool" and making links.