D2 v4.0 Now Available

If you missed the news last week, D2 v4.0 is not available.  Here is the link to the announcement.

I am excited about the improvements and enhancements listed here, but the one that grabs my attention the most is the ability to extend D2 using widgets and gadgets.  I can’t wait to see what cool extensions the community devises for D2.

I am also pleased the D2 v4.0 was released on time (in fact a little early?) based upon the last roadmap I saw.

Advertisements

D2 Overview – Part IV

In this final post about D2 I want to address a few areas of concern and disconnect that grew out of the TechSet 2012 training.  Many of these concerns and disconnects are on the roadmap for resolution, but some are not, and until they are, you should be aware of them.

  • ACLs – D2-Config has an ACL editor.  Its vocabulary differs slightly from the vocabulary used in Composer and Content Server but is not a big deal.  The interesting thing about the D2-Config ACL editor is that it allows ACLs to be dynamic and can apply access policies based upon attribute values of the object.  For example, the ACL can assign specific access to users listed in the authors attribute.
  • Document Lifecycles – this is probably the biggest disconnect with the Content Server.  D2 utilizes its own lifecycles (not dm_policy objects in the repository).  The D2-Config lifecycle editor is much nicer than its Composer counterpart and D2 lifecycles in general are more flexible and useful than those included in the Content Server.  However, they are only executable in D2.  If you operate in a mixed environment (D2, Webtop, custom app), your D2 lifecycles will not be executed or respected by other clients.  Hopefully, in the future, Content Server will adopt the D2 lifecycle paradigm.
  • Form validation – D2-Config does not provide a mechanism to valid DQL or other free-form entries in the designer.  One nice thing xCP and Forms Builder does is valid any DQL you enter in a form.  You know before you deploy and test whether your DQL is properly structured and syntactically correct.  D2-Config provides no such capability so DQL entry is guess-work.  It would also be nice to validate user form input that is not tied to a dictionary (e.g., date validation).
  • TBOs – There has been much discussion but no clarity provided regarding how D2 automation (creation matrix, default values, etc.) will work with TBOs. As previously mentioned, TBOs will work with D2; however, the question is how.  Will D2 automation occur first or take precedence over TBO execution or will it happen the other way around.  EMC just needs to provide clarity on how this interaction occurs.  I have been promised that such clarification is forthcoming.  When I see it, I’ll post a link to it.
  • UCF – As previously mentioned, D2 does not use the UCF for content transfer.  For the sake of unity and conformity, it would be nice if D2 used UCF also.
  • IE Only – Currently, D2 only works with IE.  This is certainly a limiting factor, but is expected to be resolved by v4.0 (this fall).

That about wraps it up for my impressions of D2.  I look forward to deploying and using it in the future.  Post a comment and let me know what your experience with it has been.

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.

D2 Overview – Part II

In this post I will discuss D2 Installation and Architecture .

Installation
D2 is composed of a pair of web apps, a DAR file, and a couple of JARs.  The installation process is well documented and fairly straightforward:

  1. Install the D2-DAR.dar (~34MB) file using the DARInstaller.  This DAR contains the D2 object types, jobs, methods and other objects needed by D2 and D2-Config.  Even though installation of the DAR file is an option from the D2 installation wizard (see step 3), in training, we used the DARInstaller.  A DocApp is also available if you prefer to use the Application Installer.
  2. D2 uses both DFC and the DFS.  If the DFS is not already installed on your web server, install it before you install the D2-Client and D2-Config WAR files.
  3. Run the D2_x_Install.jar.  This wizard-based installer configures and builds the D2-Client and D2-Config WAR files.  When it is done,  you need to manually deploy them to your web application server.
  4. Re-Run D2_x_Install.jar on the Content Server to install the D2-API.  This process consists of copying the D2-API, D2-BOCS-65, and D2FS4DCTM-AP, and C6-Common.jar files to the JMS library directories.

Login to the D2-Client to verify the installation:  http://<host&gt;:<port>/D2-Client.  You will be prompted to install the D2 ActiveX control.

Notes:

  • D2-Client does NOT use the UCF for content transfer.  This is both good and bad.  Good, because it isn’t using the UCF.  Bad because, well, UCF seems to work now, and it is the standard way for Documentum clients to transfer content.  This is just one of several “disconnects” from standard Documentum functionality that will need to be addressed in the future.
  • If your user environment does not allow the installation of ActiveX controls, you may have to devise a way to “push” the control to client workstations from your CM system.
  • D2 only works with IE 6, 7, and 8 32-bit.  Support for other versions and browsers is on the roadmap for future releases, but right now, this is a limitation.

Architecture
Architecturally, here are some things to know, beyond the 2 WAR files, DAR file, API JARS, and ActiveX control.

  • Out of the box, D2 does not do anything.  Even the simplest of operations must be configured.  As opposed to Webtop that out of the box does everything and often times must be scaled back to meet user requirements.
  • As mentioned above, D2 uses both the DFC and the DFS.  Training did not make it clear why or which functions used which API.  Since DFS is the way of the future, I would expect to see functionality shift in the DFS direction.
  • The DAR files installs 89 new object types into the Docbase.  The D2 objects all start with a “d2” prefix.  These objects hold the configuration settings and rules for the D2-Client, as configured by the D2-Configuration application.  Because these configurations are in the Docbase, they can be versioned and exported.
  • The D2 components generate XML and JSON streams that are sent to the web application for display.  The web application portion of D2 then renders the XML and JSON streams using ExtJS and AJAX.
  • Internationalization and localization with D2 is very simple and built into the configuration interfaces.
  • D2 v3.1 will be compatible with the Business Process Engine.  Versions prior to 3.1 will only work with Workflow Manager workflows that were installed using DAB.
  • There are still lingering questions about how D2 works with BOF.  The question is not will it work — it will — but, how it will work.  Documentation explaining how D2 and BOF interact is pending from EMC.

