Bestellzettel 2.0

Der neue Workflow für den Bestellzetteldruck an der SUB Göttingen

Ausgangslage (Zettel)

Ausgangslage (Infrastruktur)

• OUS produziert Textdateien auf Basis eines Layouts
• Ergebnis sind ASCII Dateien
• Antiquirter Zeichensatz (Codepage 858)
• Erzeugte Text Dateien werden auf Basis des Dateinamens vom ous_print_server an die Drucker (CUPS) geschickt bzw. per Mail verschickt
• Hotfolder Mechanismus

Neue Anforderungen

• Primär
  • Nutzernummer kürzen ✔
    • Notwendig für die Anonymisierung im Selbstabholbereich
  • Je nach Nutzertyp und Ziel soll der Zettel nicht anonymisiert werden ✔
  • Gut leserliches Layout (große Schrift) für Mitarbeiter bei der Arbeit und Nutzer am Selbstabholbereich ✔
  • Nutzer Initial anzeigen ✔
  • Keine Verzögerung durch die Erstellung ✔
• Sekundär
  • Logo einbinden und Leserichtung entsprechend der Blickrichtung ✔
  • Vereinfachung bei der Erstellung und Anpassung von Layouts ✖
  • XSLT-FO Kenntnisse nun notwendig – siehe Ausblick

Bestehende Anforderungen

Der Dienst sollte alles können was der Vorgänger kann

• Automatisch startender Dienst, der das Eingangsverzeichnis laufend überwacht ✔
• Druck (ohne Änderungen an CUPS) und Mail Funktion ✔
• Erkennung des Druckernamens auf Basis des Dateinamens ✔
• Einfach erweiterbar ✔
• Betrieb unter Solaris 10 ✔
• Verschiedene Ausgabepapierformate (A4 / A5) ✔
• Bearbeitete Dateien sichern ✔

Grundannahmen

• Ein Layout gibt an, was wo auf den Zettel gedruckt werden soll
• Daher: Welcher Teil eines generierten Zettels welche Bedeutung hat, kann man auf Basis des Layouts die Datei interpretiert werden
• Wenn man die Layout Datei in XML verwandelt, kann man sie mit XSLT und XSL-FO weiter verarbeiten (XML Publishing Workflow)
• Also: Man kann aus der Layout Datei einen Parser zum einlesen der Zettel generieren.
• Für die Verarbeitung kommt XSLT zum Einsatz, für die die Verbindung der Stylesheet und das Handling der Parameter Groovy
• Das Ergebnis sollte PDF oder Postscript sein um unabhängig vom Drucker zu sein

Übersicht über den Ablauf

Layout Datei einlesen – XML Repräsentation

Generierter Parser (Ausschnitt)

Geparster Zettel in XML (Ausschnitt)

Generiertes XSL FO (Ausschnitt)

Ergebnis

Nutzung auf der Kommandozeile

Möglichkeiten des Kommandozeilenprogramms

• Slips konvertieren / einlesen
• Drucker anzeigen
• Drucken
• Konvertierung in PDF, Postscript, XSL-FO
  • XSL-FO als Ausgabe kann zur weiteren Verarbeitung (XSLT, XPath) in Camel genutzt werden
• Erzeugung von XSLT basierten Parsern aus Layouts

SUB PrintServer

• Regelbasiertes Routing, Änderungen am ous_print_server entfallen
• Eigene Apache Camel Komponente um das Parsen des Layouts in einer Camel Route zu erledigen
• Camel File überwacht Verzeichnisse
• Dateinamen können als regulärer Ausdruck anagegeben werden
• Camel Print druckt erzeugte Dateien
• Alle lokalen CUPS Drucker können verwendet werden
• Camel Mail kann Ergebnisse verschicken

Apache Camel - Ein Routing Framework

• Routen haben Start- und Endpunkte, sowie Zwischenschritte
• Definiert in Java, Scala, Groovy oder XML
• Vordefinierte Start- und Endpunkte sind Dateien (auch Remote, z.B. FTP), Nachrichtensysteme („Message Queues“), Webservices, Datenbanken, Mail und viele mehr
• Punkte bzw. Schritte werden als URIs angegeben
• Eigene Funktionalitäten können als Komponente hinzugefügt werden

Beispiel für eine Route:

                    <route>
                        <from uri=""></from>
                        <to uri=""></to> 
                    </route>
                

