Posts Tagged ‘’

D2 Best Practices and all about Widgets

August 27, 2019 Comments off

There are several best practices that we can follow and to list below are a few key important ones:

  • Improving Content Transfer Performance
  1. Enable compression of content:
  2. Navigate to and open <install path of D2 Client>/WEB-INF/classes/
  3. Set the applet level properties parameters
  4. Increase the socket buffer size
  • Enabling Compression at the Application Server
  1. Navigate to and open <TOMCAT_HOME>/conf/server.xml
  2. Configure the threshold of the content size and the type of content to be compressed
  • Optimizing Performance for Widgets and Large Numbers of Content
  1. Navigate to and open <install path of D2 Client>/WEB-INF/classes/
  2. Configure a maximum result size for the Doclist widget, User and Group widgets, Thumbnails widget , Repository Browser or Taxonomy widgets.
  • General Tuning Tips

On Oracle Server:

  • Modify the Oracle sessions and processes parameters.

On the Content Server:

  • Modify server.ini and set the concurrent_sessions parameter.

On the web application server:

  • Modify the Java heap size, maximum threads, and GC policy.

Configuration Files

Navigate to <install path of web application server>/webapps/D2–Config/WEB-INF/classes for the D2 Config configuration files:, & logback.xml

Navigate to <install path of web application server>/webapps/D2/WEB-INF/classes for the D2 Client and D2FS configuration files:

applicationContext.xml, settings. Properties, logback.xml,, D2FS-trust. properties

Note: The names of configuration files are case-sensitive.

How do you configure a menu item for a Template Plugin?

We can configure a menu item using D2 Config to allow end users to call the custom action.

  1. Log in to D2 Config and navigate to Go to > Menu D2 to open the D2 Client menu configuration page.
  2. Add a new menu item to the menu in which you want the button to appear.
  3. We then fill out the form for the new menu item.
  4. Click Save.

Facet Search

The facets widget allows the search refinement in a dynamic facet list. Facets are grouped by category and ordered based on the configuration or advanced search settings.

D2 uses the EVENTS to communicate between widgets, Custom Widgets


Internal Widgets





How to set up an external Widget?

I used the D2 implementation of OAH, called D2-OAH.js which provides the binding between a web page and the surrounding D2 application. D2 Config refers to these web pages as external widgets, which are hosted in an iframe within the D2 Client web application. How to setup depends on which external widget we are trying to setup – like there is UpdateDoclist widget:

  1. Extract UpdateDocList folder from D2
  2. Stop the web application server.
  3. Copy the UpdateDoclist folder to the <web application server>/webapps/ folder.
  4. Start the web application server.
  5. Log in to D2 Config:
  6. Navigate to File > Import configuration from the menu bar.
  7. Import
  8. Navigate to Widget view > Widget from the menu bar.
  9. Select the UpdateDoclist widget.
  10. Modify the Widget url field to match the location of the web application server that we have deployed.
  11. Log in to D2 Client and add the new widget to your workspace.

This is pretty much the standard procedure.




A more detailed information about D2 Widgets can be found in the D2 Administrative Guide.

Happy Reading!!!

kVisia: Product Overview

March 18, 2015 Comments off

Howdy Users and Buddies,

Today I want to share on kVisia, a product that provides the core functionality to automate, control and deliver an organization’s engineering and enterprise business processes to the desktop or Web. It holds the business rules, executes the XML configurations, builds the business forms, and implements the lifecycles that automate an organization’s business processes.

I think the only Prerequisites that you need to know is , Basic concept of client-server applications and Documentum Architecture.

Let me put it in Content Wise for better understanding with a bit of background of what’s there , what’s missing and how this can be achieved.

  1. Abstract

Today the current era is defined by the terms like data, information, knowledge, wisdom etc. and in this electronic world the difficulty to manage data in abundance has begotten many technologies and one of them is the Documentum.

Documentum is nothing other than a Content Management Tool but its vastness and its ability to cater to almost all sorts of data types available are so rich in itself that these days it is widely used. If we undo the Documentum technically then it gives an edge over the Relational Database Management System by not storing only the Meta data but also storing the content in its native format.

kVisia blends with Documentum to bolster the level and depth of automation which can be achieved by the Documentum alone and this is what this document discusses in detail.

  1. Introduction

