• Perl Success Storys - Erfolge mit Perl
• NAME
• Einführung
• Projektbeschreibung
• Was bisher geschah
• Vorhandene EDV-Landschaft
• Das Ziel: ``e-form Redakteur''
• Die grundsätzliche Lösungsidee ...
• Einzelne Schwerpunkte und CPAN-Module
• Betriebssystem und Datenbank
• Intranetlösung mit mod perl
• Konsequente Objektorientierung
• Datenbankanbindung
• Template-Toolkit
• Silbentrennung nach TeX
• Configfiles, Logfiles, Lockfiles
• Datumskalkulation
• Stammdaten-Migration
• DBF-Files
• ZIP-Files
• FDF-Files
• Mailempfang und Mailversand
• Installation mit Automake/Autoconf
• Codeästhetik vs. Obfuscated Perl Code
• Non-Perl Goodies
• Zusammenfassung
• Zahlen
• Autor

EfRed::PerlSuccessStory::De - e-form Redakteur

Im Folgenden beschreibe ich ein Projekt, in welchem Perl praktisch allumfassend zum Einsatz kommt. Es gibt eine etwas ausführlichere Einleitung für das Verständnis des Projektkontextes und anschließend einen Überblick über technische Aspekte mit den verwendeten CPAN-Modulen.

Die Sächsisches Druck- und Verlagshaus AG (SDV) produziert wöchentlich das Sächsische Ausschreibungsblatt, eine Zeitschrift mit Bekanntmachungstexten für Ausschreibungen. Es erscheint in Papierform und in einer Online-Variante.

Herkömmlich gingen die zu veröffentlichenden Texte von ausschreibenden Stellen per Fax ein, welche im SDV manuell erfasst, Korrektur gelesen, gesetzt und gedruckt wurden.

Um die zunehmende elektronische Lieferung in verschiedensten Dateiformaten kontrollieren zu können, wurde in vorangegangenen Projekten eine einheitliche Software e-form für Ausschreibungen erstellt, mit welcher die Bekanntmachungstexte durch die Auftraggeber DIN-gerecht in Formularen erfasst und in einem einheitlichen Format (als XML und Acrobat FDF) an das SDV übertragen werden.

Die ursprünglich nur für Windows verfügbare Software e-form wurde durch eine plattformunabhängige Online-Variante e-form/online ergänzt (ebenfalls eine Perl-Lösung). Der Lieferweg für mit e-form/online erzeugte Bekanntmachungstexte ist in den Prozess des ausschreibungs-abc integriert, einer bundesweiten Ausschreibungsplattform für verschiedene Landesausschreibungsblätter und Staatsanzeiger. Über das ausschreibungs-abc werden die Bekanntmachungstexte in ZIP-Files verpackt, in denen neben dem Bekanntmachungstext weitere Metainformationen verpackt sind.

Nachdem sich der elektronische Lieferweg in diesen zwei Varianten gegenüber dem herkömmlichen Fax-Weg etabliert hatte, galt es nun, den internen Verarbeitungsprozess im SDV effizient zu gestalten.

Die vorhandene EDV-Landschaft bestand aus einer gewachsenen Infrastruktur, die vordergründig den herkömmlichen Papiereingang behandelt und durch daran angelagerte Teilprozesse zum Teil elektronisch unterstützt wurde. Primär wurden Texte aus Fax- und Email-Eingängen manuell erfasst, Texte ausgedruckt, auf Papier Korrektur gelesen, elektronisch korrigiert und gesetzt.

Sekundär wurden in zwei verschiedenen weiteren Programmen Daten zur Weiterverarbeitung erfasst:

In einem DOS-Programm wurden Adressen für Belegexemplarempfänger gepflegt, aus denen Versandetiketten gedruckt werden. In einer MS-Access-Lösung wurden die Bekanntmachungstexte inhaltlich deskribiert, um in der Onlinefassung des Ausschreibungsblattes thematisch gefilterte Abonnements für Interessenten zuzustellen. Beide Lösungen produzierten DBF-Dateien.

Eines der Hauptprobleme neben dem Papieraufwand während der Korrektur war bisher, an verschiedensten Stellen manuelle Arbeiten ausführen zu müssen, um die vorhandenen elektronischen Teilprozesse zu verknüpfen: Emails empfangen, Attachments speichern, Dateien downloaden, ZIP-Files öffnen, speichern, drucken, Daten an verschiedenen Stellen (teilweise redundant) eingeben, Dateien speichern, an anderer Stelle wieder einlesen usw.

Der gesamte interne Prozess, beginnend bei den papierbasierten und elektronischen Eingängen bis zum Satz, sollte homogen und medienbruchfrei gemacht werden.

