Webtop 6.5 SP2 User (mis)Guide: Versions

Webtop 6.5 SP2 User Guide describes versions as shown in the attached screenshot of page 34 below. In an apparent attempt to simplify the concepts it errs on the side of inaccuracy. The concerns are described and corrected below the image.

Description of Versions in Webtop 6.5 SP2 User Guide

1. The version labels for Documentum objects are strings and not decimal numbers. They are strings even for the implicit version labels (automatically assigned by Content Server using a number-based format), some of which may be considered to be decimal numbers (1.2, 3.4, etc.). But the comparison ends right there. For example, 2.3.1.2 is not a decimal number but a valid version number. Decimal numbers don’t have multiple decimal points. “Increasing version number by a tenth” is also inaccurate because increasing the decimal number 1.9 by a tenth should give you 2.0 but a minor increment of the version number 1.9 gives you 1.10 as the new version. Further, 1.1 and 1.10 would be identical as decimal numbers but duplicate version numbers are not allowed in a version tree. Particularly, these last two points make the decimal analogy egregious.
2. This version label should be 5.0.1.0 since a branch is created by appending .1.0 to the parent version. There are always odd number of dots or points (not decimal points) in an implicit version label, so 5.0.1 is not even a valid implicit version number.

Use a Specific Connection Broker in DFC Client

Suppose that we need to create a  DFC client that won’t have connection broker information before run time. So we couldn’t put this information in dmcl.ini (this is pre D6, but one could imagine a similar situation for dfc.properties – the solution would probably be similar, maybe not identical).  Yes, one could list all the connection brokers present in the environment in dmcl.ini. There may be a reason we want to use a specific connection broker. For example, if we cloned a repository (say, DEV or QA copy of production) we may have two repositories with the same ID in our environment. In this case, one repository would be hidden by the other depending on the order of connection brokers in the dmcl.ini. Once there is a such a need, it can be accomplished as follows:

// connection broker info
String cbHost = "host";
int cbPort = 1489;

// connection info
String repo = "docbasename";
String user = "me";
String pass = "secret";
String domain = null;

// get local client
IDfClientX clientx = new DfClientX();
IDfClient client = clientx.getLocalClient();

// alter client config to set the primary connection broker
IDfTypedObject cfg = client.getClientConfig();
cfg.setString("primary_host", cbHost);
cfg.setInt("primary_port", cbPort);

// create login info to set identity
IDfLoginInfo loginInfoObj = clientx.getLoginInfo();
loginInfoObj.setUser(user);
loginInfoObj.setPassword(pass);
loginInfoObj.setDomain(domain);

// Create and bind the Session Manager to the login info
IDfSessionManager sessionManager = client.newSessionManager();
sessionManager.setIdentity(repo, loginInfoObj);

IDfSession session = sessionManager.getSession(repo);

Of course, you need to set the host and connection strings according to your environment.

Note that this code alters the configuration that was read from dmcl.ini so we couldn’t rely on dmcl.ini configuration any more while we are using the same session manager. If we need to go back to the regular dmcl.ini configuration we will need to save that information before overwriting it. Or we could start from scratch creating a new DfClientX object.

Such a need maybe rare but when you need it you really need it.

