WebSpool sorgt dafür, dass Dateien in der richtigen Form an den Client übertragen werden.
Alle Dateien durchlaufen vom Empfang bzw. Import bis zur Anzeige/Verarbeitung am Client eine Reihe von Verarbeitungsschritten und münden jeweils in einen definierten Status des Dokuments. Die Stati werden durch Verzeichnisse repräsentiert. Jedes Dokument in einem bestimmten Verzeichnis besitzt also einen definierten Status. So kann sich der Administrator sehr einfach und intuitiv einen Überblick über den Stand des Dokumentenversands verschaffen. Die beteiligten Prozesse betrachten immer nur einen kleinen Ausschnitt aus der Menge der zu verarbeitenden Daten, was zu eine guten Performance führt. Darüberhinaus wird durch Cache Mechanismen der Zugriff auf die physikalischen Verzeichnisse minimiert.
Jedes Dokument durchläuft im Wesentlichen die Stadien:
Das Verzeichnissystem für WebSpool sieht demnach wie folgt aus:
spool
/receive
/in
/notified
/out
/archive
Der Ort des Basisverzeichnisses "spool" is konfigurierbar und liegt normalerweise unter dem Basisverzeichnis der Benutzerkonfiguration.
Während des Verarbeitungsprozesses muss sichergestellt sein, dass jedes Dokument eindeutig identifizierbar und einem Benutzer zugeordnet ist. Daher wird ein einheitliches Namensschema verwendet, das diesen Anforderungen Rechnung trägt. Bei der Übergabe einer Datei an WebSpool wird der originale Dateiname um diese Attribute ergänzt und ein interner Name gebildet.
Die WebSpool ist so konfiguriert, dass bei der Mehrzahl der Installationen
keine Änderungen notwendig sind.
Die Konfigurationsparameter besitzen alle
den Prefix Spool und werden in der ajax.ini Datei festgelegt.
Die Zuordnung von Dateityp zu MIME-Type nimmt der Application-Server zum Zeitpunkt der Dateiabforderung vor. Zur Konfiguration dieser Zuordnung konsultieren Sie bitte die Dokumentation Ihres Applikationsservers.
Die Weiterleitung von Mainframe-Dokumenten bzw. Druckdaten an den Client erfolgt völlig automatisch und bedarf lediglich einiger gängiger Konfigurationen. Für die Anbindung an Unix können spezifische - von der Aufgabenstellung und der Infrastruktur abhängige - Möglichkeiten in Betracht gezogen werden. Welche Lösung die Geeignetste ist, muss von Fall zu Fall geklärt werden.
Generell erfolgt der Datei-Import, außer Mainframe, via http POST in Form von multipart/form-data (vgl. RFC 2388, 2387, 2046, 1867, 1521).
Dabei sind folgende Informationen zu übermitteln:
Diese Daten sind an spool/spoolin.jsp zu senden. Das
Beispiel spool/upload.jsp verdeutlicht die Vorgehensweise.
Für die Unix-Integration kann z.B. das Programm
logwebimport (Bestandteil der LogWeb-Installation) verwendet werden.
Beispiel: logwebimport -u demo -f test.txt -config logwebimport.ini bzw. logwebimport -u demo -f test.txt
Im letzteren Fall sucht logwebimport seine Konfigurationsparameter in der server.ini von LogWeb. Wesentlicher Parameter ist ImportDestination.
Beispiel:
ImportDestination= http://127.0.0.1:8080/ajax/spool/spoolin.jsp
Mit dieser einfachen Importschnittstelle sollte jede externe Quelle in der Lage sein, Daten an WebSpool zu übergeben.
Für besondere Aufgabenstellungen können die Daten auf dem Weg zum Client geändert werden. Die Möglichkeiten reichen vom einfachen Umbenennen mit daraus resultierendem neuen MIME-Type über Textersetzung für sprachspezifische Varianten, von Broadcast eines Dokuments an viele Benutzer, bis zur PDF Generierung "on the fly".
Die benötigte Transformations- bzw. Filterfunktionalität wird als Java Klasse implementiert. Welche Filter auf welches Dokument anzuwenden sind, wird durch Regeln festgelegt. Die Regeln können sich sowohl auf Dateinamen als auch auf Dateiinhalte beziehen.
Beispiel: Füllen eines PDF-Formulars mit Hostdaten in Form einer XFDF Datei (vgl. Adobe XFDF 2.0 Specification).
Der Host erzeugt keinen Druckdatenstrom mehr und generiert auch nicht das komplette Dokument, sondern liefert nur noch den Inhalt von Feldern, die z. B. aus einer Datenbank stammen können. WebSpool füllt mit diesen Daten ein PDF-Formular und liefert an den Client ein PDF-Dokument ab.
Welches Formular zu verwenden ist bestimmt die Anwendung am Host. Diese Information wird ebenfalls im XFDF-Datenstrom übermittelt. Die Formulare sind auf dem Server für die Webapplikation hinterlegt. In diesem Beispiel sind die Formulare im Verzeichnis "PDFTemplates" zu finden.
In der Datei filter.xml wird festgelegt unter welchen Bedingungen welche Filter zur Anwendung kommen. Sie enthält u. A. folgende Einträge:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE spool-filter SYSTEM "spool-filter_1_0.dtd">
<spool-filter version="1.0">
<description> Spool filter for LogAjax</description>
<doc-class name="XFDF Merge PDF">
<condition>
<and>
1. <filename regexp=".*\.lwf"/>
2. <contains regexp=".*\x3Cxfdf\s+xmlns\s*=\s*\x22http://ns.adobe.com/xfdf/\x22"/>
</and>
</condition>
<filter-chain>
3. <filter name="XFDF Merger" class="de.logics.logwebAppV3.spool.in.filter.PDFFormFiller">
<param name="TemplateDir" value="PDFTemplates"/>
</filter>
4. <filter name="rename" class="de.logics.logwebAppV3.spool.in.filter.Rename">
<param name="extension" value="pdf"/>
</filter>
</filter-chain>
</doc-class>
</spool-filter>
Falls die Bearbeitung fehlerfrei durchgeführt wurde, wird die so erzeugt Datei für den Versand an den Client bereit gestellt. Im Fehlerfall erhält der Client eine detailierte Meldung.
Einen kleinen Leitfaden zur Implementierung eines Filters finden Sie in der Entwickler Dokumentation. Die Beschreibung der entsprechenden Java Schnittstelle ist auf Anfrage erhältlich.