OpenText Documentum is a full-fledged and mature server-based Document Management System which is accepted e.g. by the FDA and therefore widespread in pharmaceutical companies.
Compared with cloud computing technologies that are very strong in providing elastic (scalable) services OpenText Documentum products could be regarded as inflexible and monolithic / layered applications. Although they seem to be the exact opposite of the flexible Microservice architecture approach used for cloud native application design, there are ways to combine OpenText Documentum products with cloud computing technologies. read more
Containers, here I will call them more specific Linux containers, are in short modularized software installations. Think of a container as an isolated area with a self-contained service. The container consists of all dependent software the service needs to run. Each container / service can connect to other containers / services. Because the containers are isolated to each other, they are not able to interfere with others in terms of software versions and runtime behavior. For each container you can plan separately on which Linux operating system, web server, language interpreter, etc. your service will rely on — which best fits to your needs. That means, that for example for excessive use of threading or performance needs a single service could be written in Go Lang based on Alpine, while another one uses Apache with PHP also on Alpine and a third one needs to comply with prerequisites using Tomcat with Java on CentOS. All this is possible with containers even running on the same host.
From 1997 to 2007 I was employed at Documentum in Munich and was responsible for the technical sales issues for Central & Eastern Europe, Middle East and South Africa. I witnessed the birth of the fme – Documentum partnership in 1998 at close quarters. With fme Documentum had found the ideal partner to realize projects in Germany. Since then I have always followed the development and international growth of fme. That’s why I’m all the more pleased I joined the fme in 2015 and am now responsible for content management and cloud business as a board member of fme AG.
At fme we are proud that this year marks the 20th anniversary of our partnership with Documentum, now part of OpenText. It is a success story with countless successful client projects, a world renowned product that has been certified for more than 10 years, extensive platform and industry-specific process know-how and a great team of highly specialized employees.
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.
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
Who hasn’t already made the painful experience of how bad communication has led to additional costs and reduced the quality of a project at the same time? We don’t want that to happen at all and therefore most project leaders today are very aware of the importance of communication within their project.
To help keeping your communication straightforward in a migration project, let’s have a closer look at the mapping specification as a crucial document in migration projects.
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.
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.
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.
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.