Compart - Dokumenten und Output-Management

Entwicklung und Technologie

Packaged Business Capabilities für die Omnichannel-Kommunikation von Unternehmen, Organisationen und Behörden

Compart |

Small Is Beautiful

Granulare Microservices (Packaged Business Capabilities), die sich schnell und nahtlos in bestehende IT-Infrastrukturen einschließlich Cloud-Umgebungen einbinden lassen, halten auch in der Kundenkommunikation von Unternehmen und Behörden immer mehr Einzug. Technologien wie Docker und Kubernetes liefern die notwendige Grundlage für deren Bereitstellung, Verwaltung und Skalierung.


Das Ende großer monolithischer Anwendungen naht

– so der Marktanalyst Gartner in seiner kürzlich vorgestellten Analyse „Top Predictions for 2020 and Beyond: Technology Changes the Human Condition“.¹ Stattdessen werden sie zunehmend durch einen Ansatz ersetzt, bei dem Unternehmen ihre Applikationen aus kleinen, individuellen Bausteinen zusammensetzen, idealerweise unter Verwendung von Entwicklungsumgebungen wie Low Code/ No Code. Dabei komme Microservices bzw. API-Diensten eine Schlüsselrolle zu. Gartner erwartet, dass der Anteil der auf diese Weise ausgelieferten Anwendungen bis 2022 auf 30 Prozent steigen wird (gegenüber drei Prozent in 2019).

Laut Gartner sind monolithische Anwendungen wie traditionelle Musikalben der Vergangenheit: Man musste immer das gesamte Album kaufen, um den einen Song, der einem gefällt, hören zu können. Im Musikkonsum ist es daher inzwischen gang und gäbe, sich nur die Titel, die man will, herunterzuladen und zu einer individuellen Wiedergabeliste zusammenzustellen. Bei Software ist es laut Gartner ähnlich: Auch hier werde oft nur ein Bruchteil an Funktionen, die eine monolithische Unternehmensanwendung zur Verfügung stellt, tatsächlich genutzt. Daher finde auch hier eine Verlagerung hin zu SaaS-Lösungen und API-Diensten statt, die den Anwendern wesentlich mehr Komfort und Flexibilität in ihrem Tagesgeschäft böten, so die Analyse weiter. Statt an das starre Design einer einzigen „großen“ Anwendung gebunden zu sein und daran die existierenden Unternehmensprozesse ausrichten zu müssen, verleihe ihnen der Einsatz solcher granularer Microservices die notwendige Agilität, um auf Marktveränderungen schneller reagieren zu können unter Beibehaltung der vorhandenen IT-Infrastrukturen.

Tatsache ist, dass die Nachfrage nach Low-Code-Tools, SaaS-Lösungen und API-zentrierten Microservices steigt. Selbst eher konservative Branchen wie die öffentliche Verwaltung oder die Logistik- und Fertigungsindustrie beschäftigen sich zunehmend mit dem Thema. Kein Wunder, denn generell stehen die IT-Abteilungen unter enormem Effizienz- und Kostendruck. Sie müssen mit den verfügbaren Ressourcen das Maximale aus den existierenden Systemen herausholen, jederzeit eine Hochverfügbarkeit gewährleisten und dürfen dennoch keine „Überkapazitäten“ anhäufen. Es geht also neben der geschäftlichen Agilität auch um eine optimale Auslastung der IT-Ressourcen.

Gartner jedenfalls rechnet damit, dass bis zum Jahr 2023 etwa 40 Prozent der Anwender ihre Geschäftsapplikationen individuell zusammenstellen entsprechend ihren Bedürfnissen. Das könnte dann beispielsweise so aussehen, dass die Funktionen nicht wie bisher „im Stück“ (All-in-One-Paket) angeboten werden, sondern als eine Sammlung von Bausteinen (API-Diensten), die dann je nach Geschäftsanforderung von den Anwendern eingesetzt werden. Gartner spricht in diesem Zusammenhang von „Packaged Business Capabilities“, die immer mehr zum Tragen kommen.

Infobox

Lesedauer: 10 Min

  • Orchestrierung von Software via Kuberntes
  • Packaged Business Capabilities in der Kundenkommunikation
  • Einsatzszenarien in Cloud-Umgebungen
  • Microservices von Compart

Automatische Orchestrierung von Microservices

Mit der zunehmenden Verbreitung solcher Services steht natürlich auch die Frage nach ihrer Bereitstellung und Verteilung (Deployment). Hier kommen mittlerweile bewährte Technologien wie Container bzw. Docker, als ein bekannter Vertreter der Container-Technologie, ins Spiel (siehe Glossar weiter unten). An sich nicht neu, haben sie das Deployment von Mikroanwendungen (Microservices) entscheidend revolutioniert: Sie lassen sich beliebig je nach Bedarf skalieren und laufen auf allen Plattformen gleichermaßen stabil und zuverlässig.

