May 2, 2018 | by Maximilian Krone | 0 Comments

This blog article looks at OpenText’s Documentum REST API and provides insight into its technology, basic functionality and extensibility capabilities. Here I report from my own experiences and I am happy if I can help other “techies” like me a little with it 😉

What is the “Documentum Rest API”?
In principle, the term Documentum REST API refers to a web interface introduced with Documentum 7 that allows access to objects and functions of OpenText Documentum. This is based on Spring-Boot, is delivered as a WAR file and must be installed on an application server – e.g. Apache Tomcat. This interface can be used to write customized clients, apps, or plug-ins of other systems.

read more

Feb 20, 2018 | by Steffen Fruehbis | 0 Comments

In the regulated life sciences environment, the management of controlled documents such as SOPs (Standard Operating Procedures), procedural instructions or work instructions is of great importance. Change management processes ensure that these documents are properly revised, approved, trained, distributed and, where necessary, suspended. In addition to well-known use cases within change management, there are special cases that are handled differently from company to company.

One of these applications is the rare case of so called Effectivity Hold. read more

Aug 24, 2017 | by Jörg Friedrich | 0 Comments

Sometimes not the leading edge technologies are causing you headaches, but also solid requirements like synchronizing your Document object’s attributes with SAP.
In this blog post I will explain the differences and purposes of the OpenText Documentum Archive Services for SAP and OpenText Documentum Content Services for SAP as well as the challenge to synchronize only modified SAP data into OpenText Documentum.

OpenText Documentum Archive Services for SAP
The main purpose of the OpenText Documentum Archive Services for SAP (ASSAP) is to accept content (e.g. the printable bill) delivered by SAP. For this, the ASSAP exposes as ArchiveLink server. With the ArchiveLink protocol, SAP is not only able to archive content but also able to retrieve that content for display purposes. Such content can be for example billing documents. So the active part is SAP. OpenText Documentum is the passive part. The ASSAP will create the link information with SAP archive maintenance data.

OpenText Documentum Content Services for SAP
In short, if you want to interact with SAP in another way than using the ArchiveLink protocol, you need the OpenText Documentum Content Services for SAP (CSSAP).
The mapping is defined by the Document configuration objects, which are text based.
Configurations can be e.g. a mapping of a SAP attribute to an OpenText Documentum attribute or a query executed either against OpenText Documentum or SAP.

Scenario 1:
If you have the content first in OpenText Documentum and want it to link with SAP, a barcode link is a possible way to archive this. The available barcodes inside OpenText Documentum have to be published to SAP. With this, the user can link e.g. a SAP billing document with an available (external) barcode. After this, the Document object (and its content) is linked to the appropriate SAP object and the content can be retrieved via the ArchiveLink interface (exposed by the ASSAP).

Scenario 2:
You want to pull metadata e.g. from a billing document from SAP to OpenText Documentum. For this, suitable search criteria are needed (the receipt number, the ArchiveLink ID, etc.) to build a query against SAP. All matching SAP objects are then mapped to OpenText Documentum objects and all configured attributes are copied from the SAP object into the corresponding OpenText Documentum object. Mapping of attributes might not need necessarily to be linked to the same OpenText Documentum object holding the content. It is up to you how you want to define the mapping rules.

Scenario 3:
You can also modify SAP data based on OpenText Documentum objects’ values. However pulling data from SAP can be performed with standard RFC calls. For pushing data to SAP, the best way is to utilize a custom BAPI created especially for that purpose.

Delta Synchronizations
The CSSAP works best for one-time synchronizations based e.g. on missing data or on specific lifecycle status names.

However with some tweaks you can get the best value of CSSAP and enable delta synchronization abilities:

  • Perform a query against SAP to determine all modified SAP data. For this, weave into the SAP query conditions (query parameters) conditions for querying e.g. a modification date.

For example a regular query parameter inside ASSAP looks like this:

Modification Date=20170401

Change this line e.g. to

Modification Date=‘00000000’ OR AEDAT GE ‘$modified’ OR ERDAT GE ‘$created’
$DQL=select max(any_tracking_creation_date) as created, max(any_tracking_modification_date) as modified from your_object_type

With this change all creations (field ERDAT) and modifications (field AEDAT) can be identified.

  • Based on the result of the above query mark all OpenText Documentum objects subject to synchronization (to be more fault tolerant).
  • Now perform a query against SAP to match all objects in scope of the synchronization. Inject e.g. the receipt no into the SAP query of all pending OpenText Documentum objects. Consider to limit the amount of injected parameters (e.g. the amount of receipt numbers and by this the amount of retrieved receipts) to avoid a synchronization process which will span over a too long time period. Due to the split into a mark and a synchronization step, postponing object synchronization to subsequent synchronization runs is no problem. Either abort of the synchronization step is no problem. The next run will synchronize missed objects. The limitation of the amount of objects can be done e.g. by the DQL hint “return_top N”.
  • Consider increasing the amount of objects within a single transaction (CSSAP configuration) from 1 (default) to a huge amount of objects. By this, the mark step will get fault tolerant and nevertheless the amount of objects processed by ASSAP is limited by the above mentioned object limitation (enforced by the hint “return_top N”).

All taken together, you can achieve a delta metadata synchronization from SAP into OpenText Documentum.

Don’t hesitate to get in touch with me or to share your thoughts and ideas with me!

Apr 27, 2017 | by Antje Dwehus | 0 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 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”);

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:


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.


Feb 15, 2017 | by Matthias Rebettge | 0 Comments

For many years now we have seen a trend away from physical hardware and towards virtualization. The reasons are diverse: costs need to be reduced, activities should be automatized and downtime decreased. For a long time virtualization was a synonym for replicating complete server including the operating system. But since the launch of Docker in 2003 the so called „container-based virtualization“ is finding its way into the IT infrastructure of companies.

This trend does not stop even for ECM based software so that DELL EMC (in the meantime acquired by OpenText) launched the Documentum Content Server Version 7.3 with Docker support in November 2016 for the first time.

read more

Oct 19, 2016 | by Klaus Beckmann | 0 Comments

ecm platform uncertainties

Imagine, you have a set of user stories for a new enterprise content management (ECM) application. And you have an existing ECM platform up and running or you have selected a new one, but you are uncertain about the platform’s future. You will have to invest money for custom development to make users happy, and you want the solution to be supported for the next decade.

You have two options: stay with your current ECM platform or select a new one. But the decision process takes time – or you give it a try and test a new platform within your project. There are a lot of pros and cons and no general recommendation. It depends on your situation and the requirements for the new application.

read more

Sep 23, 2016 | by Dirk Bode | 0 Comments


Interesting announcement from Alfresco. They started an aggressive > swap out program against Documentum pushing the fear that Documentum is going away or going south soon. First of all, Alfresco is a really good ECM platform – fme has been an Alfresco partner for many years. There might be good reasons for the one or the other company to decide to change their ECM platform within the next weeks or months, but it should have nothing to do with the OpenText acquisition. Fear has always been a bad advisor. Documentum is not going away any time soon, or why do you think OpenText payed 1,6 billion USD? They have to keep up the flow of maintenance money for quite some years to make the deal work.
read more