Version: GSB 7Technische Umsetzung

In diesem Kapitel werden einige Aspekte der technischen Umsetzung des Workflow-Konzepts skizziert.

Eine nahe liegende Methode ist es, pro Redaktion jeweils ein Konfigurationsdokument anzulegen, das die festgelegten Konfigurationsparameter in XML-Syntax enthält. Als Ordner für diese Dokumente ist der /Sites/<mandant>/_config/workflows fest vorgegeben.

Die Konfigurationsparameter werden anschließend in Java-Objekte umgewandelt und in einem Objekt-Repository abgelegt, wodurch sie schnell zugreif- und ausführbar sind. Bei dieser Aufgabe wird der Administrator durch einen speziellen Workflow unterstützt, der die syntaktische und semantische Überprüfung, das Parsen und das Registrieren übernimmt.

Redaktionsdefinitionen

Das folgende Listing skizziert die XML-Struktur einer Redaktionsstruktur. Detaillierte Beschreibungen finden sich zudem im Workflow Developer Manual von CoreMedia.

Diese Darstellung basiert auf dem Stand der Entwicklung im Dezember 2005. Weiterentwicklungen die aus der Umsetzung ergänzender Anforderungen resultieren, werden nicht immer sofort erfasst. Für eine Übersicht der aktuellsten Struktur wird deshalb auf die aktuellste Version der JavaDoc, der generierten Dokumentation des Java-Quellcodes, verwiesen.

<syntaxhighlight lang="xml" enclose="div"><Redaktion name="xyz_redaktionelleInhalte" default="ja" > <Mailconfig server="mail.domain.example" betreff="Eine neue Aufgabe" absender="noreply@domain.example"/> <Rollen> <Rolle typ="mandant-composer-role" startgruppe="ja" > xyz_Redakteur_RD </Rolle> <Rolle typ="mandant-approver-role"> xyz_Redakteur_QB </Rolle> <Rolle typ="mandant-approver-role-6eyes"> xyz_Redakteur_QB </Rolle> <Rolle typ="mandant-publisher-role"> xyz_Redakteur_QB </Rolle> </Rollen> <Ressourcen> <Sammlung name="xyz_lrs_RedaktionelleInhalte"/> </Ressourcen> <Workflows> <Workflow name="FourEyesSubWorkflow"> <Timeout task=”Compose” modus=”timeout”>3 Stunden</Timeout> </Workflow> <Workflow name="SixEyesPublicationSubWorkflow" modifizierendeTasks=”Publish” > <Timeout task=”Approve” modus=”offer timeout”>30 Minuten</Timeout> <Timeout task=”Compose” modus=”timeout”>3 Stunden</Timeout> <Mail task=“Approve“ vorlage=“6AugenWFMail “/> </Workflow> </Workflows> </Redaktion></syntaxhighlight>

Sektion: <Rollen>

Im <Rollen>-Tag stehen die allgemeinen Workflow-Rollen (Typ), die in den Definitionen verwendet werden und ihre Zuordnungen zu Redaktions-Rollen (worin sich die konkreten User der jeweiligen Redaktion befinden). Das Attribut „startgruppe“ kennzeichnet diejenige CAP-Rolle, in der sich alle Workflow-Startberechtigten Personen befinden (üblicherweise die composer-roles).

Sektion: <Mailconfig>

In dieser Sektion werden der Mailserver, der Betreff der Notifikationen und die Absender-E-Mail-Adresse der Notifikationen festgelegt.

Sektion: <Ressourcen>

Hier sind alle LRS aufgeführt, die durch Redaktion bearbeitet werden sollen. Ausschluss-Kennzeichen gibt es nicht – wenn bestimmte Ordner oder Dokumenttypen nicht dieser Redaktion zugesprochen werden sollen, sind sie explizit in den Leserechten der LRS auszuschließen.

Sektion: <Workflows>

In dieser Sektion sind alle für die Redaktion möglichen technischen Workflows explizit angegeben. Es gibt keine Ausschlusskennzeichen oder Platzhalter.

Das optionale Unterelement <Timeout> definiert vom Standard abweichende Time-out-Werte für jeden User Task (Attribut „task“) und den Typen (Attribut „typ“). Die Tasknamen entsprechen hier wieder den Namen in den technischen Workflow-Definitionen. Der Typ kann „offer timeout“ oder „timeout“ sein. Die Zeitangaben können in ganzzahligen Werten und deutschen Zeiteinheiten (Sekunden, Minuten, Stunden, Tagen) angegeben sein.