Dadurch erreicht man die o.a. erforderliche Agilität – auch, wenn man bestimmte Funktionen oder eben auch eine Packaged Business Capability aktualisieren oder neue implementieren will. Statt wie beim „monolithischen Ansatz“ die gesamte Lösung updaten zu müssen, wird hier nur das Image mit dem betreffenden Microservice ausgetauscht. Wenn beispielsweise die Deutsche Post neue Portorabatte gewährt und man hat innerhalb seines Output-Management-Systems (OMS) eine Funktion „Portooptimierung“ als granularen Microservice im Einsatz, wird der alte durch den neuen einfach ersetzt, ohne dass die übrigen OMS-Prozesse „lahmgelegt“ werden.

Bleibt die Frage, wie man die Verteilung, Skalierung und Aktualisierung dieser Container möglichst automatisieren kann, um jederzeit eine Hochverfügbarkeit garantieren zu können. Man muss sich vor Augen halten, dass beim Auflösen einer monolithischen Applikation in zig oder hundert verschiedene Services eine komplexe Landschaft entstehen kann, die sich manuell nur schwer managen lässt.

Aus diesem Grund wurden Systeme entwickelt, über die man diese Services als Container überwacht und steuert, also „orchestriert“. Kubernetes ist in diesem Zusammenhang sicher die bekannteste Plattform (siehe Glossar). Grundprinzip ist, dass man die Services in Form von Containern auf mehrere „Knoten“ (Nodes) verteilt. Dadurch ist garantiert, dass beim Ausfall eines Servers die geschäftskritischen Services trotzdem weiter verfügbar sind.

Auch beim Skalieren kommen die Vorzüge solcher „Orchestrierungs-Plattformen“ deutlich zum Tragen. Steigt beispielsweise die Lastanforderung für einen bestimmten Dienst, lässt sich das in Echtzeit überwachen und es können bei Bedarf zusätzliche Services automatisch hinzugefügt werden, um unverändert eine hohe Performance zu garantieren.

Inzwischen besitzt Kubernetes eine große Unterstützerbasis bei den großen Cloud-Anbietern wie Microsoft Azure, Amazon Web Services, oder auch IBM/Red Hat. Unabhängig davon, ob man die Gesamtlösung „on premise“, als private Cloud oder in gehosteten Cloud-Umgebungen betreibt – die „Orchestrierung“ der Container-Anwendungen lässt sich für verschiedene Einsatzszenarien umsetzen. Dadurch ist diese Plattform geradezu prädestiniert für hybride IT-Umgebungen. Mit anderen Worten: Wer über eine Architektur auf der Basis von Microservices verfügt, besitzt gute Voraussetzungen, mittels standardisierter Methoden wie Kubernetes diese Services automatisch zu skalieren und den Dienst bzw. die „Business Capability“ jederzeit hochverfügbar zu halten.

Video

Packaged Business Capabilities

Sehen Sie das Video über die neue Herangehensweise für die Bereitstellung von Anwendungen in der Kundenkommunikation. Gebündelte Geschäftsfunktionen (Packaged Business Capabilities), die sich schnell und nahtlos in bestehende IT-Infrastrukturen einschließlich Cloud-Umgebungen einbinden lassen. Präsentation von Dr. François Charette, Chief Architect, Compart AG

Packaged Business Capabilities für die Dokumentenverarbeitung

Die zunehmende Aufsplitterung von „mächtigen“ Software-Lösungen in kleine, skalierbare und leicht zu integrierende Packaged Business Capabilities ist auch in der Kundenkommunikation zu beobachten. Hier treibt beispielsweise Compart das Thema voran. Der international agierende Hersteller von Software für die Omnichannel-Kommunikation hat bereits die Basis geschaffen, Anwendungen innerhalb der DocBridge® Produktfamilie in Cloud-Umgebungen bereitzustellen.

Im Kern geht es darum, ausgewählte Funktionen als sogenannte Services anzubieten, die dann über gut dokumentierte und leicht handhabbare Web-APIs (in der Regel nach dem REST-Muster) in bestehende Infrastrukturen schnell und problemlos eingebunden sowie mit Drittanwendungen verknüpft werden können.

Schon heute sind etliche DocBridge® Produkte in dieser Form als Packaged Business Capabilities verfügbar, die sich für dezidierte Prozesse im Output- und Dokumentenmanagement einsetzen lassen. Dazu zählen beispielsweise DocBridge® Impress (Dokumentenerstellung), DocBridge® Conversion Hub (zentraler Konvertierungsdienst im digitalen Posteingang) und DocBridge® Document Viewer (universeller, web-basierter Viewer für nahezu jedes Format). Dank ihrer Granularität stellen sie eine lohnende Alternative zu monolithischen on-premise-Applikationen dar.

Compart wird das Angebot solcher Lösungen in Zukunft kontinuierlich weiter ausbauen. Eine zentrale Rolle spielt in diesem Zusammenhang DocBridge® Gear, eine Software-Plattform für die Modellierung von wiederverwendbaren Aufgaben und Prozessen, sogenannten Worklets, die über entsprechende APIs aufgerufen werden können. Verlangt ein Kunde beispielsweise ein spezielles Tool für die Konvertierung von AFP nach PDF, reicht es aus, einen entsprechenden Prozess aus einigen Worklets zu modellieren, der dann per API eingebunden werden kann. REST ist übrigens nicht die einzige Möglichkeit, einen Prozess in DocBridge® Gear aufzurufen, selbstverständlich stehen auch Hotfolder und auch sogar die Kommandozeile weiterhin zur Verfügung.