kVisia comes of McLaren Software Limited and users need to have a license before using it. McLaren is ISO 9001 certified and it has been accredited Independent Software Vendor for Documentum and FileNet. It has got 360+ customers worldwide and it operates from UK, USA and Switzerland.

In fact kVisia is an Enterprise Engineer product that encapsulates best practices and domain expertise. This is a user configurable application consisting of XML files managed by repository and standardized on a single ECM platform. It is also believed to be powered by Documentum.

For better understanding of the kVisia we can go through the following questions and answers that will help one to identify the need.

How does it help me?

Very quickly configure the user interface and deliver it to the Desktop and Web users.

Is it easy to change?

Very easy, configuration files are stored in the Docbase in XML format.

Configurable interface using objects and tables.

Do the configuration files allow me to control inputs?

Very complex business rules can be enforced via the XML files.

Validations at creation, promotion and check in.

  1. kVisia suite

kVisia suite consists of following three components:

  1. McLaren Studio
  2. McLaren_Core DocApp
  3. McLaren_Foundation DocApp

3.1 McLaren Studio

McLaren Studio provides a user-friendly desktop application that allows users to create and edit XML configuration files that will conform to the rules of the Document Type Definition (DTD).

An XML (eXtensible Markup Language) configuration file is a structured file consisting of many elements. Elements are ordered into a tree structure or hierarchy. Elements may have parent or child elements, and may also contain attributes. An element without a parent element is the highest in a tree structure and is called a root element. Not all of the elements will have child elements.

The structure of a valid XML file is defined in a DTD (Document Type Definition) file. The DTD contains the rules that apply to each XML configuration file; these include the definitions of parent and child elements, element attributes, and how each element can be used

The appearance and behaviour of user dialogs can be modified without the need to change programme code simply by changing settings in the appropriate XML configuration file. A definition of the appearance and behaviour of a dialog is referred to as a “configuration”. A common need, however, is to display different configurations under different circumstances. For example, members of different groups may need to fill in different properties on documents, and the document’s properties may change as it moves from state to state in a lifecycle. The definition of such a scenario is referred to as a “mapping”. When you do not want to differentiate functionality between different groups, lifecycles and states, there is a value called {default} that will apply to all circumstances.

The Actions for which dialogs can be defined using an XML configuration file are:


When the user issues the New command, a customized dialog can be displayed. Commonly deployed features include automatic document numbering, interactive project allocation and any additional attributes (optional or mandatory), which may be required to be stored for the document.


A customized Properties dialog can be displayed. Fields can be made editable or read-only as required.


When the user performs an import, a customized dialog can be displayed which may typically employ features similar to those used in the New dialog.


When the user performs a copy and paste action, a customized dialog can be displayed which may typically employ features similar to those used in the New dialog.


For each document type, a search dialog referred to as QuickFind can be defined and viewed by the user in the Docbase through the McLaren menu. The attributes that can be searched on are configurable and search options such as Between, Greater Than, Containing, etc., can be specified.

 3.2 McLaren_Core DocApp

Having installed kVisia you get two sets of Docapps in the Docbase, one is the McLaren_core and the other one is McLaren_foundation. The McLaren_core Docapp is available to the user of a Documentum repository. It is always suggested that one should have the overview of the additional functionality as a result of the deployment of the kVisia before configuring the product to suit the business need.

As the name suggests McLaren_core Docapp provides the basic functionality like New, Import, Properties, Copy, QuickSearch etc to be configured. As discussed above, we use the XML configuration tool McLaren Studio to configure it.

For each Object Type used in the repository, an XML Configuration File can be created and configured to define the appearance and behavior of the various dialogs for documents of that Object Type. The definition of the appearance and behavior of a dialog is referred to as a configuration, and different configurations can be displayed in different circumstances.

3.3 McLaren_Foundation DocApp

The McLaren_foundation installation enables you to deploy a pre-configured implementation of the Core technology which transforms it into a user application specifically adapted to the engineering environment, providing a ready-for-use engineering repository. It deals with the following configurations:

User Roles that is associated with Menu Systems and User Dialogs that are adapted to those roles.

Object Types for documents and folders.