Ebenfalls optional ist das <Mail>-Element, welches einen User Task-Namen mit einem Vorlagedokument verknüpft. Es können keine Mails für Automated Tasks definiert werden, was in der Praxis auch nicht erforderlich ist. Die Vorlagen befinden sich in einem bestimmten Ordner unterhalb der Redaktionsdefinitionen und sind einfache CoreMedia-Dokumente mit einem Formtext. Jede Person, die einen so konfigurierten Task in ihrer Aufgabenliste findet, erhält automatisch eine E-Mail mit dem gewünschten Text.

Test- und Upload-Workflow

Das Konfigurationsdokument, das die festgelegten Konfigurationsparameter in XML-Syntax enthält, legt den Aufbau einer Redaktion fest.

Die Definition einer Redaktion wird, sobald sie das erste Mal innerhalb eines Mandanten angefordert wird, eingelesen und im Speicher abgelegt. Wenn in diesem Schritt alle vorhandenen Konfigurationsdokumente beachtet würden, könnten auch gerade in Arbeit befindliche Zwischenstände in den Produktionsbetrieb gelangen.

Deshalb gibt es einen speziellen Test- und Upload-Workflow, der nur von den berechtigten Administratoren verwendet werden kann und ein Dokument nach syntaktischer und semantischer Prüfung freigibt (bzw. aktiviert).

Beim Start werden alle zugelassenen Mandanten des Administrators zur Auswahl gestellt, unter denen einer gewählt werden muss. Über die Checkbox wird bestimmt, ob die gespeicherten Redaktionsdefinitionen lediglich getestet oder ob zusätzlich die freigegebenen Definitionen aktiviert werden sollen.

Nach Bestätigung des Tasks wird eine Ergebnisseite angezeigt, in der

• die erfolgreich interpretierten Dokumente
• die aktivierten Redaktionen
• die fehlerhaften Dokumente inklusive Fehlerbeschreibung

aufgelistet sind. Hinter den Dokumenten sind stets die Version angegeben, bei den aktivierten Redaktionsdokumenten ist das immer die zuletzt freigegebene („approve“).

Beispiele:

Im Beispiel sind drei Redaktionsdokumente vorhanden (Redaktion_a bis _c). Redaktion_b ist in der Version 4 (aktuell) bereits von einem früheren Durchlauf freigegeben („approve“-Kennzeichnung) worden, was durch den orangen Haken gekennzeichnet ist. Redaktion_a ist in Bearbeitung und noch nicht zurückgegeben. Deshalb kann sie nicht aktiviert werden, selbst wenn die Definition korrekt wäre. Redaktion_c ist zurückgegeben, aber noch nicht erfolgreich getestet worden.

Wird nun der Test-Workflow gestartet (Abbildung 11, allerdings mit aktivierter Checkbox für den Testmodus), werden alle Dokumente im definierten Ordner des Mandanten eingelesen.

In Abbildung 12 ist ersichtlich, dass nur Redaktion_b in der Version 4 (aktuellste) erfolgreich gelesen wurde. Dies muss auch so sein, denn sie ist ja bereits in der Ressourcenansicht als freigegeben gekennzeichnet. Redaktion_a und c haben ungültige Angaben (Feld „Fehlerreport“). Aktiviert wurde keine Redaktion, da der Workflow im Testmodus gestartet wurde.

Nun wurde der bemängelte Fehler in Redaktion_c behoben, das Dokument zurückgegeben und der Test erneut durchgeführt (Abbildung 13). Redaktion_c befindet sich jetzt im Feld „erfolgreich eingelesen“. Allerdings ist Redaktion_a noch nicht gültig, weshalb der Task noch als Fehler ausgewiesen ist. In der Ressourcenansicht ist nun auch Redaktion_c in der Version 4 als freigegeben gekennzeichnet (Abbildung 14) und würde beim Aktivierungsdurchlauf verwendet.

Abbildung 15 schließlich zeigt den anschließenden Durchlauf im Modus „installieren“.

