Obwohl seit fast 20 Jahren Archiv- bzw. Dokumenten Management Lösungen in Unternehmen eingerichtet werden, stellt auch heute noch die Verbindung von Fachanwendung und Enterprise Content Management System (ECM-System) in fast jedem Projekt eine Herausforderung dar und ist häufig eine der Gründe für unkalkuliert hohe Projektkosten. Lesen Sie in diesem zweiteiligen Artikel, warum das so ist, welche technischen Lösungen es zur Anwendungsintegration gibt und welche Bewertungskriterien es in Hinblick auf die Content Integration für ECM-Systeme gibt.

Ein wohl typischer Bereich für ECM-Lösungen ist die elektronische Rechnungsbearbeitung. Anwender arbeiten innerhalb einer solchen Lösung mit gescannten Rechnungen, um die darauf enthaltenen Daten in eine Fachanwendung zu übertragen, zu buchen oder mit dort gespeicherten Daten abzugleichen. In vielen Arbeitsumgebungen werden die in den Dokumenten liegenden, eher unstrukturierten Informationen benötigt, um auf dieser Basis strukturierte, in Datenbanken gespeicherte Informationen zu erstellen oder mit diesen abzugleichen bzw. deren Richtigkeit zu überprüfen.

Diejenige Fachanwendung, für die das Enterprise Content Management unterstützende Funktionen bietet, wird in ECM-Projekten als „führende Anwendung“ bezeichnet. In der führenden Anwendung recherchiert der Nutzer das Datenumfeld seiner fachlichen Anforderung und verwendet das ECM zur Ermittlung weiterführender Informationen oder zur Validierung der in der führenden Anwendung gefundenen Informationen. In Postkorb-Umgebungen liefert das ECM dem Anwender diejenigen Dokumente, die für die Erstellung (Bsp. Versicherungsantrag) oder Anpassung (Bsp. Änderungsbescheid) des Datenumfelds benötigt werden.

Heutige Enterprise Content Management Lösungen bilden die evolutionäre Weiterentwicklung klassischer Dokumenten Management Lösungen: Den gesteigerten Ablageanforderungen von Unternehmen haben Anbieter von klassischen Dokumenten Management Lösungen Rechnung getragen, indem sie die Speichermöglichkeiten ihrer Systeme um komplexen Content wie Audio-, Bild-, Videodaten und Anwendungsdaten erweitert haben. Im vorliegenden Artikel verwenden wir daher den Begriff „Content Management“ für solche Systeme, die neben „klassischen“ Dokumenten auch obigen Content aufnehmen und verwalten können. Die im Artikel problematisierte Aufgabenstellung der Content Integration gilt überdies auch für „reine“ Dokumenten Management Lösungen.

Die Notwendigkeit zur Content Integration besitzt viele Facetten. Die Forderung „Das ECM muss mit der XYZ-Anwendung integrierbar sein“ bezieht sich aus Sicht des Anwenders zumeist auf eine sogenannte „Retrieval-Integration“: Der Anwender soll über eine einfache Funktionswahl unmittelbar aus der Fallbearbeitung in die zugehörige Dokumentenansicht verzweigen können.

Doch Content Integration geht in fast jedem Projekt über diese Anforderung weit hinaus: Der Anwender muss immer häufiger seine zur Fallbearbeitung erhaltenen und versendeten E-Mails neben der papiergebundenen Korrespondenz im ECM hinterlegen können, ebenso sein mit der Textverarbeitung erstelltes Antwortschreiben und auch die mit der Tabellenkalkulation erstellte Kalkulationsbasis. Hierfür benötigt er entsprechende Archivierungsfunktionen, möglicherweise getrennt für seine Groupware- und seine sonstige Desktop-Umgebung.

Neben dieser Individual-Korrespondenz sollen alle Kundenanschreiben aus dem zentralen Drucksystem ebenfalls im ECM vorliegen – und zwar im gleichen Ordner wie die anderen, gescannten, gefaxten oder vom Desktop übernommenen Dokumente.

Um die Übernahme der Druckdaten zu bewerkstelligen, benötigt der Anwender leistungsfähige und flexible Archivierungsfunktionen für immer komplexere Druck- und Objektdaten. Die hierfür von ECM-Herstellern angebotenen Cold-Produkte reichen jedoch häufig nicht (mehr) aus und erfordern nicht selten eine Anpassung der Druckverfahren und -datenströme, um enthaltene Metadaten und weitere Dokumentenbeschreibungen wie Dokumenten- und Seitentrennung „ECM-kompatibel“ bereitzustellen.

