Using Relationships with contentless objects

I would like to use relationships in a model to associate documents with their projects and contracts such that in the diagram below the parent document is a custom, contentless object that has attributes that are relevant to a project; a Project object. The child document would be a document associated with this project. There would also be a similar Contract object and document relationship. I could take it even further and associate the contract objects with the projects objects. This would make for a nice ability to easily identify all documents associated with a particluar project or contract as well as associate all contracts with projects.

First, is there a gotcha here? Is it a bad practice to use relationships in this manner?

Second, it occured to me that someone would have to set the relationship which would probably require a customization to the import UI.

Also, the relationship functionality would operate differently than most users are accustomed to seeing project or contract information, it would require a separate action unlike a displayed attribute, a customization could correct this but probably not without significant overhead.

I guess I'm looking to bounce this idea off the heads of others to decide if the benefits outweight the costs/risks

Thanks,

-Mark

Find more posts tagged with

Comments

Francois Dauberlieu

Theoratically, it should work, however, it will be quite some customization, not only the import component but also the New document, Copy, etc....

Basically you'll have to customize ALL components that might change anything in the relationships, specially, addiong relations ...

Lots of work, been there, done it

What about using attributes in you object types

You could have a Project and a Contract attribute your objec type, populated using the Value assistance for example etc...

1 rule of the thumb:

Keep it as simple as possible. I have see na lot of companies wanting huge things, I gave them a minimum config (with minimum customization) that covered about 80% of their requirements and told them to use it for a couple of months and then we will redeiscuss the requirements.

Believe me, after a couple of months, suddenly the requirements become much less and what was a 80% solution became a 90% solution therefore, less money for me, better system for the customer. At the end of the day it's the user statisfaction that counts, not the consultant's bank account (well, it does of coursem, who am I kidding )

fainemr

Are you familiar with the ECIS product offered by EMC, at least from a UI perspective it would be similar. The problem is that our data entry clerks need to see the data one way and our customers need to see it in a totally different way.

The idea is to hide the true folder structure and present customers with a set of nodes in the browsertree component. These nodes would be things like projects, contracts, contractors, types, etc. Combined with the "starts with" filter would make it very quick and easy to find nearly anything.

I can see that adding a 'required visit' relationship component for each type of relationship would be necessary for the import and new containers but I don't understand why I would need to modify the copy component as that is handled by the dm_relation_type's attributes.

Presets can remove unnecessary browsertree nodes but I still would anticipate fairly major customizations for browsertree, minor customizations for New and Import but other than that I don't see much else. If there are things I am missing please let me know as I would not want to commit to such an undertaking without having my eyes wide open.

It has occurred to me that these same customizations can be done using standard DQL queries on attributes and I may test that theory but my fear is that DQL queries against an attribute value would be much slower than relationship queries.

Thanks,

-Mark

rohit.khattar

Hi,

I also have a similar kind of requirement , where I need to associate all documents to a respective project.

A relationship needs to be created between the Project Objects and the Document Objects. Project Objects are subtypes of dm_folder objects.

I want to know how can we achieve this in Documentum with minimum customization.

Thanks,

Rohit

msroth

You might consider using a virtual document as the project and relate all of the associated documents (project plans, contracts, etc.) through relationships and mechanisms that already exist in DCTM and Webtop. Using a virtual document construct would not require any customizations to the UI or the underlying functions mentioned in a previous post. Also, using a virtual document would not change the user's experience; all of the associated objects would continue to behave as expected.

One other thought...EMC just released thier Case Management Framework (https://emc.subscribenet.com/control/dctm/product?child_plneID=297923) with a reference application (https://emc.subscribenet.com/control/dctm/product?child_plneID=297933). These might be useful to you. If for nothing more than to investigate how they handled a similar situation.

agoodale

Have you looked at DCS (Documentum Collaboration Services)? We have a Room (dmc_room) type that is used to represent a project collaboration space. When you create documents & folders in a room, they are "tagged" with the ID of the room using an aspect attribute (dmc_room_aspect.a_gov_room_id). We've written the BOF code to handle maintaining this ID when objects are moved/copied between rooms or outside of rooms.

You can subtype dmc_room to create your "Project" type.

DCS is now bundled free with the platform. Check it out.

vigraf

Similar requirements. We are still on 5.3 but migrating to 6.5.

Initial analysis took into account some of the above comments:

Using attributes only
Using VD
Using relationships

With 6.5 and presets, we are now considering another option:

New folder subtype where we would basically create a "taxonomy" (maybe project organization in your case) -somehow similar the the categories
In WT, users sees a "pseudo-attribute": select the project the document belongs to. This is in fact selecting one of the folders described above.
Presets are used to hide/show the new folder structure via the browsertree: depending on roles users could browse content via the "real" folder structure or the "project taxonomy"

Benefits:

Changing the project taxonomy has little impact on content
Possiblity to link project folders into "real" folders
Move/copy/etc functionality relies on OOTB functionality for folders.

rohit.khattar

What about using attributes in you object types

You could have a Project and a Contract attribute your objec type, populated using the Value assistance for example etc...

Francois,

The above solution will work if a document can be associated with only a single attribute of a Project, what if I have multiple attributes in an object hierarchy of my Project folder types and I want to associate my document to mutilple attributes like Program name , Department , Project Code , State , Address , email Contact etc. all in different folder types through inheritance .

Any comments on that ...

rohit.khattar

..And I should be able to get the documents based on these attributes i.e. all docs for a particular department or Project Code or State etc...