Zielgruppe BetriebVersion: GSB10.1Workflow Konfiguration

Die Konfiguration erfolgt im Mandanten in der sogenannten Redaktionsdefinition in der vereinfacht ausgedrückt folgende Festlegungen getroffen werden: „Wer bearbeitet welche Inhalte mit welchen Prozessen?“

Die Definition der zugehörigen Redaktionsstruktur eines GSB-Mandanten erfolgt in der Workflowkonfiguration des Mandanten. Eine Redaktion ist für die Dokumente eines bestimmten Bereichs, d.h. für ausgewählte Ordner und Dokumenttypen innerhalb der CMS-Ordnerstruktur, verantwortlich. Aus fachlicher Sicht kann es sich hierbei um ein Thema innerhalb des Webauftritts einer Abteilung, der Webauftritt der Abteilung selbst oder einer ganzen Organisation handeln.

Um Redaktionen innerhalb des GSB einheitlich und strukturiert definieren zu können, werden der (technische) Aufbau und die entsprechenden Bausteine zur Spezifikation einer Redaktion in den folgenden Kapiteln dieses Dokuments beschrieben. An dieser Stelle wird der grundlegende technische Aufbau einer Redaktion vorab nur kurz skizziert:

Dokumente:

Die Angabe, für welche Dokumente eine Redaktion zuständig ist, erfolgt sinnvollerweise auf der Basis der CMS-Ordnerstruktur, indem Teilbereiche der Ordnerstruktur einer Redaktion zugeordnet werden.

Rollen und Rechte:

Zur einfacheren Verwaltung der Rechte werden Rechtegruppen definiert, die eine bestimmte Anzahl von Rechten haben. Diese Rechte kennzeichnen, welche Aktionen ein Benutzer oder Benutzerin, der dieser Gruppe zugeordnet ist, im CMS auf Ressourcen durchführen kann. Darüber hinaus werden diesen Benutzern Rollengruppen zugeordnet, die definieren, welche Aufgaben ein Benutzer oder Benutzerin innerhalb eines Workflows in einer Redaktion wahrnehmen kann. Am Ende sollte klar sein, wer im redaktionellen Prozess welche Aufgaben übernehmen darf und wer für welche Aufgaben zuständig ist.

Workflows:

Die Arbeitsschritte, die innerhalb einer Redaktion zur Veröffentlichung von Dokumenten notwendig sind, werden mithilfe von Workflows beschrieben. Ihre Hauptaufgabe liegt in der Steuerung des Ablaufs der einzelnen Arbeitsschritte und der Koordination der Redaktionsmitglieder. Durch ein- oder mehrstufige Workflows bzw. Redaktionsprozesse wird die Qualitätssicherung optimiert.

Der GSB stellt einen Satz an Publikationsworkflows zur Verfügung, deren Verwendung und Konfiguration innerhalb eines GSB-Mandanten individuell angepasst werden kann.

Logische-Ressourcen-Sammlung (LRS):

Eine Logische-Ressourcen-Sammlung (LRS) beschreibt einen Ausschnitt der CMS-Ordnerstruktur und der darin abgelegten Dokumente. Mithilfe dieser LRSen wird festgelegt, welche Inhalte von einer Redaktion bearbeitet werden sollen. Dabei verlässt sich die LRS auf die Definitionen einer Rechtegruppe des GSB. Die Menge der zu einer LRS gehörenden Dokumente wird durch die Dokumente mit Leseberechtigungen der zugrehörigen LRS-Gruppe definiert.

Redaktionsstruktur

Ein zentrales Unterscheidungsmerkmal innerhalb eines Mandanten ist die Redaktion. Jeder Zuständigkeitsbereich innerhalb des Mandanten wird über eine Redaktion(sdefinition) abgebildet.

Komponenten der Redaktionsdefinition

Um Redaktionen innerhalb des GSB einheitlich und strukturiert definieren zu können, sind in den vorausgegangen Kapitel die Bausteine zur Spezifikation einer Redaktion beschrieben worden.

Eine Redaktion setzt sich also aus LRS-, Workflowdefinitionen zusammen, die zunächst ein abstraktes Regelwerk für die Zuständigkeiten sowohl der Redaktion innerhalb des Webauftritts des Mandanten als auch innerhalb der Redaktion selbst festlegen. Um einen CMS-Nutzer im konkreten Redaktionsbetrieb einzubinden, muss dieser CMS-Nutzer seinen Aufgaben entsprechend den LRS-, Gruppen- und Rechtegruppen zugeordnet werden.

Ziel der Redaktionsdefinition ist es, eine möglichst einfache Schnittstelle zu schaffen, die durch die Zuordnung von CMS-Nutzern zu Gruppen, die CMS-Nutzer in ein Regelwerk von Berechtigungen einbindet. In diesem redaktionsspezifischen Regelwerk ist eindeutig festgelegt worden, welche Gruppe im redaktionellen Prozess welche Dokumente bearbeiten darf und welche Gruppe innerhalb eines Workflows welche Aufgaben übernehmen darf bzw. welche Gruppe innerhalb eines Workflows für welche Aufgaben zuständig ist.

Technische Umsetzung

Die Redaktionsdefinitionen werden im Content des Mandanten im Ordner \__EditorConfig/Workflows definiert. Jede Redaktion wird in einem Dokument <NAME_REDAKTION>-Redaktion definiert.

Das folgenden Beispiel skizziert den Aufbau einer Redaktionsdefinition anhand der Administrator-Redaktion des Mandanten "Standardlösung":

<Definition name="administrator-redaktion">
   <lrs>standardlsg_lrs_Alles@standardlsg</lrs>
   <Workflow name="twoeyesworkflow">
      <Startgroups>
         <startgroup>standardlsg_red_Administration_RD@standardlsg</startgroup>
      </Startgroups>
      <Tasks>
         <Compose>
            <groups>standardlsg_red_Administration_RD@standardlsg</groups>
         </Compose>
         <MailPublicationFailed>
            <mailToAssigneeFromTask>Compose</mailToAssigneeFromTask>
            <mailToCanidatesFromTask />
            <mailtemplate>twoeyesworkflow/publicationFailedTemplate</mailtemplate>
            <standardEmailReceiver />
         </MailPublicationFailed>
         <MailPublicationSuccessful>
            <mailToAssigneeFromTask>Compose</mailToAssigneeFromTask>
            <mailToCanidatesFromTask />
            <mailtemplate>twoeyesworkflow/publicationSuccessfulTemplate</mailtemplate>
            <standardEmailReceiver>email@standardlsg.example.com</standardEmailReceiver>
         </MailPublicationSuccessful>
      </Tasks>
   </Workflow>
</Definition>

Die Redaktionsdefinition wird wie im Beispiel ersichtlich als XML-Datei abgelegt und besteht als folgenden Komponenten:

• Die eigentlicht Basisdefinition (XML-Tag Definition) enthält im Name-Attribut nur den Namen der Redaktion. Der Name wird für die interne Identifikation der Redaktion benötigt.
• Die LRS-Definition (XML-Tag lrs) definiert den Namen der zugehörigen Redaktionsgruppe
• Die Workflowdefinitionen (XML-Tag Workflow) ordnen der Redaktion die in der Redaktion zur Verfügung stehenden Workflows zu.

Workflowdefinition

Die Konfiguration besteht aus den folgenden Definitionen

• Das Name-Attribut des Workflows enthält den technischen Namen des zu konfigurierenden Standardworkflows. Folgende Workflows stehen für die Publikation und Depublikation von Dokumenten zur Verfügung.
  • twoeyesworkflow entspricht dem 2-Augenworkflow
  • foureyesworkflow entspricht dem 4-Augenworkflow
  • sixeyesworkflow entspricht dem 6-Augenworkflow
  • revisitworkflow entspricht dem Wiedervorlageworkflow
• Das XML-Tag startgroup definiert die Redaktionsgruppe die den betreffenden Workflow im GSB Editor starten darf. Dass heißt, die Redakteure und Redakteurinnen müssen Mitglied in der zugrundeliegenden Redaktionsgruppe sein, um diesen Workflow über den Editor innerhalb der betreffenden Redaktion nutzen zu dürfen.
• Innerhalb des Task-Tags sind die einzelnen Schritte des Workflows konfiguriert
  • Die im XML-Tag Compose definierte Redaktionsgruppe ist für die initiale Erstellung des Workflows zuständig. Im Erstellen-Task werden bspw. die Dokumente zugeordnet und der gewünschte Publikationszeitpunkt gesetzt. In der Regel sind die Redaktionsgruppen für Compose und startgroup
  • Die im XML-Tag Approve definierte Redaktionsgruppe ist für die Prüfung des Workflows und der im Workflow enthaltenen Dokumente zuständig. Diese Definition ist für den 4- und 6-Augenworkflow relevant.
  • Der 6-Augenworkflow definiert mit der im XML-Tag Publish zugeordneten Redaktionsgruppe die Zuständigkeit für den den abschließenden Bearbeitungsschritt der Publikation.
  • Die im XML-Tag excludedUsersFromTask definierten Gruppen ermöglichen die Durchsetzung eines echten 4- bzw. 6-Augenworkflows indem bspw. im 4-Augenworkflow die Redakteure und Redakteurinnnen des Compose-Tasks von der Bearbeitung des Approve-Tasks ausgeschlossen werden können.

Mailbenachrichtigung

Neben der im Abschnitt Workflowdefinition beschriebenen Konfiguration der einzelnen Workflowschritte können für einen Workflow noch Mailbenachrichtigungen für die einzelnen Tasks definiert werden. Die eigentliche Anbindung der GSB Komponenten an die Mailinfrastruktur der Hostingplattform wird an dieser Stelle vorausgesetzt.

Als Abschluss jedes Bearbeitungsschrittes der Publikationsworkflows können Mails für einen erfolgreichen oder nicht erfolgreichen Abschluss des Schrittes verschickt werden. Die Definitionen erfolgen jeweils im XML-Tag Mail<TASKNAME>Successful für den erfolgreichen und im XML-Tag Mail<TASKNAME>Failed für den nicht erfolgreichen Abschluss eines Tasks.

Folgende Konfigurationen stehen jeweils zur Verfügung:

• mailToAssigneeFromTask definiert, ob der für die Bearbeitung des im XML-Tag angegebenen Tasks zuständige Redakteur oder Redakteurin eine Benachrichtigungsmail erhalten soll.
• mailToCandidatesFromTask definiert ob die für die Bearbeitung des im XML-Tag angegebene Redakteursgruppe eine Benachrichtigungsmail erhalten sollen.
• mailtemplate referenziert die Mailvorlage für die jeweilige Benachrichtigungsmail
• standardEmailReceiver definiert eine Mailadresse bzw. Mailgruppe, die standardmäßig die Benachrichtigungsmail erhalten soll.

Exemplarische Workflowkonfigurationen

Dieses Kapitel enthält exemplarische Workflowkonfigurationen am Beispiel des Mandananten standardlsg. Die Definitionen sollten sich auf Grundlage der skizzierten Beispiele einfach in mandantenspezifische Konfigurationen übertragen lassen.

Newsletter Workflow

Der Newsletter-Workflow dient der Publikation von redaktionell zusammengestellten Dokumenten (Dokumenttyp ConfigNewsletter). Der Workflow besteht aus einem zweistufigen Workflow. In einem ersten Schritt wird der jeweiligen Newsletter-Workflow erstellt (newslettercreateworkflow). Im zweiten Schritt wird dann die abschließend Qualitätssicherung und Publikation des Newsletterdokuments durchgeführt (newslettercompleteworkflow).

Die folgenden Redaktionsdefinitionen skizzieren die Konfiguration der beiden Workflows anhand einer "Newsletter-Redaktion" in der Standardlösung:

Newsletter-Erstellen Workfow

<Definition name="newsletter-redaktion">
   <lrs>standardlsg_lrs_Content@standardlsg</lrs>
   <Workflow name="newslettercreateworkflow">
      <Startgroups>
         <startgroup>standardlsg_red_Content_RD@standardlsg</startgroup>
      </Startgroups>
      <Tasks>
      </Tasks>
   </Workflow>
</Definition>

In diesem Fall werden die Workflows dieser Definition der Gruppe standardlsg_lrs_Content zugeteilt. Alle Nutzer der Gruppe standardlsg_red_Content_RD können diesen Workflow starten.

Newsletter abschließen

Newsletter-Abschließen Workflow

<Definition name="newsletter-redaktion">
   <lrs>standardlsg_lrs_Content@standardlsg</lrs>
   <Workflow name="newslettercompleteworkflow">
      <Startgroups>
         <startgroup>standardlsg_red_Content_RD@standardlsg</startgroup>
      </Startgroups>
      <Tasks>
         <Compose>
            <groups>standardlsg_red_Content_RD@standardlsg</groups>
         </Compose>
         <Approve>
            <groups>standardlsg_red_Administration_RD@standardlsg</groups>
         </Approve>
         <MailApprovementFailed>
            <mailToAssigneeFromTask>Compose</mailToAssigneeFromTask>
            <mailToCandidatesFromTask />
            <mailtemplate>newslettercompleteworkflow/approveFailedTemplate</mailtemplate>
            <standardEmailReceiver>email@domain.de</standardEmailReceiver>
         </MailApprovementFailed>
         <MailToComposer>
            <mailToAssigneeFromTask />
            <mailToCandidatesFromTask>Compose</mailToCandidatesFromTask>
            <mailtemplate>newslettercompleteworkflow/composeTemplate</mailtemplate>
            <standardEmailReceiver>email@domain.de</standardEmailReceiver>
         </MailToComposer>
         <MailToApprover>
            <mailToAssigneeFromTask />
            <mailToCandidatesFromTask>Approve</mailToCandidatesFromTask>
            <mailtemplate>newslettercompleteworkflow/approveTemplate</mailtemplate>
            <standardEmailReceiver>email@domain.de</standardEmailReceiver>
         </MailToApprover>
      </Tasks>
   </Workflow>
</Definition>

Der "Newsletter-Abschließen" Workflow wird von einem Nutzer der Gruppe standardlsg_red_Content_RD gestartet. Zunächst befindet sich der Workflow im Schritt Compose. Hier wird der Newsletter zusammengestellt. Im nächsten Schritt muss der Workflow von einem Nutzer der Gruppe standardlsg_red_Administration_RD freigegeben werden. Nach dem Freigeben ist der Workflow abgeschlossen. Neben Compose und Approve werden noch Mailtasks definiert.

Die beteiligten Gruppen für die einzelnen Workflowschritte und die Definition der Email-Empfänger müssen an die jeweiligen Belange der konkreten Newsletter-Redaktion angepasst werden.

Die Workflowdefinitionen müssen dem Editor bekannt sein. Die Definitionen sind in der Datei workflowmodel.xmlhinterlegt. Die Datei befindet sich in der Runtime-Konfiguration des Editors im Ordner webapps/editor.

<Workflow name="newslettercreateworkflow" alias="NewsletterCreateWorkflow" subworkflow="newslettercompleteworkflow">

    <Variables>
        <Variable name="mode" value="publication"/>
        <Variable name="callWorkflowKey" value="newslettercompleteworkflow"/>
        <Variable name="configNewsletter" value="${documentId}"/>
        <Variable name="documentTypes" value="ConfigNewsletter" internal="true"/>
        <Variable name="documents" value="false" internal="true"/>
    </Variables>
    <Tasks>
        <Task name="Compose" continue="Complete"/>
        <Task name="Complete"/>
    </Tasks>
</Workflow>
<Workflow name="newslettercompleteworkflow" alias="NewsletterCompleteWorkflow">
    <Variables>
        <Variable name="mode" value="publication"/>
        <Variable name="documentTypes" value="Newsletter"/>
    </Variables>
    <Tasks>
        <Task name="Approve" continue="Complete TestVersand"/>
        <Task name="Complete"/>
    </Tasks>
</Workflow>

Wiedervorlage-Workflow

Der Wiedervorlage-Workflow kann für wiederholt durchzuführenden Tätigkeiten wie bspw. die manuelle Prüfung externer Links auf Gültigkeit genutzt werden. Die zu prüfenden Dokumente werden über eine Suchergebnisliste (Dokumenttyp SearchResultSet) definiert.

Die folgende Redaktionsdefinition skizziert die Konfiguration des Workflows anhand einer "Content-Redaktion" in der Standardlösung:

Wiedervorlage Workfow

<Definition name="content-redaktion">
   <lrs>standardlsg_lrs_Content@standardlsg</lrs>
   <Workflow name="revisitworkflow">
      <Startgroups>
         <startgroup>standardlsg_red_Content_RD@standardlsg</startgroup>
      </Startgroups>
      <Tasks>
         <MailToGroup>
            <mailToAssigneeFromTask />
            <mailtemplate>newslettercompleteworkflow/approveTemplate</mailtemplate>
            <standardEmailReceiver>email@domain.de</standardEmailReceiver>
         </MailToGroup>
      </Tasks>
   </Workflow>
</Definition>

Der Workflow, dessen Definition der Gruppe standardlsg_lrs_Content zugeordnet ist, kann von Nutzern der Gruppestandardlsg_red_Content_RD gestartet werden. Für diesen Workflow muss lediglich der MailToGroup Task definiert werden. So wird die Mail der Wiedervorlage im beim Start definierten Rhythmus dem Redakteur per Mail vorgelegt.

Die beteiligten Gruppen für die einzelnen Workflowschritte und die Definition der Email-Empfänger müssen an die jeweiligen Belange der konkreten Newsletter-Redaktion angepasst werden.

Die Workflowdefinitionen müssen dem Editor bekannt sein. Die Definitionen sind in der Datei workflowmodel.xmlhinterlegt. Die Datei befindet sich in der Runtime-Konfiguration des Editors im Ordner webapps/editor.

<Workflow name="revisitworkflow" alias="RevisitWorkflow">
    <Variables>
        <Variable name="mode" value="publication"/>
        <Variable name="documentTypes" value="SearchResultSet" internal="true"/>
        <Variable name="documents" value="true" internal="true"/>
        <Variable name="continue" value="true"/>
    </Variables>
    <Properties>
        <Property name="executionPeriod" type=""/>
    </Properties>
    <Tasks>
        <Task name="Compose" continue="Complete"/>
        <Task name="Complete"/>
    </Tasks>
</Workflow>