Two questions for the experts...

Here are two questions that I believe would be very useful for Documentum experts to answer here as I imagine many users will struggle with the same issues I am facing. I've posted the first question already in a separate thread but received no answer.

Question 1. How does one get the "display form - submit - display another form" so common in Web applications with Taskspace? My team and I have used Taskspace as a user interface for simple processes now, but if the process involves some back-end automated activities, interspersed with manual activities where the user has to enter or confirm data... invariably the user has to check their inbox.

This is a clunky way of doing things if we have a "sit through the entire thing now" process... the user will not be walking away. Is there a way to get smoothly flowing form-to-form behavior in Taskspace without resorting to custom Java code? Or perhaps a small amount - we want to rollout the tool for superusers at some point who do not have programming experience, hence the question.

Question 2. Where do we store persistent data related to processes? I do not mean the debate of custom object types in the repository versus process variables in structured data types... What I mean is: suppose we have a process that involves a small amount of persistent data... such as a reservation process where we want to have a small blacklist of users whose reservations are always rejected. The blacklist would not be used anywhere else in the organization. What is the best practice for this type of requirement - we have many processes where we will face a similar question. One approach - one that I favor personally - is to create custom object types for these requirements, and store the data in objects of those types, objects that have no content/documents attached to them, but nonetheless the object properties are very useful. Another approach is to put the data outside in external databases of course.

Ahmed

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

DCTM_Guru

1. Instead of submitting the form and loading another form the lookup action, why dont you just create a validation button on the form itself? The validation button can run the query against the list and return success/error without leaving the form.

2. It data is getting populated (or consumed) from an external system, then external table/database is the easiest to manage with respect to integrating with the other system. If the data is only used internally by Documentum, then creation and management of data using custom types is much simpler.

All comments

apriam_i

Hello, Ahmed.

I'll answer at second question: in my opinion difference between object attributes and STD is very clear. If you need to save data after finishing process - save it in attributes, in other case - in SDT.

Sorry, question 1 is unclear - is it a problem about checkin Inbox?

aabdallah

Thanks for answering Alexey.

1. The first question is like this: we want the user to enter data into a form... then hit submit... get some data from the repository or from an external database and maybe do some other automated activities... then display another form immediately. We do NOT want the user to have to go to his or her inbox to see the next form - we just want to chain from form to form.

I hope that is clearer... think of something like purchasing over the net: choosing the product, checking the shopping cart, entering payment information, and then final confirmation. All without going back to an inbox and waiting for the next task/form to appear in the inbox.

2. I agree that the difference between SDT's and custom objects is clear. But what I'm wondering is something related to the question of custom objects versus external database: where to store data that is used purely by Documentum processes? Inside the repository? Or outside in external databases? I believe it should go inside the repository... but our implementing vendor is saying no the data should be kept in an external database - even though they recognize the data is only useful within Documentum... so I guess I'm a bit unconvinced about their answer frankly, and I wanted to hear from the community and/or technical experts what is the 'best practice'.

Thanks.

DCTM_Guru