ECM Design Patterns

Recently, the EMC Developer Network has started posting some “Design Patterns”. I use the term loosely to mirror their terminology. Each “pattern” is really just a quick description of the problem and two approaches to solve the problem. It is all very high level.

Before I get any further, kudos to them for actually taking the time to begin developing these “patterns”, starting last fall. There is a definite need, and their choices for the first two are ones that are encountered quite frequently, at least by myself. All I am doing here is offering some feedback, most of which I have already shared.

If you develop Documentum solutions, you need to check them out if you haven’t already. They are:

I also want to add that if I hadn’t read Patterns of Enterprise Application Architecture, I wouldn’t be able to make comments that are, I hope, constructive.

Defining ECM Design Problems

The first step in formally defining a Design Pattern is to define the problem/domain. Let’s take the 2nd example. The problem, as given, is as follow:

Developer wants to build an application on top of Documentum Content Repository to create/update/read/act on content stored in Documentum Repository. They have two available options. They can either connect to Documentum Content Server as Named User or Gateway User. Click here for a diagram that explains Named user and Gateway User mechanisms.

In the named user access, the application connects to Documentum as a user it is performing action as, where as in Gateway user access, application connects to Documentum as a application user that performs actions on behalf of the users that is interacting with the application.

Only the first sentence actually talks about the problem, even though both paragraphs are in the section Problem. The description needs to define the problem in more detail, giving the business case and an example or two.

Only by defining the problem in detail can the reader truly understand the different solution patterns and see which situations that each may be required. It is a fair to list the Patterns in this domain and/or to define any Pattern groupings.

In the example that we are looking at, Named Authentication and Gateway Authentication are actually the name of two groups of Patterns, and not two patterns themselves. The Patterns that I know (proposed names in bold) are:

  1. Named Authentication with Shared Authentication (Single Sign-On)
  2. Named Authentication with Stored Credential Authentication (user id and password stored as separate values in the 3rd party solution)
  3. Named Authentication with Generated Credential Authentication (Connection maintained by gateway user that spawns user sessions as required for the named user)
  4. Multi-Level Gateway Authentication (Different Gateway Users for different authorization levels in the 3rd Party System)
  5. Single-Level Gateway Authentication (As described in the article.)

Check out the post for my thoughts on these patterns.

Defining the ECM Design Pattern

For each Pattern, there are several things that need to be elaborated upon in order to fully define it. They are (tip of the cap to Martin Fowler):

  • Description: Describe the Pattern. Include a diagram to illustrate the concept more clearly.
  • Functional How-To: Give a description of how it actually works. Describe how different components interact to implement the Pattern.
  • When to Use It: Give the Pros and Cons. Comparing and contrasting to other Patterns in the domain would be beneficial. (Ex. Single-Level Gateway Authentication doesn’t track requests in the ECM system by user. Use a Named Authentication approach, or pass the requesting user as a parameter, to achieve auditing).
  • Examples: Where applicable/available, code snippets and other items that may assist people in implementing the Pattern.

I’m not going to go into defining any of the Patterns at this time. I may do so here if there are requests. Patterns are going to become a larger part of the Developer Network in the near future, probably after the hinted-at arrival of wikis. At that time, I will be taking time to write these out for all to share.

If you have any other Patterns that may fit in this domain, add it in the comments, add it to the Discussion thread on the Developer Network, or just wait for the wiki to arrive.

Remember, Share and Enjoy!

4 thoughts on “ECM Design Patterns

  1. Niall says:

    I’m feeling adventurous and need to integrate Pega with Documentum using DFS. I quite fancy using Generated Credential Authentication as my pattern. I suppose I could use the same method as the WDK uses for it’s TrustedAuthenticator.

    The other approach I was considering was a custom dm_checkpassword with a secure time-boxed key in the password that can be generated by Pega and decrypted and validated by Documentum.

    All sounds a bit painful. Are there any better options – I wonder – coming in 6.5 (hopefully released today). I will have a delve later and see.


  2. Niall, to my knowledge, there aren’t any other options coming in D6.5.

    I do like your approach with dm_checkpassword, though speed may be a concern. The Generated Credential Authentication works well, especially when you properly configure session pooling.

    Good luck.



  3. Alec says:

    I wasn’t able to find any technical documentation explaining how to implement “Generated Credential Authentication” pattern. Could you provide any hints on how to acquire the session as a “superuser” and how to transfer that session to be used by the actual named user? Are there any minimum requirements for the privileges that the “superuser” should have?




  4. Brinda says:

    Hi Pie,

    I have been looking for a way to enable “Named Authentication with Shared Authentication (Single Sign-On)”, unfortunately, i do not know of a dfs api that takes in the username and a sso token as its authentication arguments nor do I see a way to fetch the sso token from within form adaptors or bpm event hooks to call an internal login to the external system with the username and the already generated sso token. Do you know of any way?

    Also if the above is not possible, I would like to explore the “Named Authentication with Generated Credential Authentication”. I understand from another doc of yours where you spoke about ticketed authentication. Can we do the ticketed authentication through DFS?


Comments are closed.