Eine weitere Herausforderung stellt die vielfach begrenzte Unterstützung unterschiedlicher Druckdatenströme seitens der ECM-Hersteller dar; so wird zum Beispiel die weit verbreitete Druckersteuerung via AFP (Advanced Function Presentation) oder Xerox Metacode nur in ganz wenigen COLD-Lösungen native unterstützt. Alle anderen ECM-Lösungen erzwingen hier eine zusätzliche Format-Konvertierung z.B. in PDF oder TIFF auf der Basis von „Standard“-Drittprodukten; solche Funktionen sind dann als weiterer Prozess in die Archivierungskette einzubinden und dauerhaft zu pflegen. Bei Archivierungsproblemen muss die gesamte Archivierungskette geprüft werden – vom Korrespondenzsystem über das Drucksystem, über die Konvertier-Strecke bis hin zum Ablagesystem, was eine geordnete Job-Verfolgung komplex und teuer macht.

Neben der Fachabteilung möchte das Rechenzentrum darüber hinaus gerne die vorhandene ECM-Infrastruktur zur Langzeit-Speicherung ihrer Anwendungsdaten nutzen, um den neuen Anforderungen zur Datenaufbewahrung gem. § 14 AO (Stichwort: „GDPdU „) gerecht zu werden, ohne hierfür die teure, hoch-performante Speichertechnologie der Online-Umgebung verwenden zu müssen. Außer bei SAP gibt es für diese – in der letzten Zeit besonders häufig anzutreffende Anforderung – seitens der Hersteller betriebswirtschaftlicher Anwendungssysteme keine Standard-Lösung; Projektlösungen sind also gefragt.

Abbildung 1: Bei der Integration von ECM-Systemen in fachliche Anwendungen
sind viele Schnittstellen und Funktionen zu berücksichtigen.

Was heißt hier „Standard“-Schnittstelle?

Standard-Archivschnittstellen bieten ausschließlich SAP und ADP (Paisy) an. Beide Hersteller verwenden überdies ein Zertifizierungsverfahren, um die Korrektheit der implementierten ECM-Schnittstelle sicherzustellen. Übrigens stellt die Zertifizierung genau und nur diese Kompatibilität sicher und bewertet insbesondere nicht die sonstige Leistungsfähigkeit der geprüften ECM-Lösung.

In allen anderen Anwendungsumgebungen muss projekt-individuell eine Integration vorgenommen werden. Selbst wenn einige ECM-Hersteller vollmundig mit einer „Standard“-Baan-, Navision- etc. Integration werben, beschränken sich diese häufig auf die Bereitstellung vorkonfigurierter COLD-Jobs zur Archivierung ausgehender Dokumente aus obigen Anwendungssystemen. Eine Retrieval-Integration ist dann schon nicht mehr „Standard“. Die Hersteller der auf diese Weise integrierten betriebswirtschaftlichen Anwendungen wissen häufig kaum von der Existenz besagter Standard-Schnittstelle, bei Release-Wechseln der Standard-Anwendung kann es daher durchaus zu Schnittstellenproblemen kommen.

Content Integration ist klassisch auf den zwei Ebenen der Client-Integration und der Server-Integration zu betrachten.

Client-Integration

Im Rahmen der Client-Integration spielt vor allem der Online-Abgleich von Datenbeständen eine wesentliche Rolle. Die Integration der ECM-Anzeigefunktion in die führende Anwendung (z.B. via „Screen-Scraping“ der innerhalb der Terminal-Emulation angezeigten Maske) gehört ebenso dazu wie die Abfrage von Stammdaten aus der Host-Datenbank, die im Rahmen der Dokumenten-Indizierung erfolgt, um die Korrektheit der eingegebenen Suchkriterien sicherzustellen.  Möglicherweise gilt es also, mehrere Clients (hier: Retrieval- und Indizier-Client) mit der führenden Anwendung zu integrieren.

Für die Aufgabenstellung der Client-Integration haben sich eine Reihe von Techniken etabliert, die alle ihre spezifischen Vor- und Nachteile aufweisen (siehe hierzu auch die Artikel von Bernhard Zöller in den Newslettern vom Oktober 2004 und Mai 2005):

