Zielgruppe Site AdminVersion: GSB10.1Technische Umsetzung

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.

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.

<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>

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 GSB-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“).

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.

Abbildung 7: Redaktionen als Java-Objekte

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 (vergleiche Abschnitt Workflows).

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.