Content Integration - Teil 2

• Home
• Magazin
• Know How
• Content Management

Bis auf die Systeme von SAP und ADP (Paisy) gibt es auf dem Markt für betriebswirtschaftliche Systeme kein Produktangebot mit einer veröffentlichten, zertifizierbaren "Standard"-Schnittstelle zu einem Enterprise Content Management System. Auch "Standard"-Integrationen von ECM-Herstellern in marktgängige Fachanwendungen sind mit Schwächen verbunden. Projektarbeit tut Not – doch welchen technologischen Ansatz, welche Gesamtarchitektur sollte man wählen und wie kann ein ECM-System auf seine Integrationsmöglichkeit bewertet werden? Im zweiten Teil des Artikels "Content Integration" werden diese Fragen beantwortet.

Nachdem im ersten Teil des Artikels die Integrationsmöglichkeiten auf Client-Ebene geklärt wurden, geht es nun weiter mit den Server-basierten Schnittstellen, die vor allem für den Abgleich von Massendaten benötigt werden. So zum Beispiel für die Rückmeldung von Dokumentennummern eines umfangreichen COLD-Jobs vom ECM an die Host-Datenbank.

Hierbei haben sich ganz unterschiedliche Konzepte etabliert, vom einfachen Datei-Austausch mit anschließender Batch-Verarbeitung über die Nutzung von Message Queueing-Systemen bis zur direkten Anbindung des ECM an die Datenbank der führenden Anwendung via SQL.

Einfacher Dateiaustausch für schnelle Verarbeitung

Der einfache Dateiaustausch ist übrigens die gängige Methode im Rahmen der COLD-Archivierung: ECM-Lösungen erwarten hier typischerweise das lokale Vorliegen einer Importdatei, die die zu archivierenden Dokumente enthält. Wie die Datei vom führenden Anwendungssystem oder vom Drucksystem auf das ECM gelangt, liegt außerhalb der Kontrolle der COLD-Lösung; ebenfalls die Rückmeldung an das abgebende System über Erfolg oder Misserfolg der Archivierung.

Somit benötigen selbst "Standard" COLD-Lösungen häufig projekt-individuelle Integrationen, um z.B. die Richtigkeit und Vollständigkeit der Archivierung zu protokollieren oder um die im Archiv erzeugten Dokumenten-Kennungen der führenden Anwendung zur Verfügung zu stellen.

Die Vorteile der Integration via Dateiaustausch liegen jedoch in der einfachen Einrichtung, die keine komplexe Infrastruktur voraussetzt. Im Projekt muss lediglich eine Konvention über Gestalt und Inhalt der Austauschdatei(en) abgestimmt werden. Zusätzlich kann auf etablierte Verfahren und Übertragungsprotokolle, wie zum Beispiel FTP, zurückgegriffen werden. Letztlich ist die Verarbeitungsgeschwindigkeit sequentieller Dateien typischerweise besonders hoch, da im Laufe der Verarbeitung keine Synchronisation mit "fremden" Datenbeständen erfolgen muss. Es kommen somit alle Vorteile einer klassischen Batch-Verarbeitung zum Tragen.

Unmittelbarer Datenbank-Zugriff via SQL

Daneben kann – soweit die ECM-Umgebung eine entsprechende Server-API bereitstellt, was nur selten der Fall ist – eine direkte Datenbank-Anbindung des ECM z.B. über SQL erfolgen. Hierbei würde das ECM die erzeugten Dokumentennummern unmittelbar in der Datenbank der führenden Anwendung eintragen.

Die Probleme dieses Ansatzes liegen vor allem in der projektseitig zu regelnden Synchronisierung, der Transaktionsabgrenzung und letztlich der relativ geringen Verarbeitungsgeschwindigkeit, die sich als Folge der vorgenannten Probleme einstellt. Zusätzlich muss projektseitig eine Datenpufferung implementiert werden, die die Vollständigkeit und Korrektheit der Datenübertragung selbst bei Verbindungsausfällen sicherstellt.

Message-Queueing für hohe Verarbeitungssicherheit

Um z.B. die Rückführung massenhafter Archiv-Dokumentenkennungen eines COLD-Jobs an die führende Anwendung über ein Verfahren zu etablieren, das selbständig die Vollständigkeit und Richtigkeit der Übertragung regelt, integrieren einige ECM-Anwender Message Queueing-Systeme, vornehmlich IBMs MQ-Series. Der Vorteil liegt vor allem in der automatischen Synchronisierung, die auch die zeitweise Nicht-Verfügbarkeit eines der beteiligten Systeme automatisch und korrekt behandelt. Aus Sicht der Datensicherheit und Handhabbarkeit stellt dieser Lösungsansatz sicherlich das Optimum dar.

Wer allerdings ausschließlich zwischen ECM und führender Anwendung diesen hohen Datenaustausch bewerkstelligen muss, wird nicht alleine hierfür extra ein Message Queueing-System anschaffen, sondern zumeist mit den oben dargestellten "Schwächen" des einfachen Dateiaustauschs leben.

Die bisherigen Ausführungen haben gezeigt, dass in einer komplexen ECM-Umgebung nicht eine, sondern gleich mehrere Integrationen zum Einsatz kommen können. Dies erfordert die Erstellung und Pflege ganz unterschiedlicher Lösungskonzepte, so dass von einer einheitlichen ECM-Schnittstelle nicht die Rede sein kann, auch wenn die ausgetauschten Daten in einem gemeinsamen Kontext einer einheitlichen Gesamtlösung verwendet werden.

Middleware-Ansatz noch längst nicht überall vorhanden

Da generell die Integration von Systemen in immer komplexeren Umgebungen zur ständigen Herausforderung wird, haben sich zwischenzeitlich mit Applikations-Servern (J2EE) und EAI Produkte und Technologien zur System- und Anwendungsintegration auf dem Markt etabliert.

Immer mehr Rechenzentren verwenden diese "Hub-and-Spoke" Middleware-Lösungsansätze zur Integration ihrer komplexen Anwendungsumgebungen und kehren damit ab vom klassischen Ansatz der Point-to-Point Integration, die immer eine individuelle Integration zwischen exakt zwei Systemen darstellte. "Hub-and-Spoke" ermöglicht die Anbindung gleich mehrerer Systeme an einen einzigen Hub – über Adapter sind diese mit dem Hub verbunden, der die Kommunikation zwischen den Beteiligten regelt.

Abbildung 1: Point-to-Point vs. Hub-and-Spoke

Allerdings sind viele Hersteller von ECM-Produkten diesem Trend noch längst nicht in vollem Umfang gefolgt und stellen Middleware-Adapter zu Ihren Systemen entweder noch gar nicht, funktional unvollständig oder lediglich auf exotischen Plattformen bereit. Bei der Auswahl einer geeigneten ECM-Lösung reicht somit nicht die einfache Frage: "Unterstützt das Produkt Java?" aus – es ist ebenso die Funktionstiefe der API und die Ablauffähigkeit auf dem bevorzugten Application Server sicherzustellen.

Dabei erhöht die Verwendung von Middleware-Umgebungen die Flexibilität bei der Metadaten-Integration des ECM in führende Anwendungsumgebungen. Für die unterschiedlichen Dokumenten-Erfassungsanwendungen – von der zentralen Scan-Station über die Batch-gesteuerte Druckdatenverarbeitung (COLD) und die Archivierung via Exchange Server-Schnittstelle bis zur Archivierung unmittelbar aus dem Client heraus – kann dann im Idealfall eine einheitliche Datenübertragungsschnittstelle auf Basis der Middleware implementiert werden.