OpenText Documentum ist ein vollwertiges und ausgereiftes serverbasiertes Dokumentenmanagement-System, welches z.B. von der FDA akzeptiert und daher in Pharmaunternehmen weit verbreitet ist.

Im Vergleich zu Cloud Computing-Technologien, die sehr stark in der Bereitstellung elastischer (skalierbarer) Dienste sind, könnten OpenText Documentum Produkte als unflexible und monolithische / mehrschichtige Anwendungen betrachtet werden. Obwohl sie das genaue Gegenteil des flexiblen Ansatzes der Microservice-Architektur zu sein scheinen, die für das Design nativer Cloud-Anwendungen verwendet wird, gibt es Möglichkeiten, OpenText Documentum-Produkte mit Cloud Computing-Technologien zu kombinieren.

Hier sind einige Beispiele, die Ihnen eine Vorstellung davon geben, wie Sie mehr Flexibilität erreichen  indem Sie entweder die OpenText Documentum Basisinstallation oder die Geschäftslogik in kleinere Dienste aufteilen:

Infrastruktur-Dienste

Eine klassische OpenText Documentum Content Server Installation könnte in vier Dienste / Linux-Container aufgeteilt werden:

• der Docbroker,
• die Repository-Services,
• den Java Method Server (serverapps.ear)
• die Accelerated Content Services (acs.ear)

Es ist klar, dass der Docbroker nicht viel Verkehr zu bewältigen hat und kein Lastverteilung benötigt. So könnten maximal ein oder zwei Instanzen ausreichen (ergänzt durch eine entsprechende Kontrollüberwachung), um ein robustes Failover zu gewährleisten.

Für die Repository-Services, den Java Method Server und die Accelerated Content Services, würden jeweils zwei Instanzen ausreichen, um einen recht robusten Service bereitzustellen.

Es kann jedoch sein, dass Sie beispielsweise eine Datenmigration in Ihr Repository mit vielen Dokumenten durchführen möchten. In dieser Situation denken Sie vielleicht einmal daran, unser hochqualifiziertes Content-Migrationsteam zu beauftragen. Während der Migrationsphase, insbesondere bei Systemen, die den Java Method Server stark beanspruchen, würde genau dieser Dienst zu einem Engpass werden. Alle anderen Serverkomponenten wären in der Lage, alle Migrationsaufgaben zu bewältigen.

Und hier wird es interessant: Wenn Sie die Service-Architektur wie oben beschrieben genutzt hätten und ein Orchestrierungswerkzeug verwendet hätten, wären Sie innerhalb von Minuten in der Lage gewesen, zwei weitere Java Method Server-Instanzen on-demand anzufordern. Das Orchestrierungswerkzeug erzeugt automatisch zwei weitere Instanzen, die automatisch über einen Service-Endpunkt bereitgestellt werden. Alle anstehenden Migrationsanfragen werden dann auf alle vorhandenen Instanzen verteilt, um eine gute Migrationserfahrung zu gewährleisten. Sobald die Migration abgeschlossen ist, können Sie die Anzahl der Instanzen reduzieren.

Business-Logic-Dienste

Wenn Sie z.B. OpenText Documentum D2 verwenden und potentiell “schwere” logische Dienste wie Wasserzeichen nutzen, können Sie echte Dienste (Microservices) erstellen und diese mit Service Discovery Tools mit Load Balancing-/Failover-fähigen Clients (z.B. Netflix OSS – Eureka, Ribbon, Hystrix) verbinden. Mit dieser Option wird der Wasserzeichendienst für alle zukünftigen Anforderungen skalierbar und flexibel und kann nach Bedarf auf dedizierte Computerressourcen platziert oder verschoben werden. Wenn dieser Dienst zu einem bestimmten Zeitpunkt als Engpass identifiziert wird, können Sie Ihr Orchestrierungswerkzeug anweisen, weitere Instanzen desselben Dienstes anzulegen. Falls es ein einmaliges Ereignis wie eine Einreichung bei einer Behörde gibt, weisen Sie Ihr Orchestrierungswerkzeug beispielsweise an, zusätzliche Instanzen desselben Dienstes zu erstellen. Dieser Dienst lässt sich nach Beendigung des spezifischen Ereignisses herunterskalieren, um Ihre Hardware-Ressourcen effizient zu nutzen.

Fazit

Scheuen Sie sich nicht, das Beste aus beiden Welten zu nutzen! Wir unterstützen Sie dabei, beide Technologien zu kombinieren und Ihnen beste Ergebnisse zu liefern!

• Analyse Ihrer bestehenden OpenText Documentum Infrastruktur-Architektur
• Analyse Ihrer bestehenden OpenText Documentum Software-Architektur
• Erstellung einer Roadmap, wie Sie Ihren OpenText Documentum Stack für Cloud Computing vorbereiten können.
• Aufstellen von Best Practices, wie Sie zukünftige Komponenten in Ihrem bestehenden OpenText Documentum Stack erstellen, um sie flexibel zu machen und den Konzepten des Cloud Computing zu entsprechen.
• Anwendungslogik (wo zutreffend) in elastische Microservices überführen

Wir freuen uns darauf, unser Know-how mit Ihnen zu teilen!