[This approach is probably unsupported. This post doesn't claim suitability for any purpose whatsoever.]

Correction for Documentum Architecture Whitepaper

[UPDATE] A new version (November 2009) of the architecture whitepaper is out now. However, the errors pointed out below continue to persist in the new version.

A Documentum Architecture whitepaper is available on EMC Documentum Developer Community site – EMC Documentum Architecture: Delivering the Foundations and Services for Managing Content Across the Enterprise. A part of page 13 from the currently posted version (dated January 2008, a newer version will probably fix this issue) is shown below. It describes object-level security in a confusing manner.

Page 13 of Documentum Architecture Whitepaper

The areas of concern are marked in the image. These concerns are explained below:

1. Under Basic Permissions, it states that Delete is a special case with regard to the cumulative property. This is an incorrect assertion. The Delete basic permission does imply all the other lower basic permissions.
2. The section title – “Object-level delete privileges” is inconsistent with Documentum terminology. Privileges are associated with users and permissions are associated with objects being secured.
3. “Delete Object permission” should be “Delete Object extended permission” to be unambiguously correct. It is not the basic delete permission, which is  suggested by the last sentence of the previous section.
4. Two Extended Permissions are missing in the list – Delete Object and Change Folder Links. The Delete Object extended permission is actually what is explained under the title “Object-level delete privileges” above. The Change Folder Links  extended permission was introduced in Documentum 6. It enables linking to and unlinking from a folder.

Orphaned Java Method Server: 6.5 SP2 Windows-Oracle

While deploying DARs using Composer I started running into weird errors. The most common error was DM_SESSION_E_CLIENT_AUTHENTICATION_FAILURE. It was showing up across multiple clients.

Coincidentally, I had made a change to a lifecycle around that time and I got misled to believe that the lifecycle change caused the problem. After going down that path for several hours I ended up looking at the JBoss log. It indicated problems related to ports not being available.

So, I shut down all Documentum services and checked the ports. The ports 9080, etc. were still being used. I used netstat to look up the processes listening on ports using this command:
netstat -a -b -n

And I used Process Explorer to get the details by process ID. That confirmed that this particular java.exe was indeed running JBoss.

I killed the process and started the Documentum services again. Everything seems to be back to normal now.

TagPoolingEnabledException: Documentum 6.5 WDK Applications

Documentum 6.5 WDK applications require that JSP tag pooling be disabled. The deployment instructions clearly specify how to do it.

I copied the configuration from the PDF to conf/web.xml for Tomcat. On first connection attempt it threw the following exception:

com.documentum.web.form.control.TagPoolingEnabledException: JSP tag pooling is not supported. Please refer to the product deployment guide for instructions on turning off tag pooling for the application server.


On closer inspection of my changes I found that the copy-paste process from PDF somehow lost the dashes (‘-’) in the XML tags. I fixed the configuration and restarted Tomcat. Still the same problem.

On further scrutiny, I found that the comments in web.xml indicate the following

enablePooling       Determines whether tag handler pooling is enabled. This is a compilation option. It will not alter the behaviour of JSPs that have already been compiled.


Some JSP’s could already have been compiled on the first attempt which were not affected by the new configuration. So I deleted the work folder for da: work/Catalina/localhost/da under Tomcat. That did it and brought up the DA login page.

This is a development configuration on my laptop: Windows XP SP3, DA 6.5 SP2, Tomcat 6,  JRE 1.6, Content Server 6.5 SP2, Oracle 10.2.0.4.

Later on I found this relevant post, which is helpful for some other related configuration as well.

NOTE: I learned it the hard way that Tomcat 6.0.20 service doesn’t start when using -XX:MaxPermSize=512m in the configuration mentioned above.

Alfresco Coming of Age?

I have worked with Documentum way longer than with Alfresco. Couple of years ago I started dabbling with Alfresco and started using it as a personal content repository at home. It was ridiculously easy to set up and exceptionally stable on Linux even with that early version. At that time, most Documentum professionals I talked to wouldn’t give a serious thought about it.

How times have changed! I think that recession may also have helped Alfresco like it is helping organizations such as Walmart and Kroger. These stores near my home have renovated and look overstocked. And they are not dealing in just the traditional stuff. The Walmart store seems to be stocking all the stuff that I would usually go to Home Depot for! But this is not a post about recession so let me not digress.

Let me not take anything away from Alfresco. It is earning the reputation based on its virtues – the recession may just be hastening its arrival on the grand stage. Quite a few professionals still mention it with caveats about its suitability for non-critical systems. I feel that it is just a matter of time.

Within the last few months I have seen two Documentum vendors become Alfresco partners. There are probably more but these are the ones I have known well and worked with. With the discretionary spending drying up it seems that service providers are being forced to diversify. The Alfresco market should definitely help them get the sales pipeline filling up again, even if at lower rates.

Then there are respected Documentum professionals such as Laurence Hart (Pie) and Johnny Gee who have started exploring Alfresco and sharing their opinions. I am sure there are many others in the Documentum community in a similar situation. I haven’t gone out trying to identify any trends – these are just the thoughts triggering from the events in my usual environment. When Documentum professionals get seriously involved with Alfresco, I can envision cross-pollination of ideas and experiences resulting in creative and effective solutions for customers.

Hiding Types in Documentum Clients

Custom types in Documentum solutions benefit from inheritance in a type hierarchy. It is quite common to have a base type for a particular application/solution and the other custom types are derived from it. A common base type also facilitates querying all the related custom types since the query can use the base type in the FROM clause rather than enumerating all the subtypes. For example, a base type financial_doc could be used where the concrete document types are invoice, check, and paystub.

A side effect of this choice is that the base type also starts showing up on the Import screen (and probably some others where it may not be desirable). The base type may be akin to an abstract class and we might not want users to use this type when importing documents or creating objects. It might also be difficult to hide this type by simple configuration. Maybe we don’t want this type to show up anywhere on the UI other than in a few specific places. Is there a way to hide the type on the UI while still keeping it available for use?

This requirement can be accomplished by using the data dictionary attribute (easily via Documentum Application Builder) – lifecycle (dmi_dd_common_info.life_cycle). This attribute can have the following values 1=current 2=future 3=obsolete Like other data dictionary items this is just a hint for client applications. However, EMC products such as Webtop respect this attribute. When this attribute is set to anything other than 1, the type is available for all purposes, it is just not shown on the UI. The same approach can be taken for hiding an attribute.

It is quite likely that we do want the type to show up on the search screen since it enables us to search across all of its subtypes. This will require a customization that “hard codes” the type to be displayed. Often, this can be accomplished by modifying the appropriate JSP.

FREE EMC Documentum Developer Edition

For the first time, EMC has released a Documentum Developer Edition Package which is available as a free download. It gives an opportunity for new devlopers to build their skills on Documentum before they have formal access to Documentum through a job or training. Of course, it also gives a try-before-you-buy opportunity to potential customers. Read more here.

UCF Error: ExceptionInInitializerError

One of our Documentum users ran into this exception when doing a simple import via Webtop:

invokeMethod() failed while calling: onOk
An error has occurred when invoking the UCF runtime. Details:
java.lang.ExceptionInInitializerError

This user had performed imports successfully in the past. Everything else seemed to be in order. After asking around, I got this suggestion which actually fixed the problem. Apparently, UCF keeps stuff in a local folder which sometimes gets corrupted. Deleting (or renaming) this folder causes UCF to reinitialize its “cache”. Look for this folder in a location like C:\Documents and Settings\USERID\Documentum\ucf

Real-Life Service-Oriented Architecture (SOA) with D6

I contributed an article for EMC Proven Professional Knowledge Sharing 2008 entitled Real-Life Service-Oriented Architecture (SOA) with D6. It has now been published on EMC Education Services site. On the same topic, I also wrote an article on CMSWire.

For ease of access, the article is being made available here as well (with permission from EMC) – download article. The abstract of the article follows.

Abstract

Service-Oriented Architecture (SOA) facilitates composition of loosely-coupled services into new services and applications. SOA must deliver business and technical agility to be successful. In other words, SOA serves business goals other than the standard “potential cost reduction via technical changes.”

This article translates a real-life business goal into an SOA solution that includes a key service provided by D6 (EMC Documentum version 6). While the article is primarily technical, it keeps business drivers and context at the forefront.

Even as SOA is becoming mainstream, Enterprise Content Management (ECM) has become a key piece of the enterprise infrastructure puzzle. Explosive content growth has led Gartner to forecast a 12% annual growth in ECM software revenues for the next three years. EMC Documentum has been a leading player in the ECM space so it should come as no surprise that SOA has been adopted as one of the core principles of D6.

D6 provides Documentum Foundation Services (DFS) for plugging Documentum into an SOA solution. Documentation and articles about D6 and SOA typically focus on DFS features. While they are essential for using Documentum in an SOA solution, they need another complementary capability for completing the SOA picture – orchestration of services for composing new services or applications. This article explores implementation of a real-life business scenario via an SOA solution including Documentum as a key component.
Consider a business goal to reduce Days Sales Outstanding (DSO) defined as the average collection period of account receivables over a time period (typically quarterly or yearly). A large DSO value means that it takes longer for the business to collect payments. A process analysis reveals that invoice presentment and payment are the primary improvement opportunities. This article describes an SOA-based implementation of an Invoice Presentment and Payment Application. Documentum is used to manage payment-related documents such as invoices and payment receipts.

The article illustrates the following key aspects of such a solution:

1. Using DFS for creating content-oriented services
2. Orchestrating SOA services for composing applications or other services
3. Addressing real-life concerns