Volständiges Beispiel:

                <route>
                    <from uri="file:/pica/prod/prt/selbstabholbereich?include=sub4235_\d{16}_slip001.print
                        &?move=../sich-selbstabhol"/>
                    <to uri="layout:.?xslfo=./xslfo/layout2fo.xsl&template=./ous40_layout_001_du.asc
                        &outputFormat=PS"/> 
                    <to uri="lpr://localhost/bbk-test"/>
                </route>
                

(Umbrüche für die Lesbarkeit eingefügt)

Erste Erfahrungen

• Postscript statt PDF sorgt für bessere Ergebnisse mit unterschiedlichen Druckern und Papierformaten
• Höheren Speicherbedarf als mit dem herkömmlichen Print Server(ous_print_server)
• Keine Geschwindigkeitseinbußen – die Prozesskette benötigt ca. 0,5 Sekunden – das Verzeichnis wird einfach doppelt so häufig abgefragt
• Titeldaten werden normalisiert ausgegeben
• Interpretation des Layouts hat eigenartige Semantiken, wenn die Feldlänge zu kurz ist
• Mehrseitige Ausgabelayouts und Mail Versand noch nicht getestet
• Umlaute werden von den Schriften auf dem System nicht unterstützt, Schriften müssen eingebettet werden

Status

• In der Zentaralbibliothek der SUB Göttingen im Produktionseinsatz
• Betriebsfragen (Monitoring, SMF-Integration noch offen)
• Barcodes können schon jetzt generiert werden – Anwendungsfall fehlt noch
• Experimentelle Erstellung von XSL-FO aus ODF (bisher Proof of Concept, kein manuelles XSL-FO mehr notwendig)
• Dokumentation wird noch erweitert
• Source Codes bei GitHub
  https://github.com/subugoe/ous-print

Nachteile

• Änderungen (z.B. Namen von Theken) müssen an zwei Stellen (OUS und Stylesheet) durchgeführt werden.
• Zusätzliche Serverkomponente (SUB PrintServer).

Ausblick

• Integration ins bestehende System
  • ous_print_server kann das Kommandozeilenwerkzeug einbinden
  • SUB PrintServer kann ous_print_server ersetzen
    • Bon Drucke mit Logo denkbar
  • Start via Solaris SMF
• Tests mit anderen Zeichensätzen (ggf. entsprechende Titelsätze vorhanden?)
• Camel bietet JMX Monitoring, dies kann z.B. mit dem Nagios der VZG zusammenarbeiten
• Überwachung der Konfiguration auf Änderungen
• Handling von Mahnungsmails

Mögliche Verbesserungen (nicht geplant)

• Parser könnten auch in Java generiert werden, bzw. müssten nicht jedes mal neu generiert werden – Performance Optimierung
• Oder Parsen und Layouten in einem Stylesheet
• Datenbankabfrage zeitgesteuert (z.b. für Benachrichtigungen - mit Hilfe von Quartz)

Layouts grafisch gestalten (one more thing...)

• Perspektivisch könnten Layouts auch grafisch gestaltet werden
• Vorlagen können in Open / Libre Office erstellt werden und dann mit XSLT in XSL-FO verwandelt werden
• Open / Libre Office bietet die Möglichkeit grafische Elemente zu annotieren
• In diesen Annotationen können die Namen der gewünschten Felder, Funktionsaufrufe und einfache Kontrollstrukturen (if, then, else) hinterlegt werden

Technische Anforderungen

• Derzeit ist im XSL-FO Stylesheet Logik hinterlegt diese muss in das ODF Template überführt werden können.
  • Schriftgröße anpassen bei langen Signaturen ✔
  • Anzeige des Nutzernamens basierend auf Abholbereich und Nutzertyp ✔ (fast ✖, erfordert überlappende Definitionen mit Bedingungen)
  • Seitenverhältnisse je nach Ausgabeformat ✖
  • String Bearbeitung für die Anonymisierung ✔
• Lösung: Überführung in XPath Ausdrücke die zur Laufzeit des generierten XSL-FO Templates evaluiert werden
• Mapping der Designvorgaben von Open / Libre Office auf XSL-FO Ausdrücke
• Einträge können öfter in einem Layout benutzt werden, nur das erste Vorkommen kann weiter verarbeitet werden.

Libre Office – Textboxen annotieren