Das Zusammenspiel der verschiedenen am Gesamtprozess beteiligten Mitarbeiterinnen für Texterfassung, Korrektur, Inhaltsredaktion, Satz und Belegexemplarversand sollte dabei möglichst einfach erfolgen.

Weiterhin sollte die Entgegennahme elektronischer Eingänge automatisiert ablaufen und es sollten Bestätigungsmails versendet werden. Die DOS-Anwendung und die MS-Access-Lösung sollten migriert, die erzeugten Dateiformate jedoch für externe Weiterbearbeitung beibehalten werden.

... sieht wie folgt aus:

Das System besteht aus zwei Hauptschwerpunkten.

Der unsichtbare Teil des Systems ist ein Framework von crontab-gesteuerten Programmen. Diese überwachen regelmäßig Email-Eingänge, Verzeichnisse und Dateien, um sie schrittweise von einem Format ins nächste zu transformieren. Die Transformation der Eingänge erfolgt mehrstufig, um die Besonderheiten von Emails, ZIP-Files oder manuell erfassten Dateien zunächst spezifisch zu behandeln und in folgenden Schritten zunehmend zu vereinheitlichen.

Der sichtbare Teil der Lösung ist eine Intranetlösung. In ihr werden sämtliche Auftragseingänge und Metainformationen bearbeitet. Unter anderem wurden hier die Adressverwaltung des DOS-Programmes und die Inhaltsdeskribierung aus der MS-Access-Lösung nachgebaut. Weiterhin erfolgt in der Intranetanwendung das Setzen und Überwachen von zustandsgesteuerten Teilprozessen wie Erfassung und Korrektur. Die GUI dient zur Bearbeitung von Daten und als Auskunftswerkzeug bei telefonischen Rückfragen, die einen beträchtlichen Teil neben der redaktionellen Arbeit ausmachen.

Die Bearbeitung der eigentlichen Bekanntmachungstexte erfolgt mit Texteditoren auf den exportierten Sambafreigaben. Das bietet den Vorteil, dass für Textbearbeiterinnen und Korrektorinnen keine Schulungen über die Intranetlösung notwendig sind und die Textbearbeitung selbst mit besseren Editoren möglich ist, als es in einer Webanwendung möglich wäre.

Dateien zur Bearbeitung werden automatisch auf Sambafreigaben bereitgestellt, die Bearbeiter editieren sie und legen sie anschließend in anderen Freigaben ab, von wo sie automatisch wieder ins das System importiert werden.

Sämtliche Steuerdaten zu bearbeitender Dateien werden im Text selbst XML-markiert, um von Äußerlichkeiten wie falschen Dateinamen unabhängig zu sein. Texterfasserinnen und Korrektorinnen können wie gewohnt unter Windows arbeiten. Sie müssen nur Ort und Zweck der Sambafreigaben kennen und eine minimale XML-Markierung um den zu bearbeitenden Text respektieren.

Die korrekte Reihenfolge der Bearbeitung wird zustandsgesteuert sichergestellt. Ist ein Ausschreibungsblatt komplett bearbeitet und sind alle Texte erfasst und deskribiert, so werden nach expliziter Freigabe in der Intranetlösung ein aufbereiteter Text für die Setzer und DBF-Dateien für Etikettendruck und Online-Ausgabe erzeugt, Dateien in ZIP-Files gebündelt und wiederum auf Sambafreigaben zur Weiterverarbeitung abgelegt oder per Mail versendet.

Im Folgenden werden die wichtigsten technischen Aspekte der Lösung dargestellt.

Die gesamte Software läuft auf einem dedizierten Server (Debian GNU/Linux 3.0 ``woody''). Dieser übernimmt die gesamte Funktionalität für Email-Entgegennahme und -versand, stellt im Windowsnetzwerk via Samba Verzeichnisse bereit und hostet die Intranetlösung. Die verwendete Datenbank ist Oracle 9i unter Windows2000.

Die Intranetapplikation ist eine mod_perl-Anwendung. Es wird ein Apache 1.3 mit mod_perl 1.26 verwendet. Die URLs werden mit Apache::Dispatch und einer eigenen Dispatch-Klasse auf Klassen gemappt.

Die gesamte Anwendung ist durchgängig objektorientiert. Jede URL ist eine Klasse, jeder Request instanziiert ein Objekt. Alle Klassen sind von einer gemeinsamen Klasse abgeleitet, welche Apache::Request kapselt, transparentes Sessionhandling (via Apache::Session) bereitstellt und etwas Requestmagie betreibt. Nicht projektspezifische Aufgaben wurden in der Vererbungshierarchie diszipliniert von projektspezifischen getrennt, um sie in anderen Projekten wiederverwenden zu können.

