Version: GSB 7LinkCheckWorkflow

Anforderungen

Externe Links sind Links auf Inhalte, die nicht mit dem CMS erstellt und verwaltet werden. Zur Überwachung und Konsistenzsicherung von externen Links stellt CoreMedia nur rudimentäre Funktionalitäten bereit. Aus diesem Grund sollen externe Links mit Hilfe von Dokumenttypen so erfasst werden, dass eine Wiederverwendung dieser Links durch die Redakteure keine Neueingabe der URL erzwingt. Auf diese Weise können externe Links einfach, schnell und automatisch überprüft und zentral gepflegt werden. Sollte eine Zieladresse nicht mehr existieren, kann der zuständige Redakteur eine neue URL eingeben, die automatisch im ganzen Projekt korrigiert wird. So kann die Wahrscheinlichkeit minimiert werden, dass externe Links auf ungültige Seiten verweisen. Zur Verwaltung von externen Links wurden im Abschnitten „Externe Links“ und „Linkdatenbank für externe Links“ der Anforderungsspezifikation die folgenden Anforderungen formuliert:

• Implementation einer Link-Datenbanken auf Basis eines entsprechenden Dokumenttyps für externe Links.
• Automatische Überprüfung, ob die in der Datenbank enthalten Zieladresse der gespeicherten Links noch existieren.
• Die Überprüfungen müssen wahlweise durch den Administrator und auch zeitgesteuert gestartet werden können.
• Automatische Benachrichtigung des zuständigen Redakteurs, falls die Zieladresse eines gespeicherten Links auf eine ungültige Seite verweist.
• Sollte eine Zieladresse nicht mehr existieren, muss der zuständige Redakteur eine neue URL eingeben, die automatisch im gesamten Webauftritt korrigiert wird.

Eingesetzte Komponenten

Zur Verwaltung externer Links können die Komponenten Produktionsserver und Workflowserver des CoreMedia CMS eingesetzt werden.

Produktionsserver

Der Produktionsserver ist die Kernkomponente des CMS zur Erstellung und Verwaltung von multimedialen Inhalten. Dokumente werden in einer hierarchischen Struktur abgelegt, ähnlich wie in einem Filesystem. Während des Publikationsprozesses können Konsistenzprüfungen mit Hilfe von Validatoren durchgeführt werden. So werden bspw. standardmäßig interne Links auf Konsistenz überprüft. Dadurch werden tote interne Links vermieden. Konsistenzprüfungen können ebenfalls ausgeführt werden, wenn Dokumente gelöscht werden. Gleiches gilt für das Umbenennen und Verschieben von Dokumenten oder durch andere vom Benutzer durchgeführte Aktionen. Eine Überprüfung externer Links wird standardmäßig nicht durchgeführt. Sie kann aber durch zusätzliche Implementierungen integriert werden.

Workflowserver

Für das CoreMedia CMS wurde ein eigener Workflowserver entwickelt. Dieser ermöglicht es, kürzere oder mehrstufige und parallelisierte Workflows zu modellieren und zu verwalten. Die flexible Modellierung von Workflows erlaubt neben der Verwendung der Ba-sisschritte, Sequenz, Schleife, Entscheidung, Parallelisierung und Synchronisation, auch die Einbindung von Start-, End- und Aktions-Routinen. Diese können frei in Java entwickelt werden und so auch Drittsysteme anbinden oder Benach-richtigungen auslösen (z.B. Email). Dadurch können bspw. tote externe Links automatisiert durch einen Workflow den zuständigen Redakteuren zur Korrektur vorgelegt werden.

Systemvorraussetzungen

Ein Mailserver muss per SMTP erreichbar sein. Die entsprechenden Ports für HTTP und HTTPS müssen in einer möglichen Firewall freigeschaltet sein. Die entsprechenden Workflows (siehe nächstes Kapitel) müssen hochgeladen worden sein.

Workflows

Der Linkchecker besteht aus mehreren Workflows. Es ist sicherzustellen das folgende Workflows hochgeladen worden sind, bevor Linkchecker in Betrieb genommen wird:

• CheckExternalLinksSubWorkflow (check-links-sub.xml)
• BorkenUriSubWorkflow (broken-uri-sub.xml)
• ScheduledCheckExternalLinksSubWorkflow (scheduled-check-links-sub.xml)

LinkCheckQueryExternalManager

Dieser Daemon wurde im Rahmen des Projektes entwickelt und läuft als ExternalManager Prozeß auf dem Workflowserver ab. Er nimmt von Workflows sogenannte Tickets mit statischen bzw. dynamischen Queries entgegen und führt diese aus.

LinkCheckExternalManager

Dieser Daemon wurde im Rahmen des Projektes entwickelt und läuft als ExternalManager Prozeß auf dem Workflowserver ab. Er nimmt von Workflows sogenannte Tickets mit den zu testenden URLs entgegen und startet nach Bedarf eine angemessene Anzahl von Threads zur Abarbeitung der Linkchecks. Ist ein Ticket abgearbeitet, wird der wartende Workflow informiert und fortgesetzt.

Konzeption

Auf dem Produktionsserver befindet sich die Eingabemaske für die Erfassung der externen Links, welche über den Editor des Redakteurs aufgerufen werden kann. Um eine Verlinkung auf einen externen URL in Inhalten zu integrieren, muss zuerst der externe Link erfasst werden oder schon vorhanden sein. Anschließend kann dann auf das Objekt verwiesen werden, das den externen Link repräsentiert.

Überprüfung externer Links während der Erfassung

Neu angelegte externe Links können während der Erfassung auf Vorhandensein überprüft werden. Hierfür wird ein Workflow „check-external-links“ (Standardname: „Externe Links prüfen“) implementiert, der zur Überprüfung der URL mit dem neu angelegten Dokument gestartet wird. Kann der externe Link innerhalb einer konfigurierbaren Zeit nicht im Web gefunden werden, erhält der Redakteur jeweils einen Workflow zur Überarbeitung („broken-uri-workflow“.)

Überprüfung eingegebener externer Links im Batchmodus

Der Workflowserver kann automatisiert eine wiederholte Überprüfung aller angelegten und publizierten externen Links vornehmen. Dies wird durch den Workflow „scheduled-check-external-links“ (Standardbezeichnung: „Zeitlich gesteuerter Linkchecker“) geleistet, der pro Mandant permanent im Hintergrund laufen kann und auf seine nächste Ausführung wartet. Während der Ausführung wird z.B. ein bestimmter Ordner, in dem sich die ExternalLink Dokumente befinden, nach externen URLs durchsucht und diese getestet. Die Menge der zu testenden Dokumente wird über die beim Workflow-Start übergebene Query definiert. Auch hierbei sind Timeouts bei der Überprüfung konfigurierbar. Webseiten oder komplette Websites können temporär nicht vorhanden sein, da sie bspw. zu Wartungsarbeiten abgeschaltet wurden oder Server ausgefallen sind. Deshalb macht es, im Gegensatz zur Überprüfung externer Links während der Publikation, im Batchmodus Sinn, eine Anzahl der Überprüfungsversuche mit einer Wartezeit zwischen den einzelnen Versuchen zu konfigurieren. Jede fehlerhafte URI wird mit der Fehlerbeschreibung vermerkt. Die Liste der fehlerhaften URIs wird nach dem kompletten Durchlauf an konfigurierbare E-Mail-Empfänger geschickt. Es existiert für jeden Mandanten ein Verzeichnis unter den Redaktionsdefinitionen mit dem Namen „linkcheck“, in welchen zwei ConfigString-Dokumente den Absender und die Empfänger der Ergebnis-E-Mail definieren („mailSender“ und „mailReceivers“.) So kann für jeden Mandanten eine geeignete Gruppe von Zuständigen gewählt werden, welche die Korrektur ggf. weiter delegieren können.

Technische Umsetzung

LinkCheckQueryExternalManager

Package: de.materna.cms.workflow.linkcheckKlasse: LinkCheckQueyExternalManager

Diese Klasse wird als so genannter ExternalManager in den Workflowserver eingehängt und agiert als eine Art Daemon, der Aufträge zum Ausführen von Queries entgegennimmt und die Ergebnisse mittels eines Tickets zurückmeldet.

