Documentum 16.3 delayed until Feb 2018

If you access the new support page, there is a section where you can find roadmaps for the products, and if you check the Documentum related ones, you’ll see the target date for ths new version listing new features. Without going into much detail (As I’m not sure how public this info is), these caught my atention:

  1. Ongoing exposure of D2 APIs through REST (goodbye DFS?)
  2. Native support for S3 object storage protocols to alleviate storage costs (goodbye OnDemand, hello AWS?)
  3. New REST Services (see #1, no mention of DFS anywhere to be found)
  4. Webtop will get a 16.3 version (yeah!)


Welcome to OpenText My Support

On August 25, 2017 at 8:00 P.M. EST, the Dell EMC Enterprise Content Division, including
Documentum, Application Xtender, Captiva, Kazeon, Document Sciences and LEAP will officially be integrated into OpenText Customer Support systems. While the customer service quality you’ve come to expect won’t change, the way you access support resources will.

On August 25, 2017 at 8:00 P.M. EST, OpenText’s online support portal known as My Support will become the primary system that you use to submit, update and monitor the progress of your organization’s support requests for former ECD technology products such as Application Xtender, Captiva, Documentum, Kazeon, Document Sciences and LEAP. In addition, you will be able to access support resources such as forums, documentation, knowledge base articles, account information and much more!
To help make the transition easier, we have migrated your existing tickets to My Support. Any new tickets you create with the My Support wizard will also be accessible there.

Centera end of life

Centera will reach its end-of-life on March 2018. After that date DellEMC will stop manufacturing parts and will keep it on support until 2023, when you’ll be on your own if you’re still storing your Documentum data on Centera.

Time to say goodbye to those .pea files and to start thinking about an alternative storage.

Debugging D2 4.5/4.6

It still surprises me when people tell me that they can “only” debug D2 code by adding output to their plugins so, if you’re using eclipse as your IDE, here are some steps that most likely will help you to debug code from an eclipse server (Tomcat):

Extract all files from D2.war and D2-Config.war (just in case you want to have access to D2-Config from a local environment, not much you can debug here) and copy the D2 lib folder to your computer.

  • Generate lockbox file for your environment (probably this is the hardest part :D)
  • Update in both.
  • Update D2’s (update absolute path in lockboxPath) and logback.xml (update logs path)
  • Update D2-Config’s (update absolute path in lockboxPath) and logback.xml (update logs path)
  • Copy following libraries to Tomcat folder:
    • /endorsed: (from d2-config/web-inf/lib)
      • crypto.jar
      • cryptojce.jar
      • cryptojcommon.jar
      • jcm.jar
      • jcmandroidfips.jar
      • jcmFIPS.jar
      • util.jar
    • /lib:
      • LB.jar
      • LBJNI.jar
  • Configure a new server in eclipse. In Run Configuration add the following:
    • Arguments:
      • -Djava.endorsed.dirs=”<absolute path to tomcat>\endorsed
      •”<absolute path to some temp folder>\d2″
      • -Dclb.library.path=”<absolute path to D2 libraries folder>\lockbox\win_vc100_x64″ (choose your OS library)
    • Classpath:
      • User entries:
        • Path to LB.jar and LBJNI.jar
      • Environment:
        • Classpath: <absolute path to D2 libraries folder>\LB.jar;<absolute path to D2 libraries folder>\LBJNI.jar;<absolute path to D2 libraries folder>\C6-Common.jar;<absolute path to Documentum DFC’s dctm.jar>;<absolute path to Documentum config folder>
        • Path: <absolute path to D2 libraries folder>\lockbox\win_vc100_x64;%PATH%
    • Add project to Sources
  • Add D2 and D2-Config as deployed modules to your server configuration.
  • Start server

Webtop extension will stop working on Firefox 57

In November, Mozilla will release Firefox 57. This version will replace XUL with WebExtensions, this means every addon/extension not developed with the WebExtension API will stop working. The current extension for Webtop is not compatible with WebExtensions:


I wonder if OpenText will show us that they are a “software company” instead of the former Documentum owner which was a “hardware company” and have a new extension ready by the time Firefox 57 is released…

PS: I’m not even sure the extension will work on FF57, as Mozilla hasn’t implemented file access API due to security reasons, so I’m not sure if it’s even possible to port the extension to WebExtensions. (Maybe it is time for a HTML5 transfer mechanism?)

Support adventures II (REST Services edition)

I wasn’t expecting this week to be so “productive” 🙂

I had the chance to engage again with Documentum support, which is always an adventure 😉

We’re currently porting a framework from DFS to REST services. A couple of days ago, one of my colleagues had a problem and ask me if I knew why a query through the REST services was failing.

The query is using DATETOSTRING to retrieve a time field and returning a column with the attribute name using the alias, so, if a user requests expiration_date we execute a query like:

select DATETOSTRING(expiration_date,’dd/mm/yyyy’) as expiration_date from…

which returns the requested attribute in the desired (configurable) format. Easy, right? Well, the problem was that using r_creation_date or r_modify_date was throwing an exception:

 {    “status”: 400,
“message”: “There are illegal arguments provided.”,
“details”: “Invalid format: \”12/04/2013\” is malformed at \”/04/2013\””}

We also observed that changing the alias to something else than r_creation_date/r_modify_date would work (but it was breaking our use case).

This was weird, because I was quite sure that those kind of queries worked previously, so I checked against the Content Server:

Connected to Documentum Server running Release 7.1.0210.0328  Linux64.Oracle
1> select DATETOSTRING(r_creation_date,’dd/mm/yyyy’) as r_creation_date from dm_document enable (return_top 1);
2> go
(1 row affected)

As I though, it was working just fine. I suspected it had something to do with the custom date format, as EMC/OpenText tends to forget that not everyone uses ANSI or the american date format, so I decided to open a SR.

After some exchange of emails, we were told that both r_creation_date and r_modify_date where reserved words and that it was expected to fail. What???

After asking support to either fill this as a product limitation or fixing it, I decided to take a look at the code myself.

As I suspected, the query works just fine, and results are returned to the Query controller. The problem here is with the way REST generates the response. If you run the query with a different alias to see the result page you’ll get this:

"entries": [  {
"id": ",%27dd/mm/yyyy%27)%20as%20rr_creation_date%20from%20dm_document%20enable%20(return_top%201)&index=0",
"title": "12/04/2013",
"updated": "2017-06-16T11:04:38.284+00:00",
"published": "2017-06-16T11:04:38.284+00:00",
"content": {
"json-root": "query-result",
"definition": "",
"properties": {
"rr_creation_date": "12/04/2013"

Do you see those fields before the content element? That’s where everything breaks, why? Because of this:

public Date entryUpdated() {
Date updated = null;
Object modifyDate = ((QueryResultItem)getDataInternal())
if (modifyDate == null) {
updated = new Date();
} else if ((modifyDate instanceof Date)) {
updated = (Date)modifyDate;
} else {
updated = DateFormatter.parse(modifyDate.toString());
return updated;

public Date entryPublished()
Date published = null;
QueryResultItem queryResultItem=getDataInternal();
Object modifyDate = ((QueryResultItem)getDataInternal())
if (modifyDate == null) {
published = new Date();
} else if ((modifyDate instanceof Date)) {
published = (Date)modifyDate;
} else {
published = DateFormatter.parse(modifyDate.toString());
return published;

As you can see (besides the obvious copy/paste from one method to another changing the name of one variable), the standard view looks in the results from the query for a column with those names, and if it founds a column matching that name, tries to parse it with a forced format (which of course, it’s miserably failing with our custom date format).

This, in my opinion, is a bug, because the behaviour of the query functionality it is inconsistent between the Documentum stack, in fact, this query only fails with REST services, so I’ll keep pushing the SR to be treated as a bug and fixed by the talented team, and not as a “product limitation” or a “feature request”.

And if you face the same problem, and it is still not fixed, you have three options:

  • Keep waiting for a fix
  • Extend and handle the IllegalArgumentException that throws DateFormatter.parse
  • Extend the controller adding a custom view for the results and removing/overriding the updated/published fields.

Why Migrate to Documentum D2

I’ve just seen this post by OpenText and I couldn’t resist to add some comments:

One of the striking advantages of a D2 application versus a Webtop application is that upgrades become much easier, and keeping up to date with product development and patches becomes so much easier, because D2 applications are constructed in the configuration framework, and upgrade of the D2 platform does not require ANY work on the configuration.

As long as your business requirements doesn’t force you to develop widgets/extensions/customization of core services. Then you’re in worst position than with other clients, because if Documentum documentation is usually lacking, you’ll be amazed with D2 documentation.

Customers choose their products based on complex weighted matrices of technical considerations, comparing functional details, platform characteristics and implementation approaches before establishing a platform standard within the organization for Enterprise Content Management (ECM).

If any customer would bother to do that, EMC would’ve hardly have sold any xCP 2.0/2.1/2.2 license.

These days, the goal is more likely to be user acceptance, or better put – user adoption –

The goal is selling licences.

By the way, D2 is a good fit (with its own flaws, as Webtop has) if customer sticks to configuration and doesn’t want anything else. Any other case needs to be carefully reviewed before making a decision.