DBV-Winterthur Versicherungen
Von AFP nach PDF mit 70 Seiten pro Sekunde
Der Beschluss des Vorstandes der DBV-Winterthur Versicherungen im Jahre 2002 klang zunächst unspektakulär - Agenturen und Mitarbeiter sollten über das Web auf die Firmenarchive der Versicherung zugreifen können. Ob Vorgänge, Schriftverkehr und Verträge: Über ihren Browser und den Acrobat Reader sollen sie die AFP-Dokumente im FileNet-Archiv des Unternehmens recherchieren können. Um dieses Ziel zu verwirklichen, waren allerdings neue Maßstäbe zu setzen und zu erfüllen: Angesichts der Vielzahl von Benutzern und Zugriffen sowie der Notwendigkeit, im Intranet den Mitarbeitern schnelle Antwortzeiten zu bieten, wurde in der Ausschreibung vorgegeben, auf einer Sun Solaris Sparc-3 AFP-Dokumente mit einer Performance von mindestens 70 Seiten in der Sekunde in PDF umzuwandeln.
Die Aufgabe
Die Mitarbeiter der DBV-Winterthur schreiben Tag für Tag bis zu 20.000 Briefe an ihre Kunden. Zusätzlich erzeugt ein IBM-Mainframe zehntausende Serienbriefe, die an die Versicherten verschickt werden. Anforderung war, diese Briefe nicht nur zu drucken, sondern auch parallel im FileNet-Archiv abzulegen. Auf diese Weise sollten die Mitarbeiter – und bald auch die Agenturen – in die Lage versetzt werden, die Schriftstücke zu recherchieren. Wegen der sehr großen Anzahl von Dokumenten im Archiv fiel die Entscheidung zugunsten von AFP als Ablageformat, denn Dokumente diesen Formats sind wegen des Ressourcen-Konzepts von AFP sehr klein. Zudem geht man davon aus, dass AFP auch zukünftig durch die IBM unterstützt wird und archivierte Dokumente somit auch langfristig in dieser Form archiviert und sicher reproduziert werden können.
Wegen der Zusammensetzung der Benutzer (Mitarbeiter und Agenturen) sollten diese einheitlich über einen Internet- Browser auf die Dokumente zugreifen. Ihre Darstellung im AFP-Format war damit ausgeschlossen, da den externen Benutzern das Herunterladen und Installieren eines AFP-Plugins für den Browser nicht zuzumuten war. Die Vorgabe war folglich, das angeforderte Dokument in einem für alle Benutzer ohne weitere Voraussetzungen anzeigbaren Format zu übertragen, es also vor der Übertragung in dieses Format umzuwandeln.
Für diese meist mehrseitigen Dokumente kam damit nur PDF als Zielformat in Frage, da vorausgesetzt werden kann, dass jeder Benutzer das Acrobat Reader Plugin von Adobe auf seinem PC installiert hat. Die Herausforderung war deshalb, im Moment des Benutzerzugriffs (on-the-fly) die AFP-Dokumente in PDF umzuwandeln, und zwar mit einer Geschwindigkeit, die selbst bei der im Endausbaustadium anvisierten hohen Anzahl von mehreren Tausend Benutzern schnelle Antwortzeiten garantierte. Die DBV-Winterthur hat aus diesem Grunde den Anbietern entsprechende Vorgaben gemacht:
- Die Lösung musste in der Lage sein, AFP-Dokumente mit mindestens 75 Seiten pro Sekunde (die exakten Anforderungen waren: 5 Dokumente à 15 Seiten pro Sekunde bzw. 8 Dokumente à 9 Seiten pro Sekunde) auf einer 750 MHz-Sun Solaris Sparc-3 mit zwei Prozessoren in PDF umzuwandeln.
- Der gesamte Zugriff auf ein archiviertes AFP-Dokument im Intranet durfte bis zur Anzeige nicht länger als eine Sekunde dauern.
- Das Erscheinungsbild des PDF-Dokuments sollte von dem des ursprünglichen AFPs nicht abweichen.
Das Lösungskonzept
Diese Vorgaben zu erfüllen, war in der Tat nicht trivial. Nach Diskussionen und Tests stellte sich für die Projektverantwortlichen sehr bald heraus, dass nicht nur ein sehr performantes Konvertierungsprodukt notwendig war, sondern auch ein Lösungskonzept, das über Standardlösungen hinausging. Die ersten Tests zeigten der DBV-Winterthur, dass das DocBridge Toolkit von Compart in den Punkten Durchsatz, Stabilität, Abbildungstreue und Architektur am besten überzeugte. Zwar konnte auch dieses Produkt zunächst nur auf einer schnellen Windows-Maschine den geforderten Durchsatz erreichen, dafür aber konnte Comparts Entwicklungsabteilung Wege aufzeigen, wie der Durchsatz auch auf einer Sun Solaris des vorgegebenen Typs zu erreichen ist.
Das Ziel war mit zwei Maßnahmen zu bewältigen: Zum einen wurde der Code des Produkts hinsichtlich des internen Ressourcen-Cachings optimiert, zum anderen schlug Compart für die Ressourcenanalyse vor der Archivierung den Einsatz des hauseigenen AFP Resource Managers in einer erweiterten Variante vor.
Die weiteren Tests hatten gezeigt, dass der angestrebte Durchsatz dann zu erreichen war, wenn die Ressourcen, die in den AFPDokumenten referenziert wurden, für den Server schnell zuzugreifen. Jedes Öffnen einer neuen Ressource-Datei bedeutet zusätzliche I/O-Zugriffe, die den gesamten Umwandlungsprozess entscheidend verlangsamen. Dementsprechend sollte die Anzahl der zu öffnenden Ressource-Dateien möglichst klein gehalten werden. Dies ist zu erreichen, indem möglichst alle Ressourcen, auf die AFP-Dokumente referenzieren, in einer Ressource-Datei zu finden sind. In diesem Fall befindet sich die Ressource-Datei für alle Auflösungszugriffe noch im Cache des Konvertierungsservers und kann damit sehr schnell vom Prozessor gelesen werden.
Der Durchsatz sollte aber für die Umwandlung nicht nur eines Dokuments erreicht werden, sondern auch für die Folge-Dokumente. Diese können sich gegenüber den Vorgänger-Dokumenten in folgenden Punkten unterscheiden:
- Es kommt eine zusätzliche Ressource hinzu. Dann hat sie einen neuen, bisher nicht verwendeten Referenznamen. In diesem Fall ist es sinnvoll, die bisherige Ressourcen-Datei um diese zusätzliche Ressource zu erweitern, selbst wenn das Dokument auf andere Ressourcen aus der Ressource-Datei nicht referenziert.
- Es ändert sich eine Ressource. Dann hat sie zwar den gleichen Referenznamen wie die, die sie ersetzt, aber einen anderen Inhalt. In diesem Fall muss eine neue Ressourcen-Datei gebildet werden, damit die gleichnamigen Referenzen auf die zugehörigen unterschiedlichen Ressourcen verweisen können.
Dieses Verfahren der Ressourcen-Anreicherung sorgt also dafür, dass wegen einer zusätzlichen Ressource nicht eine neue Ressource-Datei erzeugt wird, die beim Retrieval zusätzlich geöffnet werden müsste. Außerdem wurde vorgeschlagen, die Analyse der Ressourcen durch den Compart Resource Manager getrennt nach Druckjobs vorzunehmen. Für sich betrachtet enthält ein Druckjob in der Regel ähnliche Dokumente, die auf dieselben AFP-Ressourcen zurückgreifen. Da Dokumente unterschiedlicher Druckjobs wenig gemeinsame Ressourcen enthalten bzw. selbst bei inhaltlich gleichen Ressourcen unterschiedliche Referenznamen verwenden, ist es sinnvoll, Dokumente unterschiedlicher Druckjobs mit getrennten Ressource-Dateien zu versorgen. Auf diese Weise führt eine geänderte Ressource nur zu einer neuen Ressource-Datei für diesen Druckjob, während die Ressource-Dateien der anderen Druckjobs dadurch nicht berührt sind. Da eine Ressource-Datei für einen Druckjob viel kleiner ist als eine Ressource-Datei für sämtliche Druckjobs zusammen, fällt der Zuwachs durch die zusätzliche Ressource-Datei von der Größe her bedeutend kleiner aus.
Diese Maßnahmen begrenzen den Speicherplatz, der im Cache des Konvertierungsservers für die Ressource-Dateien vorzuhalten ist, sehr effektiv – auch dadurch begünstigt, dass die Ressourcen der AFP-Dokumente bei der DBV-Winterthur sich nicht sehr häufig ändern. Die AFP-Font-Ressourcen wurden wiederum in einer separaten Ressourcen-Datei zusammengefasst, die für alle AFP-Dokumente verwendet wird. Sie sind relativ groß und ändern sich in der Regel über Jahre hinweg nicht. Daher lag es nahe, sie in einer getrennten Ressource-Datei auszulagern und sie damit permanent im Cache des Servers zu halten. Die Abbildung auf Seite 14 zeigt schematisch, wie die Ressourcen bei der DBV-Winterthur zusammengestellt und gelesen werden.
Damit war das Durchsatzziel auch auf dem Sun Solaris-Rechner der DBV-Winterthur erreicht: Im Abschlusstest brachte es die Lösung schließlich auf eine Geschwindigkeit von 116 Seiten pro Sekunde (6,2 Dokumente à 18,7 Seiten) bzw. 58 Seiten pro Sekunde (18 Dokumente à 3,27 Seiten), die von AFP nach PDF gewandelt wurden – und die DBV-Winterthur entschied sich dafür, die Compart-Lösung einzusetzen.
Die Implementierung der Lösung
Zur Umsetzung der Gesamtlösung mussten die folgenden zwei Anwendungen implementiert werden:
- Der AFP Resource Manager musste bei der AFP-Archivierung ins FileNet- Archiv in der von Compart vorgeschlagenen Weise eingebaut werden, um die gewünschten Ressource-Dateien zu erzeugen.
- Für das Heraussuchen und Anzeigen der Dokumente auf einem Web-Browser musste eine Web-Retrieval-Anwendung programmiert werden.
"Der AFP Resource Manager wurde vor dem FileNet Archiver für die Extraktion der Ressourcen und die Erstellung der Ressource-Dateien implementiert", erläutert Klaus-Dieter Häuser, Referent für das DMS-System bei der DBV-Winterthur. "Dazu analysiert und vergleicht er binär die Ressourcen mit denen der letzten Ressource-Datei." Bei jedem neuen zu archivierenden Dokument bzw. Dokumenten- Spool wird geprüft:
- Ob eine zusätzliche Ressource mit neuem Namen im Datenstrom vorhanden ist: Dann erweitert er die zugehörige Ressource- Datei um diese Ressource.
- Ob die Ressourcen mit gleichem Namen auch inhaltlich mit ihren Namensbrüdern übereinstimmen: Er vergleicht also diese Ressourcen binär und erstellt, sobald er auf eine geänderte trifft, eine neue Ressourcen- Datei, andernfalls ordnet er dem Dokument die zuletzt gültige Ressourcen- Datei mit den inhaltlich gleichen Ressourcen zu.
Nach Prüfung der gesamten Ressourcen eines AFP-Dokumenten-Spools trägt er die Namen beider Ressourcen-Dateien (derjenigen ohne die Fonts und der Font- Ressourcen-Datei) in einem TLE eines jeden AFP-Dokuments (TLE = Tag Logical Element: nicht-druckbares Element im AFP-Datenstrom) ein, also derjenigen beiden Ressource-Dateien, in denen sämtliche Ressourcen dieses Dokuments zu finden sind. Insoweit kann eine Anwendung bereits aus dem Dokument selbst entnehmen, in welchen Ressource-Dateien die referenzierten Ressourcen zu finden sind.
Außerdem übergibt der AFP Resource Manager für jedes Dokument die zugehörigen Namen der beiden Ressource- Dateien an das FileNet-Archiv. Denn dort wurden für jedes Dokument zusätzliche Indizes für die Ressource-Datei-Namen reserviert, um diese auch ohne Analyse des AFP-Dokumentendatenstroms herauslesen zu können.
Die Font-Ressourcen legt der AFP Resource Manager in einer separaten Font- Ressource-Datei ab. Die Ressourcen-Dateien werden dann dem FileNet Archiver zur Archivierung und dem Konvertierungsserver zur Ablage auf einer seiner Festplatten übergeben, um beim Umwandeln schnell zugreifen zu können.
Die Retrieval-Anwendung am Client ist je nach Benutzerkreis unterschiedlich: Die Inhouse-Benutzer wählen an ihren PCs die Dokumente über ein Servlet aus (Hinweis für die Experten: Das Servlet wird über Active-X-Komponenten des Internet- Explorers angesprochen und greift per Screen-Scraping die Dokument-ID des Dokuments aus einer CICS-Anwendung ab). Das Servlet ruft eine Enterprise Java- Bean auf, die wiederum das ausgewählte Dokument (gegebenenfalls inklusive Ressourcen- Dateien) aus dem FileNet-Archiv holt, mit dem DocBridge Toolkit ins PDF konvertiert und dann beim Benutzer zur Anzeige bringt. Für die Anzeige bei den Vermittlern dagegen ist eine Java-Anwendung vorgesehen, die dem Benutzer eine Suchmaske auf seinem Browser anzeigt und seine Suchanfrage über eine Web- Applikation an das Host-Vorgangsarchiv weiterleitet. Das Host-Vorgangsarchiv liefert eine Trefferliste zurück, aus welcher der Benutzer das gewünschte Dokument auswählen kann.
Die Retrieval-Anwendung, mit der die Benutzer in ihrem Web-Browser die Dokumente suchen und anzeigen sollten, ist eine Java-Anwendung, in der folgende Funktionen zu integrieren waren: Der Benutzer musste eine Suchmaske auf seinem Browser angezeigt bekommen, deren Suchanfrage über einen Web-Server an das FileNet-Archiv weitergeleitet wurde. Das FileNet-Archiv liefert eine Trefferliste zurück, aus der der Benutzer das gewünschte Dokument auswählen kann. Der Application Server fordert das ausgewählte AFP-Dokument und seine Ressourcen- Indizes vom Archiv-Server an. "Die Java-Anwendung auf diesem Server integriert die Funktionen des DocBridge Toolkits: Es liest das AFP-Dokument ein und analysiert die Referenzen auf die Ressourcen im Datenstrom.", sagt Häuser. "Um die AFP-Referenzen aufzulösen, öffnet es die zugehörige Ressource-Datei, deren Name es im übergebenen Ressourcen- Index gefunden hat – es sei denn, die Ressource-Datei ist von den Zugriffen vorher bereits im Cache und damit noch im schnellen Zugriff. Das auf diese Weise zusammengefügte Dokument wandelt das DocBridge Toolkit anschließend in ein PDF um." Das PDF wird an den Web- Server weitergeschickt, der es wiederum an den Browser des abfragenden Benutzers weiterleitet. Dort wird das Dokument im Acrobat Reader-Fenster des Browsers zur Anzeige gebracht.
Die Implementierung der Web-Anwendung übernahm die Firma ELSAG aus Villingen-Schwenningen. Heute liegen für den Zugriff über das Web bereits rund 80 Millionen Dokumente im Archiv.