Ein eigenes OO-Framework wurde auch um DBI gebaut. Jede Datenbanktabelle hat eine zugehörige Klasse, alle wiederverwendbaren Teile sind auf die Vererbungshierarchie verteilt. Aus den Eigenschaften einer Tabelle, im wesentlichen Spalten und Typen, werden dynamisch Standardstatements für INSERT, UPDATE und SELECT erzeugt. Spezialfälle werden durch Überladen von Methoden realisiert, meist für WHERE-Klauseln.

Die durchgängige Kapselung jeglicher Funktionalität in Klassen bietet den Vorteil, die gleichen Komponenten sowohl in der Web-Applikation unter mod_perl als auch in den crontab-gesteuerten Programmen und in Testprogrammen verwenden zu können.

Wie schon angedeutet, verwenden wir für den Zugriff auf die Oracle-9i-Datenbank DBI mit DBD::Oracle. Wir verwenden außerdem Apache::DBI für gepoolte, persistente Connections, was einen erheblichen Geschwindigkeitsvorteil bringt.

Das berühmte Template-Toolkit. Wir haben es als leistungsfähigen Makroprozessor verwendet, um die in strukturiertem XML vorliegenden Daten der Bekanntmachungstexte in einen flachen, lesbaren Bekanntmachungstext zu konvertieren. Hierbei werden die ursprünglich in Formularen erfassten Werte (ca. 150 bis 250 Einzelwerte je nach Formulartyp) zu einem Gesamttext kombiniert.

Die Logik in den Templates kümmert sich z.B. um die Behandlung von nicht vorhandenen Werten (z.B. in kommaseparierten Listen, um nicht leere Kommafolgen zu erzeugen) und um die Erzeugung von Zeilenumbrüchen und Zeileneinzug. Etwas trickreich gestaltete sich die Behandlung von Whitespace bei Beibehaltung der Lesbarkeit der Makros.

Die Templates können parametrisierbar in zwei verschiedenen Modi verwendet werden, zum einen als Textvorschau mit reinem Text und zum anderen mit automatischer Erzeugung von XML-Markierungen und geändertem Zeilenumbruch/-einzug für die spätere Verwendung im Satzprogramm, welches eigene Umbrüche und Einzüge erzeugt. Die vielen verfügbaren Filtermethoden machen die Arbeit mit dem Template-Toolkit gegenüber einem herkömmlichen Makroprozessor wie m4 sehr viel einfacher.

Silbentrennung nach TeX

Ein interessantes Problem bei der Migration der DOS-Anwendung war die Übernahme des Adressdatenbestandes. Die Adressen werden verwendet, um Etiketten für den Belegexemplarversand zu drucken. Auf den kleinen Etiketten ist jedoch eine Silbentrennung notwendig. In der DOS-Anwendung lagen die Adressen bereits in Einzelzeilen zerlegt vor, was uns aber nicht gefiel. Wir haben daher bei der Datenmigration die fixe Silbentrennung beseitigt und suchten nach einer Methode, dynamisch Silben zu trennen.

Ein Programm, das Silbentrennung beherrscht, ist das Satzprogramm TeX. Die Regeln für die Silbentrennung sind in einer TeX-Datei gekapselt, deren Syntax und Prinzip sehr kompliziert wirkt und vermutlich auch ist. Zum Glück gibt es natürlich auch dafür ein Modul auf CPAN, welches unter Verwendung dieser Datei Silbentrennung betreibt.

Der Datenbestand ist jetzt frei von solchen Besonderheiten und die Silbentrennung erfolgt dynamisch mittels TeX::Hyphen erst bei der Erzeugung der Etikettendatei.

Viele Eigenschaften unserer Applikation lassen sich in einem Configfile konfigurieren. Dabei verwenden wir ein Format wie in der Apache httpd.conf, welches durch das CPAN-Modul Config::General geparst werden kann. Das Configfile selbst wird dynamisch in einem Autoconf-getriebenen Prozess erstellt.

In unserem Framework aus automatisch ablaufenden Prozessen sind natürlich Logfiles wichtig. Wir verwenden hierfür das CPAN-Modul Log::LogLite.

Um verschiedenste Arten von Prozessüberschneidungen zu vermeiden, benutzen wir Locking mittels LockFile::Simple.

Wir rechnen an mehreren Stellen mit Datumsangaben. Häufig zur Plausibilitätsprüfung und um eingehende Bekanntmachungstexte entsprechend dem angegebenen Veröffentlichungsdatum einer Ausgabewoche zuzuordnen, unter Beachtung von allerlei Nebenbedingungen wie Erscheinungsdatum, Redaktionsschluss und Standardwerten für fehlende Angaben. Einiges an Arbeit nimmt uns hier das Modul Date::Calc ab.

