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…

CTF extensions not working on Firefox

As expected, once Mozilla has released the new Firefox Quantum moving its extension framework to WebExtensions, the current Webtop/D2 extensions have stopped working. Even if you try to use the Chrome extension by using the Foxified extension, content transfers won’t work.

Let’s see how the “software company” manages this… 😀

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!)

 

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:

webtop_extension

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?)

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.

 

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.

Multiple environments with Tomcat/DA

Similar to the previous post about configuring dqMan/DQLTester (Multiple environments with dqMan/DQLTester), a Tomcat with DA can be configured the same way:

Folder structure:

  • da.bat
  • bin
  • conf
  • jre
  • lib
  • logs
  • webapps
  • properties
    • env1
      • dev
        • dfc.properties
        • dmcl.ini
      • prod
        • dfc.properties
        • dmcl.ini
    • env2
      • dev
        • dfc.properties
        • dmcl.ini
      • prod
        • dfc.properties
        • dmcl.ini
  • etc.

DA.bat:

@Echo off
SETLOCAL ENABLEEXTENSIONS
SET folderbase=dfcproperties

echo ****************
echo 1. env1 dev
echo 2. env2 prod
...
echo ****************

SET /p var= ^> Choose option: 

if "%var%"=="1" goto op1
if "%var%"=="2" goto op2
...

:op1
SET foldervar=%folderbase%\env1\dev
goto finish

:op2
SET foldervar=%folderbase%\env1\prod
goto finish
...

:finish
set JAVA_HOME=%cd%\jre
set JAVA_OPTS=-Ddfc.properties.file=%cd%\%foldervar%\dfc.properties -Dfile.encoding=UTF-8 -Xms128m -Xmx512m -XX:+UseG1GC -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true -Djava.net.preferIPv6Addresses=false -Djava.net.preferIPv6Stack=false

start "" /D %cd%\bin /B %cd%\bin\catalina.bat start
cls&exit