Hier sind Redaktion_b und _c in den Versionen 4 (also aktueller Stand) gültig, Redaktion_a im momentanen Stand nicht. Beim Aktivieren wird deshalb ihr letzter freigegebener Stand (Version 5) verwendet.

Redaktionsmodellierung als Java-Objekte

Dieser Abschnitt erläutert grob die beteiligten Klassen, welche die CAP-Workflows um die Mandanten/Redaktionsfähigkeit erweitern.

Die zentrale Komponente ist eine Sammlung von Rule Repository-Objekten, die jeweils einen Mandanten repräsentieren und über eine Klassenmethode zugreifbar sind.

Jedes Rule Repository durchsucht den vordefinierten Ordner im Content Server des Mandanten und erzeugt aus den Redaktionsdefinitionen jeweils ein EditorGroup-Objekt. Dieses parst selbstständig den XML-Code des Konfigurationsdokuments. Durch die hier angegebenen Gruppen und Rollen kann es später zur Laufzeit entscheiden, ob der jeweilige User die markierten Ressourcen an einen Workflow dieser Redaktion hängen darf.

Ist nun festgelegt, welche Redaktion zulässig ist, muss der startende Anwender einen Workflow-Typen auswählen. Dieser Workflow ist zusammen mit den Rollen, Time-outs und den Mail-Konfigurationen ein spezieller Fall der technischen Workflows und wird schließlich in Form eines CustomWorkflowConfiguration-Objekts beschrieben. Mit den Informationen in diesem Objekt kann der Start-Workflow einen technischen Unter-Workflow auswählen und diesen mit den festgelegen Werten belegen.

Die grundsätzliche Schwierigkeit bei der Verwendung der Standardmechanismen bei unterschiedlichen Benutzergruppen besteht in der statischen Vergabe der Rollen in der Workflow-Definition. Ein Workflow kann nur auf den Server hochgeladen werden, wenn die angegebenen Rollen auch existieren. Im Nachhinein lassen sich die Rollen (= Gruppen im CAP-Server) auch nicht mehr einfach umsetzen, da sie fest in den internen Strukturen des Workflow-Servers abgelegt sind. So müsste normalerweise pro Redaktion und Workflowtyp jeweils eine Definition angelegt und auf den Workflowserver geladen werden. Da dies nur vom Site Administrator vorgenommen werden kann und eine Vielzahl fast identischer Workflows existieren würden, wäre dies in der Praxis unbefriedigend und wartungsintensitiv.

Das hier eingesetzte Verfahren legt eine Zwischenschicht über die herkömmlichen ACLRightsPolicies und legt dynamisch einen neuen, mit den speziellen Redaktionsgruppen konfigurierten Satz an Rechte-Objekten an. Auch die PerformersPolicies müssen später die Redaktionsmitglieder herausfiltern und dienen darüber hinaus zum konfigurierbaren Senden von Benachrichtigungs-Mails.

Selbstverständlich können bei besonderen Anforderungen auch weiterhin spezielle Workflow-Definitionen erstellt und hochgeladen werden.

Start-Workflow

Der Start-Workflow ist jedem Mandanten zugänglich. Jeder CMS-Nutzer darf den Start-Workflow starten, selbst wenn er nie selbst einen technischen Workflow antriggern darf (vgl. Abschnitt 3.1).

Im Redaktionsbetrieb benutzt ein CMS-Nutzer normalerweise nur den Start-Workflow. Spezielle Workflow-Typen stehen einem CMS-Nutzer nicht direkt zur Auswahl. Der Start-Workflow stellt eine Art Workflow-Wizard dar, der aus dem umgebenden Kontext die fraglichen Workflows ermittelt. Zu diesem Zweck entscheidet der Start-Workflow zunächst anhand der Ressourcen, welche Redaktionen beteiligt sein könnten. Konnte eine Redaktion gefunden bzw. bei mehreren Redaktionen eine Redaktion durch den CMS-Nutzer ausgewählt werden, entscheidet der Start-Workflow erneut anhand der Ressourcen, der ausgewählten Redaktion und der Rechte des CMS-Nutzers, welche der möglichen technischen Workflows angeboten werden können. Falls mehr als ein technischer Workflow zur Verfügung steht, wählt der CMS-Nutzer einen der verfügbaren technischen Workflows aus. Danach startet das System den eigentlichen technischen Workflow (vgl. Abschnitt 3.1).