Ziel von Compart ist es insgesamt, Unternehmen dabei zu unterstützen, ihre Prozesse in der Kundenkommunikation noch stärker zu automatisieren und agiler zu machen und gleichzeitig die eigenen IT-Ressourcen zu schonen. Im Zuge dieser Strategie wird Compart daher auch die automatisierte Bereitstellung bzw. Verteilung (Deployment) und Orchestrierung von Container-Anwendungen mittels Container und Kubernetes weiter forcieren, um der steigenden Nachfrage nach leicht zu integrierenden Microservices noch besser gerecht zu werden.

Fallbeispiel: Dokumentenerstellung als API-Service in einer hybriden Cloud

Mittlerweile laufen etliche Projekte der Compart zu diesem Thema – unter anderem im Rahmen der Migration auf ein neues ERP System, welches in der Microsoft Azure Cloud betrieben wird. Dabei sollte auch das bisherige, ausschließlich seitenorientierte Output Management System abgelöst werden. Der Kunde suchte daher eine Lösung, die sich sehr gut in die neue hybride-Cloud-Architektur integrieren lässt und nicht nur die analogen Medien (Druck) bedient, sondern auch die elektronischen, hier vor allem den E-Mail-Versand.

Daraufhin nahm man verschiedene Anbieter von Software für das Dokumenten- und Output-Management ins Visier und stieß dabei auch auf Compart. Man wollte bei der Wahl nicht „auf ein Pferd“, sprich, auf einen Hersteller setzen, der alle benötigten Funktionalitäten aus einer Hand in Form eines einzigen Produkts anbietet. Vielmehr verfolgte man eine Art „Best-of-Breed“-Ansatz: Man suchte granulare Microservices mit klar definierten API-Schnittstellen, die zwar jeweils immer nur einen bestimmten Prozess des Dokumenten- und Output-Management abdecken, sich dafür aber unkompliziert in die moderne, neue Infrastruktur einbinden lässt. Dadurch soll das Gesamtsystem entsprechend dem Dokumentenaufkommen bzw. der Nutzerzahlen auch beliebig skalierbar sein und mit Services anderer Anbieter im Rahmen der hybriden Cloud problemlos interagieren.

Daher entschied man sich, in der Dokumentenerstellung auf zwei Services der Compart zurückzugreifen: DocBridge® Impress Designer und DocBridge® Impress Engine, den Kernkomponenten der Lösung DocBridge® Impress.

Beide Services nutzt der Kunde zur Erzeugung von Rechnungen, Abrechnungen, Prüfdokumenten, Belegkopien etc. – kurz: alles was an Output im neuen ERP-System produziert und anschließend als E-Mail oder klassische Briefsendung (Papier) versendet wird. Die Aufgaben der beiden Services sind klar geregelt: Während mit dem DocBridge® Impress Designer die Vorlagen (Templates) für die jeweilige Dokumentenart erstellt und anschließend automatisiert in die Produktionsumgebung verteilt werden, verwendet DocBridge® Impress Engine diese Templates, um daraus letztlich die fertigen Dokumente im jeweiligen Format und für das entsprechende Medium zu erzeugen.

Ressourcenverwaltung für die Dokumentenerstellung

Geplant ist, demnächst einen weiteren API-Service von Compart für die Dokumentenerzeugung einzusetzen: DocBridge® Resource Director. Diese Komponente hat die Aufgabe, sämtliche für die Erzeugung eines Dokuments notwendigen Ressourcen (Schriftarten, Logos, Farben, Textbausteine, Bilder etc.) zentral zu verwalten und dafür zu sorgen, dass die jeweils richtigen Ressourcen den entsprechenden Dokumenten automatisch zugeordnet und Abhängigkeiten zwischen Resourcen überwacht.

Dadurch werden Fehler bzw. Regelverletzungen (z. B. Verwendung veralteter oder nicht vorhandener Logos und Fonts) in der Dokumentenerzeugung vermieden. Ebenso stellt DocBridge® Resource Director sicher, dass keine Ressourcen versehentlich gelöscht oder unvollständige Projekte in Produktion gegeben werden. Selbstverständlich gehört zum Funktionsumfang die automatische Versionierung sämtlicher Ressourcen.

Die Rolle von DocBridge® Resource Director ist nicht hoch genug einzuschätzen, wenn man bedenkt, dass man es bei der Dokumentenerstellung in der Regel mit sehr vielen Templates zu tun hat. Da kann es schnell unübersichtlich werden – insbesondere dann, wenn unterschiedliche Textbausteine in größerer Zahl oder eben auch viele Bilder und Fonts verwendet werden. DocBridge® Resource Director übernimmt daher die dokumentenabhängige Verwaltung der verschiedenen Ressourcen.

Fallbeispiel: Schadensregulierung von Reiseversicherungen als API-Service

Immer mehr ist Compart mit Projekten dieser Art konfrontiert, so auch bei einem großen deutschen Anbieter von Reiseversicherungen, der einen neuen geschäftskritischen Prozess etablieren musste. Konkret ging es hier um die Kommunikation zwischen Kunde, Call Center und der Sachbearbeitung (Schadensregulierung). Problem war, dass das dafür eingesetzte Altsystem diesbezüglich keine Hochverfügbarkeit bot. Man hätte zusätzliche Lizenzen erwerben und die bisherige Lösung aufwändig erweitern bzw. „updaten“ müssen.

Wäre es daher nicht besser und billiger, den besagten Kommunikationsprozess durch einen dezidierten API-Microservice abzudecken, der sich zudem automatisch skalieren lässt statt das komplette, stark monolithische Altsystem extra nur für diesen einen Anwendungsfall anzupassen?

Granulare, flexible und leicht zu integrierende Mikro-Applikationen wie DocBridge® Impress Engine wären dazu eine lohnende Alternative. Das Einsatzszenario könnte dann wie folgt aussehen: Der Kunde ruft beim Call Center des Reiseversicherers an und meldet einen Schaden (zum Beispiel Krankheit im Auslandsurlaub). Der Sachbearbeiter nimmt den Vorgang zunächst auf, gibt die notwendigen Daten in das System (Fachanwendung) ein und erzeugt mit DocBridge® Impress Engine ein PDF-Dokument, das elektronisch an den Versicherten geschickt wird. Dieser füllt es aus und schickt es an den Versicherer zurück. Mit anderen Worten: Das PDF-Dokument wird über den REST-Webservice DocBridge® Impress Engine aus der bestehenden Fachapplikation des Unternehmens heraus generiert und dorthin auch wieder direkt vom Kunden übergeben.

Da der Service auch Formate wie HTML5 verarbeiten kann, könnte man den PDF-Workflow auch abschaffen und stattdessen das Dokument gänzlich in HTML erzeugen – schließlich lässt sich dieses Format ohnehin viel einfacher verarbeiten als PDF, das sich stark am Seitenstandard DIN A4 orientiert, was für die Darstellung und Bearbeitung beispielsweise auf mobilen Endgeräten denkbar ungeeignet ist.

Compart erwartet im Dokumenten- und Output-Management eine steigende Nachfrage nach granularen API-Services (Packaged Business Capabilities), mit denen Unternehmen und Behörden ihre Dokumentenverarbeitung schnell und einfach um neue Prozesse erweitern und bestehende Abläufe modernisieren können im Sinne einer möglichst durchgehenden Automatisierung.

Der Einsatz solcher Services verleiht ihnen die notwendige Agilität, um vor dem Hintergrund der Digitalisierung ihre Kundenkommunikation so flexibel wie möglich zu halten (u.a. neue Kommunikationskanäle, neue Dokumentvorlagen/-formate).

Thorsten Meudt, Chief Marketing Officer bei Compart: „Wir fokussieren bewusst diese Themen und werden in den kommenden Jahren die modulare Architektur unseres Portfolios weiter ausbauen. Unser Ziel ist es, noch mehr skalierbare API-Microservices anzubieten, die sich als Container einfach verteilen und orchestrieren lassen. Kunden, die beabsichtigen, in die Cloud zu gehen oder bereits betreiben, sind bei uns gut aufgehoben.“

¹ Gartner’s Top Strategic Predictions for 2020 and Beyond: Technology Changes the Human Condition, Oktober 2019

Microservices für die Omnichannel-Dokumentenerstellung:
DocBridge® Impress

DocBridge® Impress ist eine skalierbare, plattformunabhängige Software für das seiten- und geräteunabhängige Design von Dokumenten, die sich auch von Anwendern ohne profundes IT-Know-how einfach bedienen lässt. Sie kann sowohl als on-premise-Lösung als auch in Cloud-Umgebungen (privat, öffentlich und hybrid) betrieben werden. Dazu bietet sie die Möglichkeit, bestimmte Funktionalitäten als Microservices herauszulösen und diese über webbasierte API (z. B. REST) in vorhandene IT-Strukturen, also auch in eine Cloud, schnell und nahtlos einzubinden.

Die mit DocBridge® Impress erstellten Dokumente sind omnichannel-fähig und barrierefrei gemäß PDF/UA und WCAG. Mit der Composition-Lösung lassen sich Dokumente erstellen und auf allen relevanten Kanälen versenden und auf unterschiedlichen Medien anzeigen: als gedruckte Seiten, als PDF im E-Mail-Anhang, als responsive HTML Seite im Webbrowser und auf dem Smartphone/Tablet, über Messenger-Dienste etc. Jedes neue Dokument braucht nur einmal erstellt zu werden und steht ohne größeren Aufwand für alle Medien zur Verfügung. Zudem ist es automatisch barrierefrei gemäß dem weltweit anerkannten Standard PDF/UA.

DocBridge® Impress bedeutet einen Paradigmenwechsel im Dokumentendesign: Die Erstellung erfolgt unabhängig von einer vorgegebenen Seitengröße und basiert auf offenen Standards wie HTML5 (erweitert um druckrelevante Funktionen). Außerdem gibt es die Möglichkeit, Regeln der Business- und Sprachlogik zu hinterlegen sowie verschiedene Funktionen für die integrierte Verwaltung von Vorlagen (Templates), Bildern, Textbausteinen und anderen Ressourcen für konsistente Dokumente.

Die Architektur von DocBridge® Impress basiert auf der konsequenten Trennung zwischen einem web-basierten Editor (Impress Designer) und der eigentlichen Composition Engine (Impress Engine). Somit lassen sich je nach Einsatzszenario beide Komponenten gemeinsam nutzen, aber auch einzeln als Microservices, die direkt an bestehende Applikationen über Webservices angebunden werden können.

Architektur

DocBridge® Impress Designer

Mit diesem Tool entwirft der Anwender (z. B. Textadministrator) über eine intuitiv zu bedienende Oberfläche sein Dokument (Template) und ergänzt es bei Bedarf um Angaben zum Layout für die digitalen Kanäle bzw. für den Druck.
Er kann dort Regeln der Geschäftslogik hinterlegen und bestimmen, ob das Dokument allgemein zugänglich (Barrierefreiheit gemäß WCAG-Standard PDF/UA) sein und in welchen Sprachen es zur Verfügung stehen soll.

Außerdem möglich:

  • Einfügen von Barcodes und Steuerungszeichen (OCR, OMR, DV-Freimachung)
  • Vorschau des Dokuments für alle denkbaren Ausgabekanäle
  • Konvertierung in die gewünschten Zielformate - jedes von Compart unterstützte Format ist möglich (HTML, PDF inklusive Spezifika, ZUGFeRD, AFP, PCL, PostScript etc.)
DocBridge® Impress Engine

Sie ist das „Herz“ von DocBridge® Impress und führt die im DocBridge® Impress Designer erstellten oder bereits anderweitig vorliegenden Templates mit den variablen Daten ("Rohdaten") aus Geschäftsanwendungen zusammen und erstellt unter Anwendung der definierten Regeln und der bereitgestellten Ressourcen (Bilder, Textbausteine, etc.) die fertigen Dokumente.

Microservices für den digitalen Posteingang:
DocBridge® Conversion Hub

Die hochleistungsfähige, skalierbare und nahtlos zu integrierende Plattform DocBridge® Conversion Hub geht hinsichtlich Umfang und Intention über das Angebot herkömmlicher Software zur Dokumentenkonvertierung hinaus. Der wohl wichtigste Vorzug der von Compart entwickelten Lösung ist die nahezu unbegrenzte Formatvielfalt: Es gibt praktisch keinen Dokumententyp, der nicht von DocBridge® Conversion Hub verarbeitet werden kann.

Selbst Nachrichten aus Messenger-Diensten, Bilder in diversen Formaten, E-Mails nebst Anhänge und Inhalte in sehr proprietären bzw. veraltete Formate lassen sich mit der Lösung verarbeiten. DocBridge® Conversion Hub fungiert quasi als „Trichter“, der jedes empfangene elektronische Dokument, unabhängig von seinem Format, entgegennimmt, erkennt, aufbereitet, also in ein les- und analysierbares Format wandelt, gleichzeitig die relevanten Daten extrahiert und damit die Voraussetzungen für dessen automatisierte Weiterverarbeitung, unter anderem auf KI-basierenden Prozessen, legt.

Kernstück der Plattform ist eine Art "Dispatcher", der jede ankommende Nachricht (E-Mail, Fax, SMS, Messenger-Dienst, Brief/Papier) analysiert und automatisch über die für das jeweilige Dokument optimale Konvertierungsstrecke (In welches Format soll konvertiert werden? Wie hat die Weiterverarbeitung zu erfolgen?) entscheidet.

DocBridge® Conversion Hub enthält außerdem eine OCR-Funktion für das Extrahieren von Inhalten und Metadaten (Optical Character Recognition) und bietet die Möglichkeit zur frei konfigurierbaren Integration von Drittanwendungen. Über die Lösung DocBridge® Gear lässt sich DocBridge® Conversion Hub zudem in komplexe Prozesse der Dokumentenverarbeitung integrieren, beispielsweise auf der Basis von KI- und Robotics-Technologien.

Dank der granularen Architektur lassen sich die einzelnen Funktionen von DocBridge® Conversion Hub auch als einzelne API-Services beziehen und mit bereits bestehenden Applikationen innerhalb von Cloud-Umgebungen verbinden bzw. betreiben.

Microservices für die Anzeige und Bearbeitung von Dokumenten jedes Formats:
DocBridge® Document Viewer

DocBridge® Document Viewer richtet sich in erster Linie an Unternehmen, die für einen hohen oder sich häufig ändernden Durchsatz an unterschiedlichen Dokumenten eine Multi-Format-View-Lösung suchen, die sie direkt in bestehende Applikationen und Arbeitsabläufe unkompliziert einbinden können. Die Anwendung lässt sich je nach vorhandenem Dokumentenaufkommen und Zahl der Nutzer beliebig skalieren.

Dabei handelt es sich um eine webbasierte Software zum Anzeigen von digitalen Dokumenten jedes Formats und Umfangs. Mit der cloud-fähigen Anwendung lassen sich Dokumente beliebigen Umfangs anzeigen und in ihrer Darstellung beeinflussen (z. B. Drehen, Zoomen, gleichzeitiges Öffnen mehrerer Dokumente). Daneben werden Metadaten (etwa aus AFP) oder Daten der Drucksteuerung (z.B. Schächte, Duplex) angezeigt. Es gibt keinerlei Beschränkungen hinsichtlich der Dateigröße (Anzahl der Seiten) und der Nutzerzahl.

Testversion:
Unter dem folgenden Link steht eine kostenlose Testversion des Online-Dokumentenviewers zur Verfügung.

DocBridge® Document Viewer braucht nur einmal auf einem zentralen Unternehmensserver installiert zu werden, die Nutzer greifen direkt vom Arbeitsplatz über einen Browser auf die hochleistungsfähige Applikation zu. Die aufwändige und kostenintensive Pflege einer Desktop-Anwendung entfällt dadurch und vertrauliche Dateien müssen von den Mitarbeitern zum Betrachten nicht erst auf ihren lokalen Rechner kopiert oder heruntergeladen werden.

Ein besonderes Merkmal von DocBridge® Document Viewer ist die Architektur: Die Compart-Lösung verfügt über ein umfangreiches JavaScript-API, das die einfache Einbindung in bestehende Web-Anwendungen ermöglicht und sich daher in existierende IT-Infrastrukturen schnell und problemlos integrieren lässt.

Gerade diese hohe Integrationsfähigkeit in alle denkbaren Systeme ist ein wesentlicher Vorzug der Software. Dadurch kann sich beispielsweise der Sachbearbeiter einer Versicherung oder eines Handelsregisters sämtliche Dokumente direkt am Bildschirm anschauen und sie bearbeiten – unabhängig davon, in welchem Format das Dokument vorliegt, mit welcher Fachanwendung der Nutzer arbeitet und ohne die Installation einer Software oder eines Browser-Plugin.

Auch für Unternehmen, die Dokumente vermehrt über Webportale empfangen bzw. ihren Kunden zur Verfügung stellen, ist DocBridge® Document Viewer auf Grund der Architektur, Performance und des breiten Spektrums an Dateiformaten eine lohnende Alternative zu herkömmlichen Viewer-Angeboten.

Zu den Vorzügen der Compart Lösung gehört außerdem die einfache Administration bzw. Wartung: Sämtliche Änderungen und funktionalen Erweiterungen (zum Beispiel im Zuge von Release-Wechseln) werden einmalig eingespielt und stehen nach der Implementierung automatisch allen Nutzern zur Verfügung. Es müssen also keine Updates an den einzelnen Arbeitsplätzen (Clients) vorgenommen werden.

Plattform für automatisierte Prozesse im Output- und Dokumenten-Management:
DocBridge® Gear

In der von Compart entwickelten Software DocBridge® Gear spiegelt sich das Prinzip der API-Economy im Umfeld der Kundenkommunikation wider: die problemlose Interaktion zwischen beliebigen Anwendungen, Systemen und Diensten auf der Basis standardisierter, offener Programmierschnittstellen mit der Chance zur Erweiterung bestehender bzw. Entwicklung neuer Geschäftsprozesse.

DocBridge® Gear ist eine Anwendung, mit der sich sämtliche Abläufe der Dokumentenerstellung, -konvertierung, -modifizierung und –ausgabe kundenspezifisch und einfach konfigurieren lassen auf der Basis von Rohdaten.

Auch typische Abläufe der Qualitätssicherung (Dokumentenprüfung und –vergleich, Validierung, Freigabeworkflows etc.) lassen sich damit modellieren. Grundprinzip von DocBridge® Gear ist der Gebrauch von wiederverwendbaren API-Services (Worklets), die für ganz bestimmte Funktionalitäten und Teilprozesse stehen. Diese Worklets können sehr granular (kleine, überschaubare Abläufe), aber auch sehr groß (mehrfach verschachtelte Prozesse/Berücksichtigung verschiedener komplexer Kriterien) sein.

DocBridge® Gear gilt als das Kernstück der Cloud- und SaaS-Strategie von Compart und bietet vielfältige Möglichkeiten zur Modellierung von separat einsetzbaren Microservices.

Microservices für Office-Dokumente:
DocBridge® FileCab

DocBridge® FileCab ist eine Software für das Sammeln, Prüfen und Übergeben von Office-Dokumenten an die zentrale Dokumentenverarbeitung eines Unternehmens. Anwender in der Fachabteilung können damit ihre am Arbeitsplatz (PC, Laptop) erstellte Korrespondenz gegen verschiedene, vom Unternehmen definierte Kriterien und Regelwerke prüfen, bevor sie diese an das zentrale Output-Management weiterleiten. Die Prüfung erfolgt direkt nach der Erstellung in der Office-Anwendung. Dadurch erhöht sich die Prozessqualität erheblich.

Optional kann das zentrale Einsammeln der Individualkorrespondenz mit einem Freigabe-Workflow kombiniert werden, der über das Zusatzmodul DocBridge® Document Desktop, eine Webanwendung, ermöglicht wird. Dadurch lässt sich die formelle, regelbasierte Prüfung von DocBridge® FileCab um eine visuelle, inhaltliche Qualitätssicherung ergänzen.

Interessant an diesem Produkt sind vor allem zwei Komponenten:

  • DocBridge® Document Desktop: eine Webanwendung für die Validierung und Freigabe von Dokumenten als Ergänzung für eine visuelle, inhaltliche Qualitätssicherung.
  • DocBridge® Document Collector: eine zentrale Servereinheit, welche die gesamte Individualkorrespondenz aller angeschlossenen FileCab-Clients einsammelt. Sie selektiert die zur Prüfung anstehenden Dokumente für den Freigabe-Workflow und übergibt die freigegebenen Vorgänge zu definierten Zeitpunkten an die angeschlossene zentrale analoge (Druck) und digitale Verarbeitung.