In the next post, I will take a look at some of the D2 paradigms and capabilities.

D2 Overview – Part I

As part of TechSet 2012, I attended three days of D2 training.  I have been interested in D2 ever since I first heard rumblings about it last year.  Part of my interest stemed from just trying to stay ahead of my clients with Documentum knowledge, but I was also genuinely interested to see what Documentum had developed as their next generation web client.  In addition, information about and access to the actual client was a little hard to come by further shrouding the software in mystery.  Well, no longer.  In the next few posts I will provide an overview of what I learned in D2 training, along with some of my own thoughts and insights. 

What is D2? 

D2 is Documentum’s new web-based client developed by the newly acquired French company, C6.  D2 is based upon the concept of configuration, as opposed to coding, the UI.  EMC’s stated vision is to consolidate Documentum’s various clients onto two platforms:  D2 and xCP 2.0.

D2 is currently offered in two flavors:  Premium and PlusPack.  The differences between the flavors are explained here.

D2 consists of two web applications:  the D2-Client and, D2-Config.  These are installed as two separate WAR files on your application server.  It should be obvious that the D2-Config application is used to configure the D2-Client.  A repository can have only one D2 installation, unlike Webtop or custom WDK applications.  If multiple “applications” are to be developed for a single repository, all configurations are created and stored in the repository, and each “application” is defined in D2-Config and presented to users using the D2-Client based upon their roles and permissions in the repository.  This concept is somewhat akin to how TaskSpace works.  The thing to note is that the URL for the D2 -Client is always the same regardless of which “application” a user may be using.

In general, the D2-Client UI is not a huge departure from Webtop as far as look and feel (see below).  I found this to be a bit disappointing.  I was hoping that this client would be really cutting-edge and more Web 2.0-ish.  That being said, the UI does sport some nice new features like a great virtual document manager, and a details pane that can quickly display a document’s location, renditions, versions, relationships with other documents, audit trail entries, and other handy stuff.

The D2-Config application makes heavy use of configuration matrices (see below).  UI components are created  (configured) and appear as rows in the matrix.  Document Sets (i.e., “scopes”) are created and appear as columns.  Configurations are then assigned to Document Sets to create the D2-Client UI.

Documentum has positioned D2 as the prefered client for all content-centric ECM applications.  That being the case, D2 sports tons of features focused on content management that can easily be configured to meet most requirements.  For example:

  • Basic library services,
  • Virtual document management,
  • Repository navigation,
  • Annotations,
  • Renditions,
  • Releations,
  • Cut/Copy/Paste,
  • Searching,
  • Lifecycles,
  • Workflows, and
  • Administration.

I fear the rub will come the first time you need to implement a feature not currently supported by D2.  D2 does have a plugin architecture and supposedly an extensible pallet of screen controls and backing logic.  Unfortunately, the training did not cover those features and the documentation on the topic is TBD.

Next time I’ll give some insight about how D2 is put together and how installation/deployment works.

Documentum Ports

I am endeavoring to compile a catalog of common/default port numbers used by Documentum and related products.  I have scoured PowerLink, the support forums, blogs, install documentation and my own systems to compile the following list.  Hopefully, this will help anyone needing to open ports in a firewall.

Here is what I have so far, please feel free to make suggestions/corrections:

1489/1490 Docbroker (native/secure – must be consecutive ports).
8080 Tomcat default app port
7001 WebLogic default app port
9200 First Indexing agent port #1 (FAST/xPlore)
9080 First Indexing Agent port #2 (FAST)
13000-17000 Index Server (4000 contiguous ports)
10000/10001 Content Server 5.x  (see …/etc/services file).  These ports represent the native and
secure connection ports.
47625/47626 Content Server 6.x  (see …/etc/services file).  These ports represent the native and
secure connection ports.
16005 FAST Server
32000 xPlore Index Agent (Dctmservice.exe)
32001/9080 Method Server
32002/32003 xPlore Server
389, 489 Active Directory, LDAP
1521 Oracle Listener
9300/9302 xPlore (native/secure)
443 SSL
9080/9081 ACS and UCF (native/secure)
8489/8490 Documentum Messaging Service (native/secure)
8086/8087 Back Office Content Server (BOCS) (native/secure)
1099 Content Intelligence Sevrices (CIS)
1433 SQL Server
9095/9096 Documentum Content Transformaiton Services (CTS)
135 eRoom
6677 Documentum SCS/IDS Adminstration
2788/2787 Documentum SCS/IDS source/target communication (native/secure)
389/636 LDAP (native/secure)
10099 Captiva InputAccel client/server TCP port
8079 CIS
8061 CIS JMX agent port
1099 CIS RMI port
3690, 4445, 7130-7229, 9000, 10000-11000,
32000-32999, 375779, 40002, 55550-55649
CIS misc. ports
8081/8008 Documentum Thumbnail Server
%d bloggers like this: