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 letzten Newsletter 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 Produkten 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.

Redundanzfreie Integration
Neben der Wahl der „richtigen“ Integrationstechnologie stellt sich in jedem ECM-Projekt die Frage, wie viel ECM-Information die führende Anwendung verwalten soll: Denkbar ist, dass alle fachlichen Dokumenten-Metadaten, wie Lieferschein-Nummer, Versicherungsschein-Nummer etc. in der führenden Anwendung hinterlegt sind.

Aus anwendungstechnischer Sicht handelt es sich dann um eine saubere, redundanzfreie Integration. Dies erfordert in der Regel eine massive Erweiterung des Datenbank-Modells der führenden Anwendung, um die Zuordnung von Dokumenten zu unterschiedlichen Datensätzen, wie dem Kunden-Stammsatz, dem Schadendatensatz und dem Kündigungseintrag zu ermöglichen.

Das ECM wird hierbei auf reine Ablage- und Bereitstellungsfunktionen reduziert und kennt keinen fachlichen Bezug der Dokumente, lediglich technische Kennzeichen wie Dokumentenformat, Seiten- und Komponentenzahl (wie Anmerkungen etc.). Steht die führende Anwendung nicht zur Verfügung, gibt es auch keinen Dokumentenzugriff.

Der Zugriffsschutz ist in der führenden Anwendung hinterlegt und kann beliebig komplex gestaltet werden – in einer entkoppelten ECM-Lösung gestaltet sich hingegen gerade die Synchronisierung komplexer Zugriffsbeschränkungen schwierig.

Diese vollständige Integration in die führende Anwendungsumgebung hat in der Regel sehr hohe Einrichtungsaufwände zur Folge: Jedes Objekt, das im ECM gespeichert wird, muss in der führenden Anwendung bekannt gemacht werden, unabhängig davon, über welchen Weg es in das ECM gelangt ist. Übrigens entspricht dieser Ansatz der von SAP bereitgestellten Content Server Standard-Schnittstelle – dort fällt auf Kundenseite jedoch der geschilderte, hohe Integrationsaufwand nicht mehr an, da alle Abgleichmechanismen zwischen ECM und SAP bereits innerhalb der gelieferten Schnittstellen abgehandelt sind.

Autarke ECM-Umgebung – Freiheit kostet Redundanz
In vielen Projekten erhält das ECM jedoch ein Eigenleben: Um eine fachliche Recherche zum Beispiel mittels Kundennummer oder Buchungsnummer unmittelbar über die ECM-Infrastruktur zu ermöglichen, werden hierbei die notwendigen Recherchekriterien im ECM selbst gespeichert.

Hierdurch erhält das ECM Eigenständigkeit und muss nun diese fachlichen Daten möglichst effizient verwalten. Leider sind viele Content Management Systeme nur mit einem eingeschränkten Datenbankmodell ausgestattet, selbst wenn für die Abbildung der Datenbank ein leistungsfähiges Datenbanksystem wie Oracle, DB/2 oder MS SQL-Server zur Verfügung steht.

Vielfach verlangt das ECM-Datenmodell, dass alle fachlichen Recherchekriterien nicht normalisiert und damit innerhalb des ECM redundant hinterlegt werden: Der Kundenname beispielsweise muss bei jedem kundenbezogenen Dokument gespeichert werden, möchte der Anwender über den Namen nach den zugeordneten Dokumenten recherchieren können. Ändert der Kunde seinen Namen, müssen alle alten Dokumente mit dem neuen Namen versorgt werden oder der Datenbestand im ECM weist einen anderen Namen auf als der Datenbestand in der führenden Fachanwendung (was aus historischer Sicht wiederum korrekt sein kann).

Das ECM kann in dieser Umgebung genutzt werden, auch wenn die führende Fachanwendung nicht zur Verfügung steht. Dies ist von Vorteil, wenn diese Fachanwendung aus technischen Gründen häufiger nicht zur Verfügung steht, die Mitarbeiter (zum Beispiel im Call-Center) dennoch ständig – zumindest beschränkt – zur Auskunft bereit sein müssen. Sporadische Nutzer brauchen überdies nicht in die führende Anwendung eingewiesen zu werden, um nach fachlichen Dokumenten zu recherchieren.

Wer mit den geschilderten Problemen der redundanten Datenhaltung leben kann, für den ist dieser Integrationsansatz immer dann interessant, wenn zusätzlich das Projektbudget eng begrenzt ist: Der Integrationsaufwand einer entkoppelten ECM-Lösung ist grundsätzlich eher gering – allerdings muss streng darauf geachtet werden, dass die auf der Basis des ECM entwickelte Lösung auf ihre Kernfunktionen beschränkt wird! Gerne wird seitens der Anwender versucht, Anwendungsfunktionen, die in der Fachanwendung fehlen, auf der Seite des ECM abbilden zu lassen, was unnötig hohe Entwicklungsaufwände zur Folge hat.

Doppelt gemoppelt hält besser
Wer ganz auf Nummer sicher gehen will und gleichzeitig eine hoch integrierte Lösung bevorzugt, der hält die fachlichen Dokumentendaten sowohl in der führenden Anwendungsumgebung als auch im ECM: Für den Notfall und für Anwender ohne Zugriffsmöglichkeit auf die führende Anwendung stehen dann die Dokumente dennoch zur Verfügung.