Beide Komponenten lassen sich auch als separate Microservices auf der Basis von API verwenden.

Glossar

Container

Transportcontainer in der Logistik ermöglichen es, Waren jeglicher Art in einer standardisierten “Verpackung” flexibel und schnell mit unterschiedlichen Verkehrsmitteln zu verschicken und zu verteilen – ob per Schiff, Flugzeug, Bahn oder LKW. Ähnlich operieren Container in der IT: Sie verpacken eine Anwendung und alle zu ihrer Ausführung erforderlichen Dateien in ein handliches Paket.

Das vereinfacht sowohl die Installation und den Betrieb von Server-Anwendungen als auch deren Management und Verteilung. Somit erleichtern Container den Umgang mit komplexen Server-Anwendungen und ermöglichen eine weitgehende Automatisierung von Rollout-Prozessen im Rechenzentrum. Das ist besonders bei der Bereitstellung von skalierbaren, verteilten Anwendungen innerhalb von Cloud-Umgebungen wichtig.

Eine wesentliche Problematik beim Rollout von neuen Anwendungen oder neuen Releases ist es, dass jede Anwendung von gewissen Elementen ihrer Umgebung abhängt. Hierzu zählen beispielsweise lokale Einstellungen oder Funktionsbibliotheken. Oft unterscheiden sich die Einstellungen in der Entwicklungsumgebung von denen der Testumgebung und der Produktion. Dann kann es schnell passieren, dass eine Anwendung in der Produktion wider Erwarten anders oder gar nicht funktioniert.

Weitere Faktoren, die einen reibungsloses Rollout stören können, sind das der Anwendung zu Grunde liegende Betriebssystem, dessen Version und Einstellungen, alle hinzugefügten Pakete und Module oder die Konfiguration des Netzwerks. Die Bereitstellung mehrerer Anwendungen über unterschiedliche Plattformen ist also eine Herausforderung. Hier bietet der Einsatz von Containern unmittelbare Vorteile: Entwickler verpacken so ihre Anwendungen inklusive aller Abhängigkeiten wie Bibliotheken und Konfigurationsdateien in einem Container. Die Anwendungen werden also nicht mehr direkt auf den Zielsystemen installiert. Die Container stellen somit die komplette Laufzeitumgebung der Applikation in einem Paket bereit.

So haben Entwickler die Möglichkeit, Anwendungen zwischen verschiedenen Umgebungen hin- und herzuschieben – zum Beispiel für Tests in einem spezifischen Hardware-Umfeld und den Betrieb in einem anderen. Oder sie betreiben Applikationen erst auf einer physikalischen Maschine und dann in einer Private, Public oder Hybrid Cloud.

Container machen Anwendungen unabhängiger von der Umgebung, in der sie ausgeführt werden. Sie agieren damit ähnlich einer virtuellen Maschine (VM). Während eine VM jedoch ein vollständiges Betriebssystem sowie Applikationen enthält, teilen sich mehrere Container einen Betriebssystemkern. Jede Anwendung erhält lediglich einen neuen User Space und damit eine komplett isolierte Umgebung. Container verbrauchen also im Vergleich zu VMs deutlich weniger Ressourcen wie Rechenleistung, Hauptspeicher etc. Und es dreht sich hier um Megabytes bei Containern im Vergleich zu Gigabytes bei VMs. Daher passen auf einen Server sehr viel mehr Container als virtuelle Maschinen. Zudem sind Container schneller einsatzbereit: Während VMs manchmal mehrere Minuten zum Start benötigen, stehen Anwendungen hier beinahe sofort zur Verfügung.

Container ergänzen die Virtualisierung
Trotzdem werden Virtualisierungs-Lösungen weder überflüssig noch komplett ersetzt werden, da sie nicht für alle Anwendungsszenarien passen. So eignen sich Container zum Beispiel sehr gut für Infrastrukturen, in denen eine große Zahl von Applikationsinstanzen parallel laufen. Sie sind zudem ideal für Anwendungen, welche häufigen Updates und funktionalen Erweiterungen unterliegen. Bei Applikationen, die aus unterschiedlichen Komponenten bestehen und auf einer Microservices-Architektur basieren, bieten Container ebenfalls eine effiziente Möglichkeit, neue Rollouts ohne großen Overhead zu implementieren.

Für andere Anwendungsfelder hingegen ist die Virtualisierung mit Hypervisoren nach wie vor die bessere Wahl: Beispielsweise für die Bereitstellung und den Betrieb von Standard-Serverdiensten wie Datenbankservern, Directory Servern oder auch Webservern – also im Prinzip für standardisierte Anwendungen, die längeren Aktualisierungszyklen unterliegen und von Dritten bereitgestellt werden. Somit sind Container eher eine sinnvolle Ergänzung zur Virtualisierung als ein Ersatz.

Docker

