Documentum in the cloud

Yesterday I attended the latest Documentum webex from Opentext. It was a review of  last year, with some use cases explained by customers and partners, and a review of the roadmap (It seems that they aren’t delaying the new Documentum version, and that it will be released by the end of this month).

Some of the topics/questions covered webtop (of course :D), new features such as iHub (a kind of Jasper Reports for Documentum, including an eclipse-based report designer), a D2 mobile application, and news regarding integration with the cloud.

It looks like the original idea EMC had of connectnig LEAP/cloud with Documentum through services is being pushed with a “common layer” of access in the form of services.

My idea of cloud may be completely wrong, but I don’t consider cloud a “remote datacenter”. Cloud is related to the concept of elasticity: elastic resources, usage and pricing. This means that you could dinamycally increase/decrease available resources according to your needs in a particular moment in time. In order to do this, you don’t just need to “go to the cloud”, you need your software to be able to do that (and Documentum is not able to).

I’m not going to discuss about microservices or containers, but a quick, clear example could be this one: Imagine you have a web application. You allocate one server on the cloud. In the cloud, you could, by defining threshold and behaviours, deal with peak workloads by automatically deploying additional server instances, that will automatically balance the load between them and then return to the “normal” usage without interaction. And this  would be extremely complex with Documentum (I guess you’ll need to configure a certain number of Documentum servers in HA, then stop them, and you could only deploy as many servers as you have previously configured in order to deal with high demand).

So, having discarded the viability of a “pure” cloud Documentum solution (note that I’m not including LEAP here, just the traditional Documentum server), we have two “offers” available:

IAAS: As far as I know, Opentext/Ondemand doesn’t have an IAAS offering available, so the alternative is to go to your favourite cloud provider, buy resources and then deploy Documentum there. However, you won’t get support (I guess this is something to be expected, as Opentext has its own cloud offering). Depending on your case, it might be worth “losing” support if figures make sense (same happened when VM were becoming popular, EMC didn’t support Documentum virtualized, but almost everyone was running it on virtual machines)

SAAS: Rather than cloud, this is a “remote datacenter” offering. Ondemand has fixed prices for this model, and the rest of competitors (if there are others left offering Documentum as a service) follow the same pricing model. This cloud offering, on paper, has the following advantages:

  • Lower TCO
  • Expert administration
  • Quicker startup (what?)
  • Better security (lol)
  • Disaster recovery with SLA response time

But you should have in mind also the following situations:

  • No specific ticketing application. Any operation that needs to be performed has to go through the support page (this includes, but it’s not limited to: creating a registered table, deploying a dar file, accesing dictionary information in d2, issuing SQL queries, running jobs, etc.).  In my experience, agile and rapid development cycles are not compatible with this way of working. Also note that the current Documentum SLAs always use “first response time” and not “time to solve the ticket” as metrics.
  • Better security: Well, if your product has security holes, the hole is there, no matter if it is on premise or on the cloud.
  • Disaster recovery: This is something I always say to clients: If you invest on a cloud environment, first thing to do is destroying the environment as soon as possible and request a recovery. This way you can have an accurate idea of how the provider works.

 

Opentext Documentum is coming next month

I didn’t realize that roadmap documents were updated last month. It looks like the February release is still going to happen (and I’ve been told a definite date, so it looks it won’t be delayed). After reviewing them (haven’t seen any changes :D), I can say:

  • Not much features regarding CS, the pattern/usage visualization and the s3 support (which, as far as I know, can be already done without official support) are the new features.
  • No word about DFS, and I know for a fact that several customers have actively asked for updates to current libs and extended support for application servers.
  • Clients get barely any changes (D2, Webtop, xCP).

I’m curious to see how many bugs are found in this first release from Opentext (and the brave customers that go first into the unknown :D), considering that some of the experienced Documentum staff left the company and the changes to the development cycle (that I guess happen when you move from a hardware company to a software company)

D2 autologin

There was a document in EDN, which now is lost, named “Useful shortcuts and urls for documentum D2”, and one of the URLs was an autologin url, quite useful for development purposes. The url shown was the following one:

D2/?_docbase=<repository>&_username=<username>&_password=<password>

However, although this works fine in D2-Config, it doesn’t work in D2 (>4.2, AFAIK) and this seems to be the case as there are several posts that seem related to this “issue”.

Well, the truth is that there’s still a way to autologin in D2:

D2/?docbase=<repository>&login=<username>&password=<password>

D2-Config DQL Editor

