Too small for our britches – when is it time to create another repository

Most of us create a Documentum application for a specific purpose or user group. We create custom types, groups, acl templates/alias sets, lifecycles, and workflows that are used by the application and all of these custom objects are stored in repository used by the application. Assuming the application is a success, you might generate interest from other user groups to develop a Documentum application for them. Here’s the $10,000 (or $1,000,000 if you adjust for inflation) question:

Should we use the same repository or create another one?

There are many factors that may come into play when deciding on whether to share one common repository have multiple repositories for each application. Here’s a few off the top of my head:

1. Are the sames users going to access both applications? If so, creating a second repository would require you to create user objects in both repositories. This maintenance can be minimized by setting up a Federation, but that is a different story.

2. Do you plan on sharing documents between the applications? If so, keeping one repository is simpler than trying to replicate content between the two repositories.

These two questions really focus on the back-end customization of the repository. If you are using Webtop, there are also several options from a customization perspective.

1. You can have separate Webtop applications connecting to the same repository, each with its own unique features.

2. You can have a single Webtop instance with customizations that are specific to which repository you are connecting to. For example, you can have a Contracts menu item that is only visible when connecting to Contracts repository.

I know there are probably other factors that I have not thought about. Please feel free to share your experiences.


9 responses to “Too small for our britches – when is it time to create another repository

  1. Hi Jhonny,

    Nice to see your comments on some common pit-falls developers make during a DCTM project.

    We have the same issue of having same repository or different ones for different departments. Also our users are geographically distributed and the applications are as diverse as they can. We have already created a couple of webtop instances, each one having department specific customizations. But we are sure. we can’t go ahead with 10 different webtop instances with a ton of customizations in each.

    Would it be nice if Webtop can be customized based on roles like we do in BEA portal?Can you throw some light on this?


  2. Webtop/WDK components support scoping by roles. Can you give me an example of what you would like to do with roles?

    I think the bigger issue from an enterprise perspective is maintaining a manageable security model.

  3. Sarma,

    You can consider scoping based on docbase. Though it depends upon the load on the server, you can always scope your for docbase. (scope docbase=’emc’)
    Vivek Pandey

  4. You have to take care when scoping by docbase for certain components like browsertree and advancedsearch. These components allow you to specifiy docbase you want to perform an action on. Scoping by docbase on these components may have certain unintentional side effects.

  5. Hi Johnny,

    Thanks for that reply. This is what we are doing:

    We have more than 10 different departments that use Documentum to manage their documents. Each department has their custom doc types and metadata defined. We have customized webtop components like DocList, Search, Advanced Search, Preferences(column), Import, New document etc to show only the respective department specific types and corresponding metadata. We also did some customizations to concatenate a set of columns and display them as a single column in search results. To manage all of this, we already have 3 different webtop instances running in production.

    When user logs in to Department1’s webtop, they will see all department1 specific customizations. Similar is the case with other departments.

    I think you now got a fair idea of what we are doing. Let me know how we can use role scoping to achieve this. Many thanks for your time.


  6. Read Configuring Roles and Client Capability chapter in WDK Development Guide. You can create a role for each department and then assign the department group to the role. Roles were not exactly designed for this, but you can use it just like any other scoping configuration.

  7. Hi Johnny,
    we are coming at this from another direction. Our current dev project is aimed at an external market. Diff customers will use the system, and we must keep their documents seperate(permission and attribute based search). A lot of time has been spent on analysis working out a core structure for the product that we envisage will give our customers what they need. Everything will start of in one docbase for the initial release, and the intention is that if the customers what something “extra” they will have to be moved to their own docbase- assuming of course they feel its value for money.
    Its easier to admin one docbase, but sometimes you need many…..


  8. Hi! Johnny:
    We are having a similar issue …we want to go with a shared docbase at an enterprise one of issue is there are 4-5 applications which want to modify the “dm_event_sender” its a shared docbase we are having difficulties with it ..
    also can you recommend some of the points which we need to keep in mind if we want to go with shared docbase at an enterprise level.

  9. Hi dctmexpert07,
    There are a lot of factors that come into play when deciding to have one shared enterprise docbase or multiple docbases. I suggest you contact an experienced Documentum consultant to help you review your requirements and make sure you make an informed decision.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s