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,
“code”: “E_INPUT_ILLEGAL_ARGUMENTS”,
“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
r_creation_date
—————
12/04/2013
(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": "http://127.0.0.1:8080/dctm-rest/repositories/repo.json?dql=select%20DATETOSTRING_LOCAL(r_creation_date,%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": "http://127.0.0.1:8080/dctm-rest/repositories/repo/types/dm_document.json",
"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())
  .getMandatoryAttribute("r_modify_date");
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())
  .getMandatoryAttribute("r_creation_date");
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 com.emc.documentum.rest.view.impl.QueryResultItemView 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.

 

Support adventures

I’ve said many times that support is mostly useless, and that support metrics do more harm than good.

I’m currently involved in a migration from an old 6.0 environment to 7.x (this means that we have to install a clean 6.0 in the new servers, upgrade to 6.6 then upgrade to 7.x), so, as 6.0 is out of support, the downloads aren’t available. Of course, this means having to engage with support, while the customer approaches OpenText reps to get the installers. As expected, the support way was quite short:

Me: Can we have access to the Documentum 6.0 for Linux/Oracle installers in the download section or in the FTP?

Support: Unfortunately Documentum 6.0 is out of support .You can access the documentum content server 6.6 and later versions

From a support metric perspective, this gaves support “premium” rating:

  • Incident resolved: check.
  • Time from opening the case to closing it: 2 hours.

So, for support, this a success history (plus a bonus, because they’ve used their registry of solutions to provide a “solution”, for sure is great for a hardware company).

However, the sad truth is that nothing has been resolved (as if I wasn’t aware that 6.0 is out of support) and we’ll have to wait until some representative from OpenText provides us with the installers in order to perform the upgrade (assuming that OpenText has some interest in keeping customers that bother to upgrade their environments).

Filename in Documentum REST Services

If you have used Document REST Services you most likely have realized that downloading any content from an object return a “document”/”response” + dot + file extension.

You can check William Zhou’s answer here:

This had been discussed in the initial implementation but hadn’t been implemented since Content-Disposition response header is neither mandatory nor handled by all HTTP clients. Besides, it has some overhead to map the format/mime to a filename extension. But I think it has values helping for the download experience. It is appreciated if you can file a feature request CR so that we can discuss this with the product manager.

I’ve alredy raised a SR to support in order to get OpenText to consider adding this “feature”.

However, if you can’t/don’t want to wait, just “extend” com.emc.documentum.rest.controller.ContentMediaController adding the following line to the getContent method just before returning the response:

headers.setContentDispositionFormData("attachment", (String)co.getAttributeByName("object_name"));

and you’re good to go.

 

Updated roadmap, webinar and FAQ from OpenText Documentum

If you registered for the webinar OpenText held a few weeks ago (if you didn’t, maybe you can check Andrey’s post on the subject), you should have received an invitation to some site from OT with a FAQ about the Documentum stack. I’m not going to paste it here, just in case it’s not public, but IMHO, the highlights are:

  • Content Server: Aligment with ECD. No new features but trying to move to a microservices architechture. It probably means CS won’t evolve anymore.
  • Webtop: Several points on this. Will keep being supported and updated to support latest CS.
  • Rest: Every new product based on this. No mention about DFS (I hope it’s dead, unless they decide to update with libraries from this decade)
  • xCP: It looks like xCP 1.x support will be over by the end of 2019.
  • Support: Still through EMC’s site until the end of the year.

Support almost got it right

I was dealing with a problem with D2 (ha!), and suspected that I couldn’t be the first one having this issue so I decided to check support page. I found the problem and a “solution”, but I couldn’t avoid thinking about “Maybe OpenText will add value to Documentum after all” and theย “talented team” when I saw the solution:

Clearing d2c_preferences object resolves issue, using the below DQL:
delete from d2c_preferences where object_name='<User Name>’

It was close enough to be filled as a solution, I guess ๐Ÿ˜€