XML Configuration Files that define the content, appearance and behavior of the New, Copy, Properties, Import and QuickFind dialogs for the supplied Object Types in accordance with the current user’s User Role and the document’s lifecycle and state, including pre-configured, automatically generated document numbering.

Check in dialogs which are specifically adapted for each supplied type of engineering document.

Automated document revision numbering that reflects common design practice. Revision numbers start at 0 and the first issued version is 1, the second 2, the third 3, etc. When a document is checked in for the first time, a numeric value is assigned and incremented each time it is checked in.

  1. Traditional – VB (Desktop) Vs kVisia(Desktop & Web)

Following Comparison lets you know how much flexibility kVisia provides and how much time and effort it saves.

Traditional – VB (Desktop) kVisia (Desktop and Web)
Ø  Obtain VB source code.

Ø  Open VBP.

Ø  Edit GUI.

Ø  Add code to populate list.

Ø  Add validation rules.

Ø  Save source code.

Ø  Compile DLL.

Ø  Create CAB file.

Ø  Open DocApp in Composer

Ø  Edit the component ACX and

replace CAB file.

Ø  Check DocApp back in.

Ø  Not available until next user login.

Ø  Check out XML.

Ø  Edit XML kVisia Studio.

Ø  Add XML tag.

Ø  Specify properties.

Ø  Save and Check back in.

Ø  Change available immediately (no logout required).

  1. Benefits
  • Easy to manage development process as applications are configured via XML using Studio
  • Fast route from innovation to user acceptance
  • Shorter time from design through to development
  • Shorter time to deploy to the business users
  • Reduces development costs
  • Future upgrades are minimised
  • Simple deployment and at a local level of control
  • Speeds up implementation process through rapid configuration

Hope you like the post, Feel free to post your comments and I will reply back to any queries that you have.

Adios , Have a great day ahead…

Documentum Folder Bulk Export

February 10, 2013 Comments off

Hi Readers,

It’s been a while I was away from my blog…here I am back with all your requests.

Someone wrote a note to post something on Folder Export…Bringing it to you:

There is often a requirement of exporting an entire folder structure from a Documentum file repository to the local file system. The Documentum web applications allow export of only a single file not an entire folder structure with all files.

This document intends to illustrate the usage of a free tool ‘Documentum Deep Export Utility’ available on the EMC Developer Community site to achieve the objective of exporting an entire folder structure with all files from Documentum to the local file system.

This document also details the procedure for enabling Deep Export on Documentum 6.5 natively, enumerating the pros and cons of using the native functionality v/s the external utility.

Let me categorizes in sections:


The cabinet structure in Documentum is required to be replicated to the local file system, including the folder structure and all files. Export of metadata from Documentum is not included in scope.


  • Ensure that a fast data connection to the content server is available
  • Ensure that there is sufficient disk space for exporting the files
  • This utility has not been tested for docbases which have a very high degree of interlinked folders.

Enabling Native Deep Export Functionality on Documentum 6.5

This method will enable the native Deep Export functionality introduced in Documentum 6.5. This will enable a right click menu item in Webtop when the user right clicks on a folder. The menu item will be labeled as ‘Export’. The whole folder will be saved to the user specified directory sans the metadata.

  • Deep export of a folder having special characters (for example,:,?, <>, ʺ, |, *) are not supported. If you try to export a folder having such special characters, then the application throws an error.
  • Deep export of a hidden folder is allowed when you export a parent folder. If a folder is not visible in Webtop, then all the sub‑folders including hidden folders get exported during Deep export.
  • Deep export is supported for UCF content transfer, not HTTP content transfer.
  • Only the primary content is exported, no renditions are exported.
  • Only the current versions of documents are exported.
  • A VDM root and its children are exported starting from the level that is present in the folder selected for Deep export.
  • If the child of a VDM is in multiple folders, it is only exported once.
  • Deep export is trimmed down not to support VDM


Enabling Deep Export:

  • Go to the webapps folder where Webtop application is installed. If Apache Tomcat is being used the location would be “C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\webtop”
  • In the Webtop folder, go to the ‘wdk’ folder and open the ‘app.xml’ file
  • Search for this text:

<!– Enable / Disable (true | false), the deep / folder export functionality. –>