Docker ist eine Open-Source-Software zur Isolierung von Applikationen in Containern (Virtualisierung). Docker vereinfacht die Bereitstellung von Anwendungen, weil sich Container, die alle nötigen Pakete enthalten, leicht als Dateien transportieren und installieren lassen. Container gewährleisten die Trennung und Verwaltung der auf einem Rechner genutzten Ressourcen. Das beinhaltet laut Aussage der Entwickler: Code, Laufzeitmodul, Systemwerkzeuge und –bibliotheken – alles, was auf einem Rechner installiert werden kann.

Docker basiert auf Linux-Techniken wie Cgroups und Namespaces, um Container zu realisieren. Während anfänglich noch die LXC-Schnittstelle des Linux-Kernels verwendet wurde, haben die Docker-Entwickler mittlerweile eine eigene Programmierschnittstelle namens libcontainer entwickelt, die auch anderen Projekten zur Verfügung steht. Als Speicher-Backend verwendet Docker das Overlay-Dateisystem AuFS, ab Version 0.8 unterstützt die Software aber auch btrfs.

Prinzipiell ist Docker auf die Virtualisierung mit Linux ausgerichtet. Docker kann allerdings auch mittels Hyper-V (Standard) oder VirtualBox auf Windows und mittels VirtualBox auf macOS verwendet werden. Da die Ressourcentrennung alleine mit den Docker-Techniken nicht völlig sicher ist, hat die Firma Red Hat Unterstützung für die sicherheitsrelevante Kernel-Erweiterung SELinux implementiert, welche die Container auf der Ebene des Host-Systems zusätzlich absichert.

Veröffentlicht wurde die Software Docker vom Unternehmen dotCloud im März 2013. dotCloud nannte sich im Oktober 2013 in Docker um; dotCloud selbst wurde zu einem Platform-as-a-Service, der im August 2014 an das Berliner IT-Unternehmen cloudControl verkauft wurde.

Im Jahr 2014 wurde die Open-Source-Software zunehmend bekannter und populärer. Inzwischen ist Docker ein fester Bestandteil der Linux-Distribution von Red Hat. Auch im Lieferumfang der Linux-Distribution openSUSE ist die Software enthalten. Im Sommer 2014 schlossen sich die Firmen Docker, Microsoft, IBM, Red Hat, CoreOS, Saltstack und Mesosphere dem Kubernetes-Projekt an. Dieses Projekt wurde von Google angestoßen und hat zum Ziel, Container auf allen öffentlichen, privaten und hybriden Cloud-Umgebungen bereitzustellen.

Kubernetes

Kubernetes ist ein Open-Source-System zur automatisierten Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen, das ursprünglich von Google entworfen und an die Cloud Native Computing Foundation (CNFC) gespendet wurde. Es zielt darauf ab, eine „Plattform für das automatisierte Bespielen, Skalieren und Warten von Anwendungscontainern auf verteilten Hosts“ zu liefern. Die Orchestrierung mittels Kubernetes wird von führenden Cloud-Plattformen wie Microsoft Azure, Amazon AWS, Oracle OCI, OpenShift unterstützt.

Kubernetes wurde von Joe Beda, Brendan Burns und Craig McLuckie gegründet. Kurze Zeit später stießen weitere Google-Entwickler wie Brian Grant und Tim Hockin hinzu. 2014 wurde Kubernetes von Google angekündigt.

Das Akronym CRUD umfasst die vier grundlegenden Operationen persistenter Speicher

  • Create, Datensatz anlegen,
  • Read oder Retrieve, Datensatz lesen,
  • Update, Datensatz aktualisieren, und
  • Delete oder Destroy, Datensatz löschen.

Zum Verständnis: CRUD bezeicnet die grundlegenden Vorgänge, die in einem Daten-Repository ausgeführt werden müssen. Sie bearbeiten Datensätze oder Datenobjekte direkt. Abgesehen von diesen Vorgängen sind die Datensätze passive Einheiten. Normalerweise handelt es sich nur um Datenbanktabellen und Datensätze.

REST hingegen verarbeitet Ressourcendarstellungen, die jeweils durch eine URL gekennzeichnet sind. Dies sind normalerweise keine Datenobjekte, sondern komplexe Objektabstraktionen.

Eine Ressource kann beispielsweise ein Benutzerkommentar sein. Das bedeutet nicht nur einen Datensatz in einer 'Kommentar'-Tabelle, sondern auch die Beziehung zu der' Benutzer'-Ressource, dem Beitrag, an den der Kommentar angehängt ist, oder zu einem anderen Kommentar, auf den er reagiert.

Das Bearbeiten des Kommentars ist keine primitive Datenbankoperation, sondern kann erhebliche Nebenwirkungen haben, z. B. das Auslösen einer Warnung für das ursprüngliche Poster oder das Neuberechnen einiger spielähnlicher "Punkte" oder das Aktualisieren einiger "Follower-Streams".

Außerdem enthält eine Ressourcendarstellung Hypertext (überprüfen Sie das HATEOAS- Prinzip), sodass der Designer Beziehungen zwischen Ressourcen ausdrücken oder den REST-Client im Workflow einer Operation steuern kann.
Kurz gesagt, CRUD ist eine Menge primitiver Operationen (hauptsächlich für Datenbanken und statische Datenspeicher), während REST ein API-Stil auf sehr hoher Ebene ist (hauptsächlich für Webdienste und andere "Live" -Systeme).