D2-Config (at least in D2 4.5) has a servlet (/GetData) that is used internally to run DQLs. I though when I saw it that, in the same way the REST query service is limited to run read queries, this won’t let you run write queries (you know, due to the “Get” in the name). Well, I was wrong. Any authenticated user can run any kind of query (limited by user permissions, as this is not run as superuser) by using this servlet:

D2-Config/servlet/GetData?dql1=select user_password from (select * from dm_user)&interfaceId=<my session id>&computerName=<my computer id>
D2-Config/servlet/GetData?dql1=create dm_document object set object_name='d2test' link '/Temp'&interfaceId=<my session id>&computerName=<my computer id>
D2-Config/servlet/GetData?dql1=delete dm_document object where folder('/Temp') and object_name='d2test'&interfaceId=<my session id>&computerName=<my computer id>

D2 configuration vs. Doclist widget

One weird requirement customer may want is to show different columns for different types. This kind of requirement is very difficult to meet with obsolete, difficult to customize and migrate webtop, because you’ll need to create a configuration such as:

<config version="1.0">
<scope type="custom_type">
<component id="objectlist" extends="objectlist:webtop/config/objectlist_component.xml">
<columns>
<column>
...
</column>
</columns>
</component>
</scope>
</config>

and be done with it.

Now, how can we achieve this difficult customization in our beloved, configurable, easy to migrate D2? We can’t.

Stupid Useless Limited doclist widget will store a single column preference for the widget, meaning that if you want to apply certain column configuration, it will be applied for every location, no matter the type. Besides, the configuration is stored in the format object_type.attribute. This means that, if you have inherited attributes, you can easily find yourself in the following situations:

  • If you added subtype1.attribute, supertype and other subtypes won’t show any value, and it will only work for subtype1 objects.
  • If you have different labels for the same attribute in different subtypes, only the label for the object_type.attribute you added to the column will be shown (not much of a problem yet, as you won’t see any value).

As far as I know, this has been a feature request since D2 4.5 (released on April 2015), so after almost 3 years, this hasn’t been implemented yet. Even though I’m an optimistic person, and I’m sure (not really) that the “software company” will improve D2, we can, somehow, implement this (in a very rudimentary way, to be honest).

The current behaviour of the doclist widget is basically located in com.emc.d2fs.dctm.content.FolderContent. This class receives a request to retrieve and return the contents of a folder.

The two main methods that are interesting to our requirement would be getContent and getFilteredContent.

These methods receive some parameters, and they generate a query to retrieve objects from the folder, and then return a resulset (DocItems object) with the objects from the folder.

So, in case you want to “configure” the values shown (note that you can’t, or at least I haven’t been able to, change the columns shown in the widget, so data won’t match columns names), you’ll need to:

  • Modify listColNames List of String values with only the attributes you want to retrieve.
  • Take the List of Items returned by the ContentBuilder class and, for each attribute stored, customize the attribute name with the column you want to show the value in.
  • Replace OOTB FolderContent class with your own.

Of course, you have to have this in mind when migrating to a new D2 versions, because I’m quite sure this won’t work as expected in every D2 version…

D2 configuration vs. a_is_hidden

Recently we came across a requirement that involved showing the a_is_hidden attribute in the content widget, regardless of its value.

At first glance, it seemed an easy goal to achieve, just add the attribute to the column list and it will work. Well, it doesn’t. The content widget just displays objects with a_is_hidden=false (duh!).

Next step, would be to find the configuration that manages this behaviour. Well, after looking a bit, we found the “configuration” that handles this:

com.emc.d2fs.dctm.content.FolderContent generates a DQL in order to retrieve the contents of the folder, and the method that generates this query uses com.emc.d2.api.preferences.ID2cPreferences to retrieve different preferences related to queries.

Some decompiling get us to the configurable side of things:

com.emc.d2.api.preferences.D2cPreferences:

 public DqlFilter getDqlFilter()
{
DqlFilter result = new DqlFilter(false, false);
return result;
}

com.emc.d2.api.preferences.DqlFilter:

public final class DqlFilter
{
private boolean m_showHidden;
private boolean m_showArchive;

public DqlFilter(boolean showHidden, boolean showArchive)
{
this.m_showHidden = showHidden;
this.m_showArchive = showArchive;
}

public String toString()
{
StringBuffer result = new StringBuffer();
if (!this.m_showHidden) {
result.append("a_is_hidden = false");
}
if (!this.m_showArchive)
{
if (result.length() != 0) {
result.append(" and ");
}
result.append("a_archive = false");
}
return result.toString();
}
}

So much for configurable application…