A Brief History in Time (DCTM Development)

Now I might be dating myself, but if anyone remembers the days of Documentum 3.x, you can appreciate the level of customization that is supported in the current version 6.5.

Back in 3.x, the development paradigm was based on DCTM api, docbasic to glue all of the api commands together, and if you need to create custom UI, you had to use a custom tool (whose name I cant remember), to assemble widgets that could be rendered on various OS.  The UI tool was clunky, but it allowed developer to build a single UI and deploy to both Windows, Solaris, and other unix flavors.  DCTM API and docbasic was also supported in the various supported operating systems, so a developer would only have to learn API methods and docbasic to customize Workspace.

With version 4.x, DFC was introduced to replace low level DCTM api calls and docbasic.  DFC was written in java, so this was a big leap in the development paradigm.  Developers could use java (and any external libraries available on the internet) to customize DCTM and were not limited by the constraints of docbasic language, which was basically “BASIC” language.  Also with 4.x, DCTM made its first foray into web application world, called RightSite and Intranet Client.  RightSite was a proprietary web app server that still used docbasic to encapsulate business logic, but it had support for HTML and web scripts.  This meant that developers could customize Intranet Client using HTML, docbasic, and DCTM APIs.

With version 5.x, DFC was enhanced significantly with the introduction of Business Object Framework.  Now you could extend server events (e.g. save) and perform pre and post processing.  Also, RightSite and Intranet Client was replaced with WDK, which allow clients to run web apps on J2EE servers.  WDK customization was based on Model-View-Controller paradigm and developers only needed to know DFC/WDK framework, JSP to customize the UI, and java to extend component classes.  A developer did not need to learn docbasic and native low-level DCTM apis any more.  WDK/DFC is supported on various platforms was also supported on various OS.

With D6, docbasic and APIs was no longer supported.  WDK/Webtop was greatly enhanced by providing support for AJAX and presets.  SOA was starting to get hot, so DCTM provide supported for web services, which eventually became DFS.  With DFS, you could call DCTM via service consumer and not have to build a web app or extend WDK to suit your UI needs.  Also in the D6 timeframe, Taskspace was introduced.  Taskspace is built on Forms Builder and BPM and had a new development paradigm (see my blog entry on TaskSpace – Webtop killer).  WDK developers are still required to customize Webtop, but with TaskSpace, a normal business user could create a simple application without having to learn WDK/DFC.

My next post will cover in more detail the divergence of the DCTM development paradigm.


5 responses to “A Brief History in Time (DCTM Development)

  1. guru..more articles and more often pls 🙂

  2. Pingback: Documentum Development Divergence « Ask Johnny! - Documentum Guru

  3. For the history geeks amongst us, if I recall correctly the widget building interface was called Quickbuilder. I have the EDMS98 disk set in front of me and in those days Documentum actually sent you all the CDs (there were 6 of them) in a colourful wallet!

  4. Ah Quickbuilder. Do you remember the huge manuals they used to print and we had to read through to find the right info? Where would be with Adobe Reader?

  5. thanks for the post..infact u covered everything in a nutshell..

Leave a Reply

Please log in using one of these methods to post your comment:

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