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.
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.
Similar to the previous post about configuring dqMan/DQLTester (Multiple environments with dqMan/DQLTester), a Tomcat with DA can be configured the same way:
echo 1. env1 dev
echo 2. env2 prod
SET /p var= ^> Choose option:
if "%var%"=="1" goto op1
if "%var%"=="2" goto op2
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
What does this mean to Documentum? Well, if your Webtop/D2 is using applets (UCF), starting March, you’ll only be able to use it with IE11 and older versions, as no other major browser (actually, Firefox is the only “major” browser that still allows NPAPI plugins, but this is due to their slow pace of development) will allow NPAPI plugins (Java).
CTF (Content Transfer Framework) is how
EMC Dell calls their “new UCF”. It works as a browser extension, and is the same extension you’ve used for the latest version of Webtop (new functionality getting first to Webtop? LOL). And this mode is not the default (why?) so you’ll need to change it in the settings.properties file of D2.
Also, this extension will generate some “index” files on the folder where you download files:
That contain object names, ids, operation performed, and folder paths of the files transferred.
Tested on latest Firefox Nightly x64 and Chrome.
FYI, I’m pasting the “wonderful” ASCII compatibility matrix provided by Dell in the configuration file:
# | Browser:OS \ Mode | Thin | Java | ctf | Note |
# | IE 11 | yes | yes | yes | |
# | Edge | yes | NO | NO | (1) |
# | Firefox | yes | yes | yes | |
# | Chrome | yes | NO | yes | (1) |
# | Safari:Mac_OSX | yes | yes | yes | |
# | Safari:Mac_IOS | yes | NO | NO | (2) |
# (1) Chrome and Edge do not support java applets, and Edge does not support the CTF plugin.
# D2 will fallback to thin client mode appropriately when java or ctf has been
# specified in the value of the browser.plugin.mode setting as described above.
# (2) If browser.plugin.mode contains java or ctf, then D2 will silently continue to run in
# thin client mode. Safari running on Mac_IOS does not support the java or ctf plugin.
- Prompt for installing the extension:
What I think OpenText should keep:
- Support Community
- EMC Support (at least the search engine with the knowledge base)
- Download Center (After so many changes, I really don’t want to change again :P)
- EMC GitHub
- Webtop (It’s the only client that works OOTB)
What I think OpenText should change:
- Sales policy (Stop pushing products that customers don’t need, and yes, that means D2 and xCP for customers that simply want a “library”)
- Sort libraries/dependencies in the Documentum stack (if 7.x is released, make it that every product has the same version of every library). Rebrand products accordingly (yeah, Webtop 7.x if it is using DFC 7.x)
- Detailed changelog of the products (don’t force us to go through every single customization to check if some component we’re extending has changed and broke the customizations)
- Kill lockbox with fire (or at least, make it optional for both CS and D2). Nobody understands it, nobody knows how to set it up, so it is more a pain in the ass than a security feature
- Oh, and remove D2 dependency on JMS
I’ve lost any hope to see dmbasic gone for good, or JBOSS replaced with something “lighter”, that’s why those didn’t make it into the list (as probably many others, that I don’t remember now)
(And yes, I’m not a huge fan of D2 :P)
Yesterday I saw Webtop 6.8.2 was released, and as this was great news because this version was supposed to remove Java applets once and for all. While most of us though that removing applets would imply moving to HTML5, EMC has decided to implement an intermediate solution 😦
Webtop 6.8.2 will prompt users to install a browser extension first time you log in:
In Firefox the extension will be installed, and in Chrome user will be redirected to the Chrome Web Store:
After installing the extension, the first time users try to download something they’ll be prompted to install a local application that will handle the transfers (WebSockets I presume).
Good news: Now you don’t need to fight with Java/browser combination
Bad news: Users have to perform operations. Not the cleanest solution (IMHO).
Bonus: Now importing files is really not-user friendly:
- File -> import
- Ugly Java window will pop-up over the import container asking for files to import
- Select files/folders, press ok and… nothing happens. You are kept in a blank container window with “Next” and “Finish” buttons and no indication whatsoever if the files are been/have been uploaded or what is going on.