Design Pattern suggestion: Value Assistance Management without DAB.

Derrick

I need help in determining if the below is a worthwhile submission to the design pattern library.  Please review and help me.

Providing non-technical end user ability to modify value assistance list of a custom attribute without giving them access to Application Builder.

Problem:

Due to the complex workflows and nature of the broadcast business, Documentum needs to be customized for television broadcast engineering in order to use it as a media management system.  Part of the customization includes representing different episodes as objects in the repository, and storing cuesheet information of each episode as an attribute.  One of the required attributes is closed captioning information, which can only be one of a pre-defined list of values.  These values may require modification from time to time by the broadcast engineering staff.  This issue can be resolved using a vanilla Documentum install by adding the predefined list of values as a value assistance list to a custom type’s attribute, and allowing the end users access to Documentum Application Builder (DAB) to update the value assistance list.  However, DAB encompasses a lot of functionality that is not desirable in a typical end user’s hands.  The only other vanilla approach would be to provide the end users with Documentum Query Language (DQL) queries they can enter via Documentum Administrator (DA).  This approach also is risky as it requires system administrators to expose DA to non-technical staff and requires training the end users in DQL.  Therefore, the only approach is through customization.  So how should this customization be implemented?

Solution:

There are several options that can be taken, but most can be summarized into the 2 below:

1)      Providing Lookups for Data Fields (this is a pattern already in development at the EMC developer community)

2)      Provide a service that encapsulates either the Documentum Foundation Services (DFS) or Documentum Foundation Classes (DFC).  The service must also provide a way for clients to execute Documentum Query Language (DQL) required to update the value assistance data for a custom attribute.  Then provide a client to consume the service, which can be anything from a thick client to a mobile client.

Obviously, since Providing Lookups for Data Fields is already a pattern in progress, I will focus on the second option.

Manage Value Assistance Pattern

Description:

The primary business users for this pattern would be operations staff in the television broadcasting industry, though other industry verticals may find use for this pattern as well.

As a precursor, it is assumed that the current IT environment contains a Documentum repository and a box running either DFS or DFC.  Since there is already DFS/DFC in the environment, why does this pattern include a service to encapsulate this functionality?  This is to account for the relatively high costs of a Documentum implementation; there are licensing costs associated with every server hosting DFS/DFC.

Using a design based on services oriented architecture, this pattern will expose the functionality to update the value assistance data for any custom type in a Documentum repository to multiple non-technical users.  This will avoid licensing and training costs associated with deploying DAB to multiple desktops and training non-IT staff on how to use DAB.

Functional How-To:

The Manage Value Assistance pattern is based on the layered services pattern.  First, create a method that accepts the name of a custom type and a custom attribute as parameters, and returns a collection of objects with members for the value, display string and description of each value assistance item.  Then, create a method that accepts the name of a custom type, the name of a custom attribute of the custom type, and a collection of value assistance items as described above.  This method basically overwrites the existing value assistance data for the custom attribute of the custom type and replaces them with the values contained in the collection passed through as a parameter.  Essentially the collection of value assistance data is used to build a string object that will be the DQL query required to run against the repository.  Once the DQL query is constructed, the method will run the query against the repository with the PUBLISH keyword to ensure other users have access to the new value assistance data.

Since this second method will be exposed to multiple users, it must be made re-entrant or thread-safe to prevent multiple users from editing the same custom type and attribute at the same time.  As a security precaution, there should be authorization checking implemented here so only users who are supposed to be modifying the value assistance are allowed to.  Therefore, this service must never allow anonymous access.

Next, expose these methods via service consumable by clients hosted on other machines.  The favourite choice would be a XML web service but WCF is also a good option.  This will enable many users access to this functionality, so it can be shared across the enterprise.

When to use it:

Obviously there are multiple ways to allow non-technical users to gain access to the value assistance data.  The database table these values reside in can be updated directly with a stored procedure, saving the trouble of learning the Documentum APIs.  Although this is the more efficient way, I do not recommend it as it bypasses a lot of the built in plumbing that Documentum provides.  It’s always safer to use the Documentum provided facilities to manipulate it as they naturally invoke required background processes to ensure everything goes smoothly.

Examples:

I implemented an example on http://www.codeplex.com/documentum.

The requirements to make the example work are:

Content Server 5.3 SP6.

DFC 5.3 SP6.

Microsoft.NET 3.5 (WCF and WPF).

ukdavo

A quick way of facilitating VA management could be:

• Create a custom type as a child of dm_document. Let's call this enterprise_document. Add the attribute document_type.
  
• Create a custom type as a child type of dm_folder or dm_document. Let's call this type my_lookup. It doesn't need any custom attributes. This type is used to hold the VA values.
  
• Update the VA config for enterprise_document.document_type with "select object_name from my_lookup where folder('/Lookup/enterprise_document/document_type') order by object_name"
• Create a cabinet called /Lookup and apply an appropriate ACL
  
• Create the folder /Lookup/enterprise_document/document_type
• Using Webtop/DA/DQL/API/etc create my_lookup objects within /Lookup/enterprise_document/document_type

The benefits of this approach are:

• You can perform CRUD operations on VA values via Webtop/DA/DQL/API/etc - i.e. no custom UI required, no custom code
• No user training required - it's as simple as managing documents/folders
• VA values can be secured with different ACLs so the dropdown list could appear different for different users/groups
• VA values could be versioned if my_lookup descends from dm_document
• VA values could be included in docapps
• Exposing VA management to custom clients is pretty straightforward as you can use standard DFC/DFS/DQL in your integration code

The drawbacks are:

• Custom object based value assistance is not as performant as using registered tables

I would be interested in other people's approaches to this. I'm pretty sure that others on this site have put together custom WDK components to manage registered tables, etc.

Oops - I just re-read your post and I noticed that the above is covered in scenario 1 which as you've pointed out is covered elsewhere. My apologies - please ignore me :-)

Message was edited by: ukdavo