nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Architectural Issue: where to store data?

aabdallah

In the company I work for, we have begun a massive Documentum effort for automating workflow and archiving documents.

Here's the problem: my company hired a third party company to do some initial work for us using Taskspace, Process Builder, etc. (xCP). In our meetings with that vendor, we asked them to store some data into the repository as custom object types. Their response was that the repository should not be used as a database, and data should always be stored outside of Documentum.

This response has me puzzled, so I thought I would take this question to the EMC experts here please.

Where should data be stored? I don't think there is a black and white answer to this, so please explain what are the factors to consider.

Thank you in advance. I think if EMC personnel answer this question, it will help a lot of aspiring Documentum teams.

Ahmed.

Find more posts tagged with

Comments

aabdallah

Again, just to clarify the issue (I'm re-reading my original question, and seeing how it can be misinterpreted):

When I asked where to store the data, I meant: Given a particular application, the question arises as to where to put the data - inside a regular database, or within custom object types within Documentum. I am not talking about content: I am talking about what Documentum calls "metadata".

It is entirely possible that what I am thinking of is not recommended in Documentum, and I would be happy to learn that.

For example, consider a banking application where a customer may need some information stored about them. Should we store that information as a custom object type within Documentum (e.g. customer_account_information), or is it best practice to have an external database, then access this information through an interface from within Documentum?

I believe the answer has more than one factor to consider... no? yes?

EdSteenhoek

Hi Ahmed,

Indeed there is no black and white answer. For me it all depends on the purpose of this data.

First, I would say that the Documentum repository is for documents/unstructured content and a database is for structured data.

That leaves the grey area in between both.

With xCP I would say it is legitimate to store data, that is relevant to the process you're implementing, as custome types within the repository. Especially if you need this data versioned. If e.g. you want to store the possible static values a certain attribute can contain, there is no need to store this in a database.

On the other hand, if you're going to store all line-items on each purchase order, than a seperate databse does make sense.

Question to answer are:

- which application creates the data? Only Documentum?

- which application maintains the lifecycle (change/delete) of the data? Only Documentum?

- which other applications use the data? None?

- are you paying a performance penalty for storing it in Documentum as custom types? No?

- are we talking about mass volume data? No?

In that case, I would settle for Documentum...

Regards,

EdSteenhoek

Hi Ahmed,

In the given example of a banking application where a customer may need some information stored about them and not being meta data, I can hardly imagine that this Documentum application is the only application that needs that information. This type of information appears to be more or less CRM data and that type of data tend to be stored outside Documentum in a CRM system/database.

Regards,

aabdallah

Thank you for both of your answers. I appreciate the advice you are giving, definitely.

The example I gave was something I purposely chose based on something you and I agree with: who will be using the data is a major factor to consider when wondering whether to go with your own database or with custom object types. In the example I gave, I used information that would likely be of interest to many different entities, not just Documentum. I would agree that it is not necessarily the best choice to put in the repository then because we cannot optimize the table design, and I there are other reasons too.

But our vendor is objecting (pun not intended...) to cases where the data is only being used within Documentum. This is what drove the original question. It sounds like you would agree that in this case, storing the data inside Documentum custom object types would be entirely within the norm of Documentum usage... right?

Again, many thanks for your input.

I do wish someone who is "officially" from EMC would give their two cents, though the issue is definitely getting clearer with excellent input like yours.

Crink

There are a few other considerations that you might have.

1. Can the data be edited. If so you could use xCP as a method of building a UI for the fields. This is typically done with a Documentum form. You can also do this with a Process to update a table but it becomes one more process you need to maintain.

2. Do you want read access to this data? If so, do you need security of who can see the data?. Again, you can use a Documentum forms to hold the data and then use search template to show the columns of the data. Using Documentum ACLs as well as roll based searches you can customize which users can access which data. There are also attribute based visibility that you can control in a Documentum form.

3. Do you need to keep the data for a set period of time? There are retention polices in Documentum that you can add to enforce retention of data for a set amount of time.

4. If you do not have security or editing requirements for this data you can still access it from within xCP using either registered tables with a search template or a data source adapter in a form.

It all depends on how the data will be used in your process.

aabdallah

Thank you very much! Between your and Ed's answers, I can see that our vendor has been overly simplistic in telling us no custom object types should be created. And your answer in particular is highlighting that Documentum xCP adds features that make it compelling to put the data in the repository - even if it is being used by a "few" (my choice of words) of applications. It depends on who is using the data, how it is being used, and the value that is offered by all the extra features (rapid application development in particular) of xCP.

FYI, we are indeed using xCP: Taskspace, Process Builder, Forms Builder, and so on. We have a team with many years of Java development, but we are purposely stretching the tools to examine how powerful they are.

Again, thank you to both of you, and if others are kind enough to contribute within EMC and otherwise, I would be grateful. This is an important issue, even if it is clear to some.