Dieser Blogbeitrag richtet sich an alle, die daran interessiert sind, einen Einblick in einige der automatisierten IT-Prozesse zu erhalten, die Ihre Zeitungen oder Zeitschriften hinter den Mauern von Visiolink durchlaufen. Viel Spaß beim Lesen!
Stark vereinfacht lässt sich Visiolinks SaaS Kern-Backend auf drei Bereiche reduzieren:
- Automatische Sammlung der richtigen PDF-Dateien vom FTP-Account des Herausgebers zum richtigen Zeitpunkt und Verschieben dieser Dateien in die Warteschlange zur Weiterverarbeitung.
- Warteschlangenbasierte Konvertierung der PDF-Dateien in zwei andere Formate für Internet bzw. Smartphones/Tablet-PCs.
- Viele verschiedene Webservices, z. B. Web- und Geräte-Clients, benötigen diese, um Daten daraus abzurufen.
Ich werde mich hier auf den ersten Bereich konzentrieren, der in der letzten Zeit eine vollständige Umprogrammierung durchlaufen hat. Da keine Publikation einer anderen gleicht, gilt dies häufig gleichermaßen für ihre Deadlines, Freigabezeitpunkte und den Output der redaktionellen Systeme. Der Grund für die Umprogrammierung besteht gerade in neuen Anforderungen für die Freigabezeitpunkte sowie darin, dass es mehrere Versionen derselben Ausgabe geben kann.
Intern in unserer Welt wird dieses System als „Normalizer“ bezeichnet. Aber was wird da eigentlich normalisiert? Hier die Erklärung: Unsere Systeme setzen voraus, dass die Herausgeber einseitige PDF-Dateien in ihr FTP-Account hochladen. All diese Einzelseiten müssen zu einer Publikation zusammengestellt und für die Weiterverarbeitung in eine Warteschlange verschoben werden, bevor diese in unseren AUTHENTIC- und DYNAMIC-Lösungen im Internet, auf Smartphones und Tablet-PCs angezeigt werden können, aber wie funktioniert das?
Eine Publikation besteht natürlich aus verschiedenen Seiten, und jede Seite kann zu einer Sektion gehören. Darüber hinaus hat eine Publikation außerdem ein Veröffentlichungsdatum, da Dateien für viele verschiedene Datumsangaben vorliegen können. Aus diesem Grund muss jede PDF-Datei mindestens angeben, zu welcher Seite und zu welchem Datum sie gehört. Wenn Publikationen über mehrere Sektionen verfügen, muss diese ebenfalls angegeben werden. Außerdem kann jede Seite in verschiedenen Versionen vorhanden sein, wenn die Redaktion Inhalte im Verlauf des Veröffentlichungszeitraumes ändern muss. All diese Informationen müssen ganz einfach Teil der Dateinamen sein.
Da die Benennung der Dateien einschließlich Datumsformat sich für jeden Herausgeber unterscheidet, erfolgt die Verarbeitung mit verschiedenen für jeden Kunden individuellen regulären Ausdrücken; wobei die einzelnen Inhalte für jedes der vorgeschriebenen Elemente und ggf. eine fest definierte Sektion gruppiert werden. Darüber hinaus kann man eine Toleranzschwelle für die Anzahl fehlender Seiten innerhalb einer Sektion, den Freigabezeitpunkt und andere Details definieren.
In der „guten alten Zeit“ war alles einfacher
Zu Anbeginn der Zeiten bestand die einzige Möglichkeit, eine abgeschlossene Dateisammlung auszulösen, darin, einen so genannten „XML-Trigger“ hochzuladen. Diese XML-Datei musste das Veröffentlichungsdatum (dasselbe Datum wie im Namen der PDF-Dateien), einen Ausgabezeitpunkt und eine Version enthalten. Diese Datei musste häufig manuell erstellt und hochgeladen werden, was oft zu Unklarheiten und Fehlern führte. Auch heute ist diese Form der Fertigstellung der Dateizusammenstellung weiterhin für diejenigen aktiv, die dieses Verfahren wünschen.
In dem Maß, in dem die Anzahl der Ausgaben in unseren Systemen zunahm, wuchsen auch die Anforderungen an diese. Die wichtigste Anforderung war eine automatische Sammlung von Dateien ab einem bestimmten Zeitpunkt des Tages ohne XML-Trigger. Diese Funktion wurde ergänzt und funktionierte über einen langen Zeitraum reibungslos.
All dies war jedoch, bevor in der Branche die Anforderung einer „Early Release“ entstand, also einer Möglichkeit, Publikationen am Tag/Abend vor dem Veröffentlichungsdatum freigeben zu können. Daher war das System so konstruiert, dass ausschließlich Dateien desselben Datums wie der Ausführungszeitpunkt gesammelt werden; es wurde also nicht zwischen Verarbeitungs- und Veröffentlichungsdatum unterschieden. Beispielsweise wurden im Fall einer Abendzeitung bei einer ausnahmsweise leicht verspäteten Ausgabe nach Mitternacht die Dateien nicht automatisch gesammelt. Darüber hinaus war es ebenfalls nicht möglich, eine Zeitung mit aktualisierten Seiten neu zu erstellen, wenn diese bereits einmal erstellt worden war. Beide Probleme konnte man selbstverständlich manuell durch Aufrufen unserer Administrationsoberfläche und erneutem Erzwingen einer Zusammenstellung eines bestimmten Datums beheben. Aber wir hatten schon immer das Ziel, eine Automatisierung der gesamten Verarbeitung zu erreichen; wenn also neue Anforderungen in der Branche entstehen, möchten wir in der Lage sein, diese in unsere automatische Verarbeitung zu integrieren.
Mit der Zeit entstand also die Anforderung einer „Early Release“ in der Zeitungsbranche. Diese Anforderung konnten wir problemlos mit dem oben genannten XML-Trigger lösen. Der Vorteil eines XML-Triggers besteht nämlich darin, dass der Kunde zu 100 % kontrolliert, wann die Dateien zusammengestellt werden. Gleichzeitig kann der Kunde außerdem eine Veröffentlichung mithilfe des XML-Triggers erneut durchführen. Wie erwähnt ist der XML-Trigger jedoch auch mit einigen Nachteilen verbunden, und da immer mehr Kunden eine automatische „Early Release“-Funktion und Neuerstellungen wünschten, entschieden wir uns für die Entwicklung eines neuen Normalizers.
In den „noch besseren neuen Zeiten“ wurde es komplexer
Aus diesem Grund wurde der Begriff „File set“ („Dateisatz“) für den neuen Normalizer eingeführt. Kurz gesagt besteht ein Dateisatz aus allen Dateien für ein bestimmtes Datum, die Kandidaten für die Auswahl darstellen. Die erste große Aufgabe bei einer Normalizer-Ausführung besteht daher darin, alle Dateien im FTP-Account des Kunden zu finden, diese mit den Dateinamenkonventionen abzugleichen und nach Datum zu gruppieren.
Bei jeder Ausführung bleiben Informationen zu jedem einzelnen bekannten Dateisatz erhalten, so dass wir später ermitteln können, ob ein Dateisatz seit der letzten Ausführung geändert wurde. Wenn dies der Fall ist und die sonstige Konfiguration es zulässt, wird der Dateisatz zusammengestellt und zur Weiterverarbeitung in die Warteschlange verschoben. Die Zusammenstellungskriterien passen jedoch nicht perfekt, denn ein Dateisatz wird nicht zusammengestellt, wenn eine Datei gerade erst hochgeladen oder gelöscht wurde. Dies ist eine Sicherheitsfunktion, mit der wir verhindern, dass ein Dateisatz zusammengestellt wird, während der Kunde gerade Dateien hochlädt oder löscht. Daher warten wir einige Zeit mit der Zusammenstellung der Dateien, bis über einen gewissen Zeitraum keine Änderungen erfolgt sind.
Ohne zu sehr ins Detail gehen zu wollen, ist es mit diesen Dateisatzinformationen und der Zusammenstellungskonfiguration relativ einfach, für jedes einzelne Datum herauszufinden, ob Dateien für dieses Datum zu sammeln sind, wenn Änderungen in den Dateien im FTP-Account erfolgt sind.
Mit der Entscheidung, das System neu zu programmieren, gingen auch verschiedene Ideen für weitere Verbesserungen einher, die ebenfalls implementiert wurden. Zu den wichtigsten Verbesserungen gehören:
- Statt Dateien ausschließlich am Tag und Abend vor dem Veröffentlichungsdatum sammeln zu können, wurde das System so allgemein programmiert, dass es möglich ist, eine bestimmte Anzahl Tage vor bzw. nach dem Ausführungszeitpunkt zu konfigurieren, an denen Dateien für eine Ausgabe gesammelt werden können. Insbesondere die Anzahl Tage in der Zukunft ist sehr hilfreich für Zeitschriften, die lange Zeit vor ihrer Freigabe bereits fertiggestellt sind. Die Anzahl Tage in der Vergangenheit kann für Neuerstellungen verwendet werden. Später haben wir außerdem eine genaue Uhrzeit für diese Grenze hinzugefügt, die dem Zeitpunkt der Deadline der Ausgabe entspricht, bis zu dem wir alle Dateien erhalten haben müssen.
- Bevor ausschließlich Dateien zwischen einem bestimmten Tageszeitpunkt und Mitternacht automatisch gesammelt werden konnten, wurde es ermöglicht, einen oder mehrere willkürliche Tageszeiträume zu konfigurieren. Für viele Ausgaben wird man das System lediglich so programmieren, dass die Dateien rund um die Uhr gesammelt werden, so dass keine manuelle Ausführung erforderlich ist.
- Zuvor waren lediglich Log-Informationen der letzten Ausführung zugänglich. Mit dem neuen System sind alle kürzlich erstellen Logs verfügbar, so dass man auf Informationen zu jeder einzelnen Ausführung zugreifen kann. Auf diese Weise können wir beispielsweise das Log für die letzte Ausführung und für die letzte Ausführung, bei der eine Dateisammlung über die Administrationsoberfläche erfolgte, anzeigen.
- Wir arbeiten ja mit wichtigen journalistischen Inhalten, und das bedeutet, dass ein Dateisatz als fehlerhaft betrachtet wird, wenn die Titelseite fehlt. Darüber hinaus kann man konfigurieren, dass das Fehlen von Sektionstitelseiten nicht zulässig ist. Wird die Verarbeitung eines Dateisatzes vorgesehen, werden die fehlenden Seiten später in der Verarbeitung durch Leerseiten ersetzt, so dass für den Nutzer, u. a. bei einer Coverflow-Darstellung, kein optimales Leseerlebnis erreicht wird. Das System weiß ja schließlich generell nicht, wie viele Seiten eine bestimmte Publikation umfassen muss, und daher haben wir keine Möglichkeit, eine Datensammlung zu stoppen, bei der Seiten/Dateien am Ende einer Sektion fehlen. Aus diesem Grund ist es ebenfalls möglich, zu konfigurieren, ob die Anzahl der Seiten in einer Sektion durch zwei oder vier teilbar sein soll, was in der Regel eine sinnvolle Zahl für ursprünglich physische Publikationen ist. All diese Konfigurationsmöglichkeiten tragen dazu bei, dass der einzelne Herausgeber die Möglichkeit hat, bei seinen digitalen Ausgaben eine hohe Qualität ohne Fehler und Mängel zu erreichen.
Blickwinkel
Dies war nur eine oberflächliche Darstellung des neuen Normalizer-Systems, und natürlich gibt es eine Vielzahl kleiner Details, deren Entwicklung herausfordernd und spannend war. Aber wir sind davon überzeugt, dass das Produkt sowohl unseren Kunden als auch uns selbst einen großen Mehrwert bieten kann. Derzeit arbeiten wir daran, die vielen Ausgaben in den neuen Normalizer zu übertragen. Aber auch wenn wir der Auffassung sind, dass wir die meisten der heute in der Branche bestehenden Anforderungen erfüllen, werden wir in fünf Jahren mit Sicherheit wieder klüger geworden sein, genau wie es heute der Fall ist.