Native Deep Export in D6.5 Webtop will be enabled.

Performing Deep Export via the Documentum Deep Export Utility

Setting up the Environment

Ensure that the DeepExport utility is unzipped to a folder on the system with a content server installation

  1. Register the SBO. Go to C:\Documentum\Config
    Append the following line to the file ‘DBOR.PROPERTIES’


  2. If the source server where the files are to be exported from is a remote server, you need to set the to point to the remote server. If the source server is local, no changes to the are necessary
    Set ‘
    Enter the name of the remote server in the ‘<content server>’
  3. Assuming deepExport utility is extracted in the ‘C:\ deepExportService’ folder
    Go to this folder and open setEnv.bat
    Set Java path (including quotes)
    eg. JAVA_HOME=” C:\j2sdk1.6.0_27″
  4. Set path of dctm.jar & dfc.jar. Please note that though path of config directory is not mentioned in the manual included with the utility, you also need to include it for correct operation of the utility. This has been included in the example below

         eg. DCTM_JAR=C:\Program Files\Documentum\dctm.jar;C:\Documentum\config

Run the batch file from a command line


Verify whether the path has been set correctly by typing echo %CLASSPATH% on the command line

Performing the Export

Go to the deepExport folder and edit the ‘testDeepExport.bat’

  1. Set the username and password to the username and password of a user of the docbase. Ensure that the user has sufficient permissions
  2. Set the docbase name variable
  3. Set the docbase source folder name variable
  4. Set the export folder on the local system
    Please note that the path has all double backslashes and ensure that sufficient space is present on the system
  5. Execute the batch file



The process takes quite some time. When the command prompt returns the utility would have finished the export.

Comparison of Utility v/s Native export

The advantage of the utility based export is that no changes are required to the documentum environment itself. The export can even be done remotely by setting the as instructed above. On the other hand, native export functionality is recommended if the export feature has to be provided to the end users as a permanent feature.

For more information , check out the below link:



Documentum Traces

November 4, 2010 Comments off
Tracing is one of the easiest and excellent way to troubleshoot complex issues in Documentum.
There are 5 Types of Traces i can think of :
  • DMCl Trace
  • SQL Trace
  • Method Server Trace
  • DFC Trace
  • Authentication trace

1. DFC trace


This is to trace all the requests that use the Documentum foundation classes.


To do this you need to add the following flags to the %DOCUMENTUM%\config\ file:

# Specifies whether to combine the trace of dmcl along with other traces.


# Specifies whether to enable or disable trace.

Once you save the file the tracing starts.
You don’t require restarting the Application Server but it can create extremely large logs. Because of this reason it is best if you enable the tracing just before you are ready to replicate the problem and disable it just after you finish replicating the problem.
To stop the tracing change the flag value to false:

# Specifies whether to enable or disable trace.

Remember you need to save the file for the change to take effect.

The information is saved in the %DOCUMENTUM%\logs\trace.log file unless you have modified the default configuration in the %DOCUMENTUM%\config\ file if you are not sure you can check this flag:

log4j.appender.FILE_TRACE.File=C\:/Documentum/logs/trace. log

2. DMCL Trace


This is to trace all the requests that go from the Documentum clients to the content server.


Go to the dmcl.ini file and add the following two lines

trace_file=<specify the location where you want the file to be created>


3. SQL trace


This is to trace all the requests that go from the Content server to the database and it is logged automatically to the docbase log.


This is done at the content server box

Go to the Documentum Server Manager and select the docbase on which you want to enable the trace.

Go to edit service and add the following line at the end


Trace is generated on the docbase logs which can be found in



4. Method server trace


This is to trace all the requests that go to the Method server.

This is done at the content server box

Go to the Documentum Server Manager and select the docbase on which you want to enable the trace.

Go to edit service and add the following line at the end


Logs are in %DOCUMENTUM%\dba\log\<repository_id>\MethodServer\MethodServer\server_config_name.log


5 .Authentication Trace


This is to trace the all the authentication mechanisms in a docbase.

This is done at the content server box.

Go to the Documentum Server Manager and select the docbase on which you want to enable the trace.

Go to edit service and add the following line at the end


Trace is generated on the docbase logs which can be found in


Appreciate any comments.

%d bloggers like this: