Insights Into OpenText Documentum Webtop 6.8.2 – We’d Love to Share Our Experience
Apr 27, 2017 | by Antje Dwehus | 2 Comments

Despite the ongoing discussion about the prospects of new web technologies, progressive clients or even the need of an unmitigated new user experience, many enterprises are still using the “good old Documentum Webtop” quite contentedly. In general, Webtop applications integrate smoothly with other systems that have spawned over time such as Jive, Jira, CRM and others.

Nevertheless, let’s be honest. There have been some flaws and one of them has always been the content transfer mechanism UCF which can be hard to maintain especially in complex network settings and which causes an annoying dependency on the client’s Java Runtime Environment. With modern browser vendors reducing plugin support and the decision of Oracle to deprecate the Java browser plugin in Java 9, a new content transfer mechanism was long overdue.

So well, with Webtop 6.8.2 a new content transfer mechanism is finally available and therefore the demand of updating those Webtop applications has increased. I was excited to migrate the first Webtop application, which includes some minor customizations from 6.7 SP2 to 6.8.2. A quick gaze at the release notes made me aware of another considerable change: There is no support for modal dialogs anymore, irrespective of the technical aspect. What came to my mind instantly was, that this time the version change is going to be recognized by the users, unlike in preceding changes, where the UI almost remained identical. And that might lead to the potential need for some kind of explanation e. g. adaption of training material. But let’s put this thought aside for the moment and refocus on the update process.

Preparation of the Application Server
First, I installed the original version of Webtop 6.8.2 without any customizations, to ensure that the new content transfer mechanism was working in our environment. In order for it to work properly the following line has to be inserted into the server.xml of Tomcat between the <Engine> and <Host> tags:

<Context path=“/webtop” useHttpOnly=”true”/>

After the adaption of the dfc.properties file and custom\app.xml and followed by a Tomcat restart, I was able to reach Webtop and the Loginmask.

On the Client: Browser Extension-based Content Transfer Using Firefox
The browser extension-based content transfer mechanism exists of two components:
1. Content transfer browser extension
2. Native client application (needs JRE running on the client machine)

When accessing the Webtop with Mozilla Firefox I was prompted to install the extension (Figure 1). OK, no problem, did that.

After a browser restart a pop-up window appeared, which asked for the native client application to be installed. I saved the exe, executed it and restarted Firefox.
And that was it – the content transfer worked!

Figure 1 Installation of browser extension and client application

So, let’s have a closer look at the client:
On the client, you will find the two components. The content transfer browser extension can be found in the Add-On Overview of Mozilla Firefox (Figure 2) whereas the native client application is listed in the Windows Programs and Features control panel (Figure 3 ).

Figure 2 Firefox Add-ons Webtop Content Transfer extension

Figure 3 BHO in Programs and Features

I also tested Google Chrome and Microsoft IE 11, both worked. The IE is a little more complicated regarding the various security settings that have to be met.

Test Environment

Contentserver: 7.2 P22
Application Server: Tomcat: 7.0.33, with jdk1.7.0_51
Client Machine: Win 8.1 64 bit JRE 8 update 121
Client Browser : IE 11, Firefox 52.0.1 (32-Bit), Google Chrome 57.0 (64-bit)

Deploying the Customizations
I didn’t experience any problems regarding the compilation of the custom source code with the new java version and dfc, wdk classes. But with this new release there came a few important changes in the JSP Pages, some of them essential for the content transfer mode. Therefore, all custom JSPs, which were created as a copy of the original JSP and then modified, need a close analysis.
For example, the titlebar.jsp imports three more classes and performs a check for the browser extension.

Code extract from titlebar.jsp

<%@ page import=“com.documentum.web.common.ClientInfo“ %>
<%@ page import=“com.documentum.web.common.SessionState“ %>
<%@ page import=“com.documentum.web.form.Form“ %>
….

if (ClientInfo.useBrowswerExtension(request))

If you don’t have that in your custom titlebar.jsp, the new content transfer won’t work.
Additionally I found the following code, which handles the handshake for the transfer mechanism, in the main_ex.jsp:

Code extract from main_ex.jsp

<% if (ClientInfo.useBrowswerExtension(request)){ if(ClientInfo.isChrome(request) || ClientInfo.isFirefox(request)){ %>
var handshakeelement = document.createElement(„div“);
handshakeelement.setAttribute(„id“, „dohandshake“);
document.documentElement.appendChild(handshakeelement);

You should also revise the layout of all custom components that use a modal pop-up window. Here is an example of a custom search dialog, before and after the update:

         p

Figure 4 example of a custom search dialog, before and after the update

Impressions at a Glance

  • Despite the new content transfer mechanism the client still needs the JRE installed
  • To install the Helper Object (BHO) users need to have administrator privileges on the client. If that is not the case in your enterprise, you need to think of a way for a roll out. Which probably makes sense anyway, because users have to perform operations in order to install the components for the content transfer and that could lead to many support calls.
  • Due to changes in the JSP Pages and the abolition of modal pop-up windows the effort for upgrading a highly customized application might be higher than in preceding upgrades.
  • Good news: You won’t have to fight with the java/browser combination anymore
  • There will be changes in the UI which might force you to update documentation and training material, especially if your application uses a lot of modal pop-up windows.


My Conclusion

In my opinion, the upgrade to OpenText Documentum Webtop 6.8.2 is worth the effort, if you plan to maintain your Webtop application for a couple of years. The new transfer mechanism does its job and makes you ready for the next browser generation without Java Applet support. The absence of modal dialogs might force you to some redesigning, but on the other hand your good old Webtop application will look reasonable even on tablets – that’s a change.

If you have further questions or need help with a specific issue or specific settings and environments, we are happy to further share our experience with you.