LinkCheckExternalManager

Package: de.materna.cms.workflow.linkcheckKlasse: LinkCheckExternalManager

Diese Klasse wird als so genannter ExternalManager in den Workflowserver eingehängt und agiert als eine Art Daemon, der Aufträge zum Checken von externen URLs entgegen nimmt, diese testet und das Ergebnis zurückmeldet. Aufträge zum Checken von Links werden über ein LinkCheckTicket Objekt gekapselt, welches über eine ID identifizierbar ist. Wird ein solches Ticket über die Methode addTicket() angemeldet, so wird eine entsprechende Anzahl Threads gestartet, die versuchen, die im Ticket enthaltenen URLs zu überprüfen. Nachdem alle Links getestet wurden, wird die im Ticket angegebene Process-/Workflow-Instanz informiert. Ein im Workflow-Process registrierter Guard kann dann erneut ausgeführt werden und den Workflow weiter laufen lassen. Als Basis liegt dieser Entwicklung das Jakarta Commons HttpClient Paket zugrunde (http://jakarta.apache.org/commons/httpclient/). Die Linkchecks werden ausschließlich auf dem Workflowserver durchgeführt, da der Internetzugang hier evtl. über einen Proxyserver zentral konfiguriert ist und somit ein funktionierender Zugang gewährleistet wird. (Kommunikationsrichtung bei Request: R-DMZ -> DMZ -> Internet).

Workflows

Die Funktionalität des External-Link Checkers ist über Workflows in den Editor integriert und ist in das Redaktionenkonzept integriert.

check-links-sub

Standardbezeichnung: Externe Links prüfen Dieser Workflow wird mit einer oder mehreren Ressourcen durch den Editorbe-nutzer bzw. Redakteur mit dem Automatik-Workflow gestartet. Er dient beispiels-weise der Überprüfung eines neu angelegten externen Links, bevor versucht wird, diesen zu publizieren. Ablauf des Workflows:

• User: Auswählen der Ressourcen
• User: Konfigurieren des Workflows
• System: Durchsuchen der Ressourcen nach URLs
• System: Übergeben der gesammelten URLs als ein Ticket an den Link-CheckExternalManager
• System: Warten auf das Ergebnis des LinkCheckExternalManagers
• User: Anzeigen der fehlerhaften ExternalLinks
• System: Falls ausgewählt: Starten der „broken-uri-workflows“ für External-Links mit fehlerhaften URLs

scheduled-check-external-links

Standardbezeichnung: Zeitlich gesteuerter Linkchecker Mit diesem Workflow wird die Überprüfung der externen Links im „Batchmodus“ realisiert. Pro Mandant sollte i.d.R. nur eine Workflow-Instanz von diesem Typ durch den Administrator gestartet und gepflegt werden. Dieser Workflow wird i.d.R. nicht terminiert. Neben den zu überprüfenden Ressourcen als Query werden hier der Zeitpunkt der nächsten Ausführung und die Ausführungsperiode konfiguriert. Je nach Anzahl der zu überprüfenden externen Links sollte ein Ausführungszeitpunkt mit möglichst wenig Traffic-Aufkommen gewählt werden. Nach einem kompletten Durchlauf eines Satzes an Linkdokumenten wird eine Mail mit fehlerhaften URIs verschickt. Ablauf des Workflows:

• User: Auswählen der Query und Start über Automatik-Workflow. Die Query sollte alle ExternalLink-Dokumente des Mandanten oder eine sinnvolle Untermenge liefern.
• User: Konfigurieren des Workflows
• System: Wartet auf den nächsten Ausführungszeitpunkt
• System: Durchsuchen der Ressourcen nach URLs
• System: Übergeben der gesammelten URLs als ein Ticket an den Link-CheckExternalManager
• System: Warten auf das Ergebnis des LinkCheckExternalManagers
• System: Mail mit fehlerhaften externen Links
• System: Neuberechnung des nächsten Ausführungszeitpunktes entsprechend der Ausführungsperiode
• System: Schleifenrücksprung zum ersten System-Schritt

broken-uri-sub

Standardbezeichnung: Fehlerhafte URL Dieser Workflow wird aus anderen Workflows heraus gestartet, falls externe Links mit fehlerhaften URLs gefunden wurden. Hier bekommt der Redakteur den ExternalLink und die fehlerhafte URL angezeigt und kann die URL korrigieren.

Ablauf des Workflows:

• Anderer Workflow: Auswählen der Ressource
• User: Anzeigen des ExternalLink Dokumentes und der fehlerhaften URL
• User: Ändern der fehlerhaften URL
• System: Durchsuchen des ExternalLink Dokumentes nach URLs
• System: Übergabe der gesammelten URLs als ein Ticket an den LinkCheck-ExternalManager
• System: Warten auf das Ergebnis des LinkCheckExternalManagers
• System: wenn Link immer noch fehlerhaft beginnt der Ablauf von vorne, an-sonsten beendet sich der Workflow

Publikationsworkflows

Alle Publikationsworkflows führen den beschriebenen Test durch, falls ein ExternalLink Dokument publiziert werden soll. Im Fehlerfall wird die Publikation nicht durchgeführt und alle fehlerhaften externen Links werden dem Redakteur angezeigt. Diese Integration ist für eine der nächsten Versionen des GSB geplant.

CheckExternalLinksAction

Package: de.materna.cms.workflow.actionsKlasse: CheckExternalLinksAction

Diese WorkflowAction wird in allen Workflows zur Überprüfung der externen Links eingesetzt. Ablauf der WorkflowAction:

• Übergabe der zu überprüfenden Ressourcen an einen LinkCheckCollector
• Der LinkCheckCollector durchsucht die Ressourcen nach externen Links und sammelt diese in einem LinkCheckEntry Array. Folder werden dabei rekursiv ausgelesen und nach externen Links durchsucht. Insbesondere im Batchbetrieb reicht somit die Angabe eines Basisfolders.
• Instanziieren eines LinkCheckTicket aus dem LinkCheckEntry Array
• Übergabe des LinkCheckTicket an den LinkCheckExternalManager. Dieser arbeitet parallel in mehreren Threads die Tickets nach und nach ab.

In den Workflows wird anschließend auf die Abarbeitung des Tickets gewartet. Dies leistet ein Guard mit einer LinkCheckTicketFinishedExpression., welche die Methode LinkCheckTicket.isFinished() überwacht.

Konfigurationsmöglichkeiten

Globale Optionen

workflowserver.properties:

• workflow.server.managers.LinkCheckExternalManager.maxthreads: Die maximale Anzahl an LinkCheckThreads (Ticket-übergreifend)
• workflow.server.managers.LinkCheckExternalManager.proxyhost: Der Hostname des Proxyservers, falls ein solcher benutzt wird.
• workflow.server.managers.LinkCheckExternalManager.proxyport: Der Port des Proxyservers, falls ein solcher benutzt wird.
• workflow.server.managers.LinkCheckExternalManager.proxyuser: Der Proxybenutzer (Wenn keine Proxyauthentisierung notwendig dann leerlassen)
• workflow.server.managers.LinkCheckExternalManager.proxypassword: Das Proxypassword (Wenn keine Proxyauthentisierung bitte leerlassen)
• workflow.server.managers.LinkCheckExternalManager.getafterhead: true | false: Soll nach einem fehlerhaften „HEAD“ Request ein „GET“ Request durchgeführt werden
• workflow.server.managers.LinkCheckExternalManager.class: Der „external Manager“ der die Links überprüft. (Ist für Debugzwecke änderbar)

Lokale Optionen für einzelne Mandanten

Konfigurationen werden in den Workflows über das Standard CoreMedia Work-flow GUI vorgenommen.

Überprüfung vor und während der Publikation

„check-external-links“ Workflow:

• Zu prüfende Resourcen(changeSet): Menge der zu überprüfenden Resourcen
• Weiterleitungen erlaubt(enableRedirects): true, falls Redirects weiterverfolgt werden sollen
• Maximale Anzahl Weiterleitungen(maxRedirects): Maximale Anzahl aufeinan-derfolgender Redirects
• Max. Prüfdauer pro Link(connectionTimeou)t: Zeitspanne, die der HttpClient auf ein Response wartet
• Max. Prüfversuche pro Link (maxNrOfRetries): Maximale Anzahl der wieder-holten Requests
• Zeit zwischen Prüfversuchen (s) (retryDelay): Zeitverzögerung vor einem er-neuten Request in Sekunden
• Starte Fehler-Workflows (startBrokenUriWorkflows): Soll ein Workflow zur Fehlerbehebung der Url gestart werden ?

Überprüfung im Batchmodus

„scheduled-check-external-links“ Workflow:

• Zu prüfende Resourcen(checkSet): Menge der zu überprüfenden Resourcen
• nextExecution: Zeitpunkt der ersten/nächsten Ausführung (wird nach Ausfüh-rung automatisch um executionPeriod Wert erhöht)
• Intervall(executionPeriod): Ausführungsperiode
• Zeiteinheit des Intervalls(executionPeriodUnit): Ausführungsperiode

• Weiterleitungen erlaubt(enableRedirects): true, falls Redirects weiterverfolgt werden sollen
• Maximale Anzahl Weiterleitungen(maxRedirects): Maximale Anzahl aufei-nander folgender Redirects
• Max. Prüfdauer pro Link(connectionTimeout): Zeitspanne, die der HttpClient auf ein Response wartet
• Max. Prüfversuche pro Link (maxNrOfRetries): Maximale Anzahl der wieder-holten Requests
• Zeit zwischen Prüfversuchen(retryDelay): Zeitverzögerung vor einem erneuten Request:
• Betreffzeile Ergebnismail (mailSubject): Betreffzeile der zu generierenden Er-gebnismail

Zusätzliche Hinweise

Der Linkchecker überprüft zur Zeit nur HTTP und HTTPS Requests. Andere Protokolle (zum Beispiel: mailto: oder ftp:) werden nicht unterstützt. Stößt der Linkchecker auf solche Links, werden sie ignoriert. Es kann vorkommen, dass ein Link als nicht erreichbar ausgewiesen wird, in einem Webbrowser jedoch erfolgreich aufgerufen werden kann. Dieses kann mehrere Ursachen haben. Hilfreich ist es immer mit wget auszuprobieren, ob der Link von der entsprechenden Maschine auf dem der Workflowserver läuft, erreichbar ist. Wird vom Workflowserver ein Proxy benutzt, muss auch das wget einen Proxy benutzen. Ist ein Link nicht erreichbar. kann dies mehrere Ursachen haben:

• Der Server lehnt den Linkcheck ab, weil er von einem Client kommt der ihm nicht bekannt ist. Einige Webseiten werten den USER-AGENT String aus, und lassen Requests nur von bekannten Browsern zu. Es wäre zwar denkbar den User-Agent String zu ändern um vorzugaukeln, es handelt sich um einen Browser, aber da das nicht die feine Art ist wurde darauf verzichtet. Es wäre auch denkbar, dass der Seitenbetreiber dann die IPs aus dem Netz der Anfrage sperrt, was vermieden werden soll.
• Der Link ist über den konfigurierten Proxy nicht erreichbar. Gerade interne Links die nur übers Intranet zu erreichen sind, sind über den Proxy oft nicht zu erreichen.
• Der Link war zum Zeitpunkt der Überprüfung nicht erreichbar, oder ein Timeout hat zugeschlagen. (Eventuell Timeout vergrössern)
• Der Anbieter der Seite hat die IP die den Linkcheckrequest durchführt ge-sperrt
• Es handelt sich um Https-Links: Um Https Links checken zu können, müssen alle entsprechenden Zertifikate auf dem Zertfikatsweg vorhanden sein. Nun hat der Browser zum Beispiel andere Root-Zertifikate, als die vom Workflow-server genutzte Java-Version eingebaut. Das führt dazu, daß der Browser die Seite erreichen kann, während es auf der Linkchecker Seite eine Exception gibt.

Diese sieht im Logfile so aus:

ERROR de.materna.cms.workflow.linkcheck.LinkCheckThread: LinkCheck-Thread.check: Got IOException javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Um das Problem zu umgehen könnte man nun alle entsprechenden Zertifikate aus dem Browser in den Zertifikatsstore des Javas legen. Damit wäre das Problem erledigt.