D2 Overview – Part III

In this post I will briefly cover some of D2’s paradigms and features.

From a user’s perspective, the D2-Client closely follows the Desktop Client/Webtop paradigm. For example, D2-Client makes use of: context menus, drag and drop, extended selections, multi-pane UI, virtual document editor, and graphical workflow viewer. Of course, D2-Client provides all the functionality you would expect from a Documentum client: library services, navigation, security, searching, administration, inbox, etc. It’s just all presented in a fresh and intuitive way.

From a developer’s perspective, D2 is rather unique; it employs two primary paradigms, components and document sets, that are related via a third paradigm, the configuration matrix. Document sets are scoping mechanisms. A document set can restrict certain functionality (or apply certain functionality, depending upon your perspective) to a set of qualifying objects based upon object type, a DQL query, user roles, or a combination of these characteristics.  Document sets are created via a form interface in D2-Config and are displayed across the top of the D2-Config configuration matrix (see below).  Document sets are given precedence left to right in the matrix.

Components of the D2-Client interface are configured in D2-Config and appear as rows in the D2-Config configuration matrix (shown above).  Components are then added Document Sets by clicking in the intersection of the component’s row and the Document Set’s column.  The list of configurable components for D2-Client is extensive.  Here is an excerpt just to give you a taste:

  • Security,
  • Checkin,
  • Checkout,
  • Renditions,
  • Properties,
  • Templates,
  • Workflows,
  • Lifecycles,
  • Search,
  • Menus,
  • Audit, and
  • Document templates.

Each component is configured using a unique set of forms in D2-Config designed just for that component.  D2 also provides some extremely useful capabilities that don’t fit as easily into the list above.  For example:

  • Document Creation – In order for a user to create a document in D2, a document creation process must be defined for the type of document the user is creating.  This process requires that a property page, a dictionary, and a creation matrix be defined.
  • Custom Property Page – every object managed by D2 must have a property page associate with it.  Each property page must be custom designed using the D2-Config built-in forms builder.  The forms builder is very versatile, powerful, easy to use, and creates nice looking property pages that can employ value assistance.
  • Dictionaries and Taxonomies – D2 makes heavy use of custom dictionaries and taxonomies.  With dictionaries, you can easily customize UI vocabulary to be industry-specific and/or langauge/culture specific.  Internationalization is built into D2!  Taxonomies relate dictionaries.  By relating dictionaries in taxonomies, you can easily setup value assistance on property pages and strictly control the vocabulary your UI uses.
  • Creation Matrix – this matrix simply unites the object type, its dictionary, and its property page.  It defines the behavior the application will exhibit when a user creates (or imports) a new object of a given type.  This is a very powerful feature whose functionality used to require considerable programming.  In the creation matrix, you can employ other D2-specific features such as automatic naming, automatic linking and metadata inheritance.
  • Automatic naming and linking – D2-Config allows you to set up naming templates for documents.  These templates are automatically applied to all new documents of the specified type and can contain dates, property values, and counters.  Auto Naming is a really nice feature (and easy to implement) if you have a use case that requires objects to follow a strict naming convention and be unique.  Auto Linking allows newly created objects to be stored in a particular cabinet/folder structure.  If the structure does not exist, it will be created.  The logic for determining the storage location can contain static text, property values, and other system values (e.g., the date).  This capability also used to required considerable programming in previous clients.
  • Metadata inheritance – allows newly created objects to inherit certain metadata values from other documents in the repository.  This is a really nice feature that previously required a TBO to implement (see an example here).
  • Linked documents – D2 can automatically create additional documents and link them to the primary document being created via a relationship.  For example, if an SOP is being checked out for updating, a change request document can automatically be created, linked, saved and routed with the SOP.
  • Configuration export and documentation – you can export all of the configuration settings for your application into a ZIP file on your hard drive.  You can open the ZIP file and poke around in the XML files if you want to see what they contain.  This ZIP file can then be imported into a new instance of D2.  This is the mechanism by which you can move a D2 application from Dev to QA to Prod.  Think of it as a D2 DAR file, only better!  The other cool thing you can do is automatically generate documentation for your application.  With the click of a button, D2-Config will dump a PDF spec sheet detailing your configuration.

This is but a few of  the new capabilities provided by D2.  As noted above, many of these new features that are now configurable previously required programming either in WDK or the BOF.

In the next post I will discuss some of the disconnects between D2 and the established Documentum capabilities and paradigms.

UPDATE:  Some nice press from EMC here.

Advertisements

About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

4 Responses to D2 Overview – Part III

  1. Liz Tarquin says:

    Hi Scott. Thanks for putting all this out there – I’m in Sydney Australia, and faced with a dilemma. My organisation has selected xCP as their ECM tool, and nominated me as the PM. We have the usual problems of multiple disjointed data and data sources, inefficient processes, information fiefdoms, etc. I have been reiterating two major risks – one, that xCP is not going to be a silver bullet and two, that I have never implemented an ECM project before, let alone one that uses Documentum.

    I’m also concerned, after reading your blog, regarding D2 – whether we are better off planning a D2 rather than xCP implementation, and what risks we will face in later upgrading to D2.

    I’m looking for any help, including a ‘primer’ on what my key activities/steps are in planning and executing the nuts and bolts of the project. Thank you for your time.

    Regards,

    Liz

    Like

  2. Scott says:

    Liz, thanks for the comments. You are right that xCP is not a silver bullet; it’ll take some hard work and smart people to achive success. But, because of xCP’s “configure not code” appoach to development, it does fit well into an Agile software development process where approaches and processes can be quickly prototyped and built upon. As for xCP vs. D2: if you are modeling a bunch of business processes (workflows, interfaces with other systems, etc.) then EMC recommends using xCP. If your application is more content-based (creating documents, making sure they are filed in the appropriate place, making renditions) then your best bet may be D2. I could be mistaken, but I think the community.emc.com Documentum site may have some sample project plans, design docs, etc. that EMC has produced. Best of luck!

    Like

  3. Vicky says:

    Hi, I want to inherit the document properties to folder inside which the document is created. Please can anyone let me know how to achieve the same in D2.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: