Version: GSB 7Workflow-Varianten

Dokumente, die auf die Website publiziert wurden, müssen auch wieder entfernt werden können. Dies wird über einen entsprechenden Depublikations-Workflow realisiert, der eine Variation des 2-, 4- bzw. 6-Augen-Workflows darstellt. Dadurch ist sichergestellt, dass auch eine Löschoperation eine geeignete Qualitätssicherung durchläuft. Beim Depublikations-Workflow ist mit Löschen das Depublizieren von Dokumenten auf der WebSite gemeint, nicht das Entfernen von Dokumenten aus dem CMS Repository.

Depublikation

Im GSB ist ein Workflow vorgesehen, der es ermöglicht, Inhalte wieder von der LiveSite zu löschen. Die LiveSite kann Inter-, Intra- oder Extranet sein. Dieses Löschen inkludiert nicht das Löschen aus dem CMS Repository. Das muss dann ggf. zusätzlich in einem zweiten Schritt erfolgen. Bei einem Depublish-Workflow handelt es sich um Varianten der zuvor beschriebenen 2-Augen, 4-Augen- bzw. 6-Augen-Workflows, es erfolgt also auch eine entsprechende Qualitätssicherung. Diese wird zudem vom System dahingehend unterstützt, dass die Verlinkungen auf diese Seite überprüft werden, um eine Linkkonsistenz zu gewährleisten.

Wichtige Hinweise

• Bei der Depublikation und beim Auto(De-)publish wird in einer Server-Task publiziert, welche eine längere Zeit eine Server-Transaktion beansprucht. Deshalb ist darauf zu achten, diese Mechanismen sparsam und mit nur wenigen Dokumenten einzusetzen.
• Wird versucht, ein bereits depubliziertes Dokument erneut zu publizieren, ist dies normalerweise kein Problem. Verweist dies allerdings auf ein ebenfalls depubliziertes, aber nicht in der Liste enthaltenes Dokument (z. B. Metadaten), wird es im aktuellen CoreMedia Build nicht korrekt vom Publikationseditor erkannt. Auto-Vervollständigen findet es nicht und bei einer Publikation wird Version 1 publiziert, obwohl vorher bereits mehrere geänderte Versionen live waren.

Zeitabhängige Steuerung mit Workflows

Weitere Varianten der Standard-Workflows ermöglichen die zeitgesteuerte Publikation, Depublikation oder die Wiedervorlage von Dokumenten. Der Redakteur kann dabei entweder innerhalb eines Workflows oder bei der Angabe der Metadaten hinterlegen, zu welchem Zeitpunkt (Datum, Uhrzeit) die gewünschte Aktion erfolgen soll.

Metadaten

Die Standard-Workflows werten vor der Veröffentlichung die Metainformationen eines Dokuments aus. Dabei haben die Metadaten folgende Bedeutung:

• validFrom: (Datum) frühest möglicher Zeitpunkt, an dem ein Dokument publiziert werden darf. Falls jemand versucht per Workflow ein Dokument vor diesem Datum zu publizieren, wird in allen Standard-Workflows die Veröffentlichung abgebrochen und eine entsprechende Fehlermeldung ausgegeben.
• validUntil: (Datum) spätester Zeitpunkt, an dem ein Dokument publiziert werden darf. Falls jemand versucht per Workflow ein Dokument nach diesem Datum zu publizieren, wird in allen Standard-Workflows die Veröffentlichung abgebrochen und eine entsprechende Fehlermeldung ausgegeben.
• followUp: (Datum) Tag, an dem das Dokument dem zuständigen Redakteur per Workflow zur Kontrolle erneut vorgelegt werden sollte.

Diese Beschreibung ist für den Auto-Revisit-Workflow von Bedeutung.

Bei der Eingabe der Werte für diese drei Eigenschaften ist zu beachten, dass stets:

• validFrom ≤ followUp ≤ validUntil

gilt. Die Standardbelegung der drei Attribute ist wie folgt:

• validFrom = <heute>
• followUp = maxDate
• validUntil = maxDate

Diese Einstellungen können mandantenspezifisch festgelegt werden.

Auto Publish

Bei einem Auto Publish-Workflow handelt es sich um eine weitere Variante der beschriebenen 4- bzw. 6-Augen-Workflows. Beim Start des Workflows wird vom Redakteur ein Zeitpunkt (Datum, Uhrzeit) bestimmt, zu dem die Veröffentlichung erfolgen soll. Bei der Angabe des Publikations-Zeitpunkts muss, darauf geachtet werden, dass er nur innerhalb eines bestimmten Zeitfensters liegen kann. Der Publikations-Zeitpunkt wird mit max(Document.metaEnt.validFrom) vorbelegt. Um die Veröffentlichung am gewünschten Zeitpunkt sicherzustellen, wird folgende Bedingung geprüft:

• max (Document.metaEnt.validFrom)

≤ Publish-Time≤ min (Document.metaEnt.followUp)≤ min (Document.metaEnt.validUntil)

Falls diese Bedingung nicht erfüllt ist, wird der Auto Publish-Workflow mit einer entsprechenden Fehlermeldung abgebrochen.

Die Qualitätssicherung und Publikationsfreigabe laufen wie oben beschrieben ab.

Nach der Freigabe zur Publikation wartet der Workflow mit der Publikation bis zum Publish-Zeitpunkt. Dann überprüft der Workflow, ob von den zu publizierenden Dokumenten bereits eine neuere Version auf anderem Wege publiziert wurde. Ist dies nicht der Fall, werden alle angehängten Dokumente veröffentlicht. Anderenfalls werden die veralteten Versionen nicht mehr veröffentlicht und der Redakteur, der den Workflow gestartet hat, wird über diesen Vorgang in Kenntnis gesetzt.

Auto-Depublish

Bei einem Auto Depublish-Workflow handelt es sich um eine weitere Variante der beschriebenen 4- bzw. 6-Augen-Workflows mit dem Ziel der Depublikation. Beim Start des Workflows wird vom Redakteur ein Zeitpunkt (Datum, Uhrzeit) bestimmt, am dem die Depublikation erfolgen soll. Der Depublikations-Zeitpunkt wird mit min(Document.metaEnt.validUntil) vorbelegt.

Die Qualitätssicherung und Publikationsfreigabe laufen wie beim Depublikations-Workflow beschrieben ab. Anschließend verzögert der Workflow die Depublikation bis zum angegebenen Termin.

Um die Depublikation am gewünschten Zeitpunkt sicherzustellen, wird folgende Bedingung geprüft:

• max (Document.metaEnt.followUp)

≤ Depublish-Time

Falls diese Bedingung nicht erfüllt ist, wird ein entsprechender Warnhinweis ausgegeben, und der Auto Depublish-Workflow wird anschließend fortgesetzt.

Anschließend wird das Standardverhalten des Depublikations-Workflows zur Löschen von Dokumenten von der LiveSite aktiviert.