Eine Aufgabe während des Projektes bestand in der Übernahme vorhandener Stammdaten. Diese wurden aus den Anwendungen als DBF-Files exportiert und mit Perl-Skripts unter Verwendung von XBase in unsere Datenbank gelesen.

Herkömmlich wurden mit der DOS- und der MS-Access-Anwendung DBF-Dateien (dBase) erzeugt, die zur Weiterverarbeitung extern weitergegeben wurden. Wir haben beide Anwendungen in unserer Webapplikation nachgebaut und den bisher redundanten Datenbestand vereinheitlicht. Damit die externen nachfolgenden Prozesse ``den Unterschied nicht merken'', erzeugen wir mittels XBase DBF-Dateien im gleichen Format wie bisher.

Wir schälen in mehreren Schritten unsere XML-Files aus ineinander verschachtelten Zipfiles heraus. Die Zlib macht es möglich und Archive::Zip besonders einfach.

Ein Teil der eingehenden Daten kommt als Acrobat-FDF-Attachments an, da die Software e-form für Ausschreibungen mit Adobe Acrobat arbeitet. (Neuere Versionen von e-form erzeugen neben FDF zusätzlich gleich XML.) Für die Arbeit mit FDF-Dateien stellt Adobe ein FDF-Toolkit bereit, welches wir zum Extrahieren der Formularinhalte verwenden.

Ein beträchtlicher Teil des Systems beschäftigt sich mit der automatischen Entgegennahme und Zerlegung von Emails. Wir lesen mit Net::POP3 und zerlegen sie mit MIME::Parser, um an die Attachments zu gelangen.

Für den Versand von Bestätigungsemails und die Weiterleitung von ``unverständlichen'' Mails verwenden wir Mail::Sender und Net::SMTP.

Obwohl es MakeMaker gibt, installieren wir unser komplettes System mit Automake/Autoconf, da wir dies bereits für die Ermittlung der Konfiguration und eine große Menge von zu installierenden Nicht-Perl-Dateien verwenden. Perl-spezifische Informationen ermitteln wir im configure-Skript mit dem Perl-Modul Config.

Perl hat den nicht ganz unberechtigten Ruf ``write-only''-Code zu fördern. Wir haben bewusst darauf verzichtet, uns gegenseitig mit unübersichtlichen kryptischen Perl-Fragmenten zu beeindrucken. Nichttriviale reguläre Ausdrücke oder ähnliches haben wir in Subfunctions mit sinnvollen Namen gekapselt, Klassennamen und Dateinamen korrelieren und der Quellcode ist ästhetisch und lesbar formatiert.

Die Intranetlösung muss nicht mehrere tausend Requests pro Sekunde schaffen; hohe Strukturierung durch Verteilung auf viele kleine Funktionen und eine durchgängige Objektorientierung sind unter diesen Umständen praktisch Pflicht.

Interessant neben dem vielen Perl ist vielleicht noch der Einsatz von GNU Emacs für die Textbearbeitung unter Windows. Hierfür wurde ein eigener Emacs-Major-Mode geschrieben, der die Formatrichtlinien für die Bekanntmachungstexte kennt, XML-markierte Inhalte hervorhebt und zugeschnittene Menüs und Keybindings für diverse Makros anbietet.

Mit dem cua-mode, der das Cut/Copy/Paste auf die typischen Windows-Tasten Ctrl-X/C/V mappt, können die Textbearbeiter wie in anderen Windows-Editoren gewohnt arbeiten, ohne sich umstellen zu müssen.

Wir konnten die gleiche Programmiersprache für alle Aspekte des Projektes verwenden; via mod_perl für die Webapplikation, als ``normale'' Programmiersprache für die Cron-Jobs, als ``Glue'' zwischen vorhandenen Lösungen und für Einmal-Tools, um im Projekt Dateien zu migrieren oder Code aufzubereiten.

Trotz bewusster Vermeidung von obfuscated Perl-Code, haben wir mit Perl sehr viel mehr Probleme mit sehr viel weniger Code gelöst, zusätzlich unterstützt durch die große Auswahl an fertigen CPAN-Modulen.

Mit Perl haben wir uns komplett auf die projektspezifischen Aufgaben konzentrieren können, ohne vor technologischen Einschränkungen zittern zu müssen.

* 300

Bekanntmachungstexte durchschnittlich pro Woche.

* 140

Perl-Klassen.

* 20.000

Zeilen unter dem Meer, d.h. non-obfuscated Perl Code.

* 2600

Zeilen obfuscated Template-Toolkit Makro Carnage.

(c) 2003 Steffen Schwigon
webit! Gesellschaft für neue Medien mbH.

Siehe Perl Erfolgs Stories, Steffen Schwigon