Die einfachste Form der Client-Integration – eigentlich eher ein abgestimmtes Zusammenspiel zwischen den Systemen –  erfolgt über den Sachbearbeiter. Die Fachanwendung wird mit dem ECM über „Copy & Paste“ oder manuelles Eintippen der ECM-Suchkriterien durch den Sachbearbeiter selbst angebunden. Ein solches Vorgehen erfordert, dass alle Content Informationen im ECM hinterlegt sind und dass das ECM kritische Abfragekriterien aus führenden Anwendungen verwendet, wie die Buchungsnummer, die Schadennummer oder Kundenstammnummer. Diese Art der Integration, die keine technische Integration darstellt, wird immer dann gewählt, wenn entweder das führende Anwendungs­system oder das Content-Management System über keine technischen Integrationsmöglichkeiten verfügt oder der Aufwand zur Nutzung dieser Schnittstellen über dem erwarteten Nutzen liegt.

Manchmal sind es recht triviale Dinge, die diese Art der Content Integration erfordern: So fehlt möglicherweise einfach das Know-how im Unternehmen, die betroffene Legacy Anwendung im Source Code anzupassen oder es macht einfach keinen Sinn, Investitionen in eine betriebswirtschaftliche Anwendungen zu tätigen, die kurz vor ihrer Ablösung steht.

Fortschrittlicher ist da schon die Window-Window-Integration via „Screen Scraping“, die überwiegend in Verbindung mit Host-Terminalemulationen eingesetzt und technisch über DDE/OLE-Mechanismen abgebildet wird: Per Tastendruck gestartet, liest ein Makro maskenspezifisch Bildschirminhalte, zum Beispiel die Versicherungsschein-Nummer oder die Buchungsnummer, aus der Host-Maske heraus und übergibt diese Suchkriterien an eine ECM-Abfragefunktion; das gefundene Dokument wird unmittelbar zur Anzeige gebracht.

Gerne wird diese Funktionalität im Rahmen der Indizierung für die automatische Übernahme von Indexdaten aus dem Host in die ECM-Umgebung verwendet, was gleichzeitig den Erfassungsaufwand verringert und überdies eine hohe Metadaten-Qualität im ECM zur Folge hat.

Vorteilhaft ist, dass die Screen-Scraping Methode relativ einfach abgebildet werden kann und keine funktionale oder datenbanktechnische Erweiterung der führenden Anwendungsumgebung erfordert, da sie vollkommen auf dem Client, innerhalb der Terminalemulation abgehandelt wird. Sie ist daher auch heute noch in der Praxis häufig anzutreffen.

Die wesentlichen Nachteile dieser Methode liegen jedoch darin, dass jede Änderung des Masken-Layouts auf der Host-Seite eine Anpassung der Schnittstelle zur Folge hat, und dass für jede betroffene Host-Maske die Integration separat zu implementieren ist. Das „Screen Scraping“ setzt überdies eine programmierbare Terminalemulation und einen programmierbaren ECM-Client voraus, die beide miteinander kommunizieren können müssen – zumeist per DDE / OLE.

Bei der ECM-Produktauswahl ist also darauf zu achten, dass der mitgelieferte Client nicht nur Anzeigfunktionen besitzt, sondern überdies mit ausreichend flexiblen API-Funktionen ausgestattet ist. Dies gilt dann sowohl für den Retrieval-Client als auch für die Scan- bzw. Indizierfunktion.

Einige Anwender haben extensiv auf die Screen-Scraping-Möglichkeiten gesetzt und teilweise zusätzliche Makros zum Datenabgleich etc. implementiert. Große Schwierigkeiten ergeben sich dann beim Versuch, diesen Lösungsansatz in den Browser zu verlagern, da die DDE/OLE-Schnittstellen und auch die Makro-Erweiterungsmöglichkeiten der Terminalemulationen dort nicht zur Verfügung stehen. Plötzlich gilt es, eine neue Umgebung für eine komplexe, gewachsene Integration zu definieren, die dem Anwender den gleichen, hohen Komfort bietet wie die alte Lösung.

Programm zu Programm Kommunikation ist aufwendig

Für Anwender, denen eine „oberflächliche“ Integration nicht ausreicht, bietet sich die Möglichkeit der unmittelbaren Programm-zu-Programm-Integration, wie z.B. bei IBM Mainframe-Umgebungen über das APPC/LU6.2 Protokoll. Diese Technologie bietet die Möglichkeit, eine spezifische Oberfläche zu schaffen, die Host-Daten und Content-Informationen gleichermaßen beinhaltet.

Die Realisierung setzt jedoch umfangreiche Anpassungen und Erweiterungen der etablierten, Host-basierten Anwendungen bzw. die Errichtung solcher Anwendungen voraus, da per APPC vom Client aus nicht unmittelbar mit der Host-Datenbank, sondern immer mit einem Host-basierten Programm kommuniziert werden muss, das wiederum als Datenbank-Service dienen kann und somit die Verbindung zur Datenbank regelt.

Nur wenige ECM-Hersteller haben innerhalb ihrer Client-API eine direkte Unterstützung des LU6.2 Protokolls implementiert. Vor allem aber aufgrund des hohen Aufwands in der Realisierung wurde und wird dieser Ansatz der Client-Integration daher nur in relativ wenigen Projekten genutzt.

Weitere Client-Integrationstechniken

Letztlich stellt sich die Frage, ob die ECM-Client-Umgebung mit der entsprechenden Client-Umgebung der führenden Anwendung zu integrieren ist oder ob eine Verbindung vom Client zur Server-Seite bzw. direkt zur Datenbank der führenden Anwendung geschaffen werden soll.

Moderne, lokale Client-Client-Schnittstellen basieren in der Windows-Umgebung auf der von Microsoft zur Verfügung gestellten COM / ActiveX Technologie. Dies kann jedoch nur funktionieren, wenn beide Anwendungs-Clients programmierbare COM-Objekte  oder ActiveX-Controls bereitstellen. Fehlt die entsprechende Unterstützung auf lediglich einer Seite, egal ob ECM oder führende Anwendung, dann kann diese Art der Integration nicht genutzt werden.

Die lokale Client-Client-Integration kann überdies nicht ausreichend sein, wenn zum Beispiel seitens ECM von der führenden Anwendung Daten benötigt werden, die der aktuellen Client-Umgebung nicht zur Verfügung stehen. So könnte auf dem Client der führenden Anwendung zwar ein Kundenstamm-Satz angezeigt sein, die Liste der zugehörigen Dokumente jedoch nicht bereitstehen. In solchen Fällen kann es notwendig sein, aus dem ECM-Client heraus unmittelbar in der Datenbank der führenden Anwendung recherchieren zu können. Vom lokalen Client beschafft sich die ECM-Anwendung dann die aktuell angezeigte Kundennummer und recherchiert selbständig – angebunden z.B. via ODBC – in der Datenbank der führenden Anwendung nach den zugehörigen Dokumenten.

Noch häufiger wird die unmittelbare Datenbank-Anbindung des ECM-Clients an eine führende Anwendung im Rahmen der Dokumenten-Indizierung genutzt: Durch einfache Datenbank-Abfrage per ODBC wird diese Datenbank genutzt, um die Korrektheit der eingegebenen Metadaten zu verifizieren und ggf. weitere abhängige Daten wie den Kundennamen und Adresse als Suchkriterien in das ECM zu übernehmen.

Lesen Sie in der nächsten Ausgabe, welche serverseitigen Integrationstechniken verbreitet sind und welche Vor- bzw. Nachteile diese besitzen. Weiterhin stellen wir Ihnen eine Checkliste zur Bewertung der Integrationsmöglichkeit Ihres ECM zur Verfügung.

Fragestellungen zur Klärung der Content Integration:

• Welches ist die für den Geschäftsprozess notwendige führende Anwendung?
• Ist eine Content Integration in die führende Anwendung sinnvoll?
• Welche Transaktionen bzw. Dialoge innerhalb der führenden Anwendung sind für die Content Integration relevant?
• Wie tief  soll das ECM in die führende Anwendung integriert werden (wie viele und welche ECM Informationen soll die führende Anwendung vom ECM erhalten, bzw. wie viele und welche Informationen soll das ECM von der führenden Anwendung erhalten)?
• Wie und wann erfolgt die Content Verknüpfung zwischen der führenden Anwendung und dem ECM?
• Welche Client- und welche Server-Prozesse sind abzugleichen?
• Wie wird die Transaktionssicherheit zwischen der führenden Anwendung und dem ECM gewährleistet?
• Welche Auswirkung auf die Systemwartung und den Systembetrieb hat die Content Integration mit dem führenden Anwendungssystem?