Die Integrationsaufwände dieses Lösungsansatzes sind nur geringfügig höher als in der reinen Datenhaltung innerhalb der führenden Fachanwendung. Eine Reihe von SAP-Kunden verwenden zum Beispiel Produkt-Erweiterungen von ECM-Herstellern, die per „Index-Extraktion“ fachliche Recherchekriterien aus SAP in das ECM übertragen und dort dem Content zusteuern.

Solche Lösungen sind selbst auf Projektbasis mit relativ geringem Aufwand umsetzbar. Allerdings ist hierbei zu beachten, dass ein ECM selten in der Lage ist, einen komplexen Zugriffsschutz, ggf. rollenbasiert und für einzelne Dokumente unterschiedlich ausgeprägt, im Systemstandard zu implementieren. Ist der in der führenden Anwendung fachlich verwaltete Dokumentenbestand inhaltlich kritisch und schutzwürdig, so steht die doppelte Indexverwaltung – in der Fachanwendung und im ECM – nur mit entsprechend hohem Aufwand in der Einrichtung eines Zugriffsschutzmodells innerhalb des ECM zur Verfügung.

Kein Industrie-Standard in Sicht – was nun?
Abgesehen von den erwähnten Hersteller-Standards von SAP und ADP sind keine weiteren Standards erkennbar, die eine ähnliche Funktionstiefe enthalten.

Kunden, die das ECM als integrierten Bestandteil ihrer führenden Fachanwendung verwenden möchten sind gut beraten, die Nutzbarkeit der von SAP definierten Schnittstelle genau zu untersuchen: Einige Anwender haben die SAP-spezifischen ECM-Funktionsaufrufe in ihre führenden Anwendungen implementiert und können über diese Schnittstelle einheitlich auf jedes von SAP zertifierte Ablagesystem zugreifen.

Bei der Wahl der „richtigen“ Integration spielen das Projekt-Budget und die strategische Einbettung des ECM in die betrieblichen Abläufe eine wesentliche Rolle. Tiefe Integrationen dienen keinem architektonischem Selbstzweck, sondern sollen helfen, die fallbezogenen Bearbeitungskosten zu reduzieren. Der ROI jeder Integration liegt typischerweise um so höher, je mehr Anwender das System nutzen, je mehr Dokumente im System gespeichert werden und je mehr Dokumentenzugriffe stattfinden.

Die Frage der „richtigen“ Integrationstechnologie ist ebenfalls von den strategischen Richtlinien des Unternehmens deutlich beeinflusst. Unternehmen mit einer klaren Middleware-Ausrichtung werden versuchen, diesen Integrationsansatz auch im ECM-Projekt umzusetzen, müssen hierbei jedoch eine dedizierte Produktauswahl durchführen, da viele ECM-Hersteller Middleware-Konzepte noch nicht oder unzulänglich unterstützen.

Sobald der Middleware-Ansatz nicht realisiert werden kann, müssen plattformspezifische Client- und Server-Integrationstechniken eingesetzt werden – vornehmlich ausgerichtet an den IT-strategischen Vorgaben, der vorhandenen IT-Infrastruktur, dem vorhandenen Know-how, den vom ECM bereitgestellten Möglichkeiten und dem Projekt-Budget.

Bereits bei der Produktauswahl sollten Anwender daher kritisch Plattformen und Funktionstiefe der vom ECM-Hersteller bereitgestellten API untersuchen. Wenn die Integrationsanforderungen bereits im Vorfeld exakt untersucht und spezifiziert wurden, können vom Integrator konkrete Lösungsansätze und bindende Aufwandschätzungen eingefordert werden. Die nachfolgende Checkliste zur Bewertung der Integrationsmöglichkeit eines ECM-Systems ist dabei sehr hilfreich:

Checkliste zur Bewertung der Integrationsmöglichkeit eines ECM-Systems:

• Besitzt das ECM eine standardisierte und zertifizierte Schnittstelle zu dem führenden Anwendungssystem (nur SAP und ADP Paisy)?
• Besitzt der ECM-Hersteller bereits eine fertige Lösung zur Content Integration mit der entsprechenden führenden Anwendung? Welcher Ansatz wurde gewählt – welche Funktionstiefe ist implementiert?
• Gibt es für das ECM bereits entsprechende Referenzlösungen mit gleichen Integrationsanforderungen?
• Gibt es Programmierobjekte (Java, COM usw.) und Tools zur Content Integration vom ausgewählten ECM und von der führenden Anwendung?
• Ist beim Projektpartner entsprechendes Know-how insbesondere für das bestehende führende Anwendungssystem vorhanden?
• Wie ist auf Releasewechsel der führenden Anwendung bzw. des ECM zu reagieren?
• In welchem System findet die Indexverwaltung statt?
• Lassen sich die Replikations-, Backup- und Restore-Funktionalitäten des ECM in den Backupszenarien der führenden Anwendung integrieren?
• Sind Integrationsalternativen konzeptionell ausgearbeitet und verbindlich angeboten worden?