Referenzen und Zielsysteme

Globale Metainformationen

Mit dem Media Asset Management wurde das Konstrukt des globale Metainfo-Objekts eingeführt. Darin werden Inhalte zum Dokument abgelegt die das Dokument, unabhängig von seiner Version oder dem Workflow, gegenüber anderen Dokumenten repräsentieren.

Daraus folgt, dass es für ein Dokument immer auch genau ein globales Metainfo-Objekt gibt. Dieses Objekt besitzt keine Versionierung und kann am Workflow vorbei bearbeitet werden. Die Daten des zugehörigen Dokuments sind davon jedoch nur indirekt betroffen. Diese können nur unter Einhaltung des Workflows bearbeitet werden.

Im globalen Metainfo-Objekt werden die folgenden Meta-Informationen gespeichert, soweit diese vorhanden sind:

__imperia_ac
__imperia_mam_unique
__imperia_asset_actions
__imperia_ac_variants
__imperia_ac_prevfile
__imperia_created
__imperia_mam_spool_original
__imperia_mime_content_length
__imperia_mime_content_type width height
__imperia_old_mdb_datatype
comment1
comment2
copyright
dpi
playlength
sellprice
server
viewprice

Zusätzlich werden alle Felder, die in der System-Conf-Variable GLOBAL_METAKEYS aufgeführt sind, in das globale Metainfo-Objekt übernommen.

Wird ein Dokument dessen globales Metainfo-Objekt geändert wurde importiert, so werden die Metainformationen im Dokument überschrieben. Ausnahme ist das Metafeld „Template“. Dieses Metafeld wird nicht überschrieben.

Beim „Reparsen“ werden weder die Werte vom Dokument ins globale Metainfo-Objekt übernommen, noch werden Werte aus dem globalen Metainfo-Objekt in das Dokument übernommen.

Wichtig

Die globalen Metainformationen ermöglichen es am Workflow vorbei Daten zu ändern, die dann beim Reimportieren aktiv werden. Dies widerspricht der imperia-Philosophie, dass Daten nur im Workflow verändert werden können.

Referenzen

Unter Referenzen werden in imperia URL-Links innerhalb der Metainformationen des Dokuments verstanden, die auf ein anderes imperia-Dokument verweisen .
Damit Referenzen umfassend und vollständig erfasst und gespeichert werden können, ist es notwendig genau zu wissen, welches Dokument auf welchem Zielsystem vorhanden ist. Seit imperia 9 werden die Informationen "welches Dokument auf welches Zielsystem" publiziert bzw. von dort gelöscht wurde detaillierter gespeichert.

Ablaufbeispiel: Ein Dokument A wird erstellt. Im Bearbeiten-Schritt wird z.B. über das Linktool oder das iWE ein Link auf ein anderes imperia-Dokument (B) im Dokument A erzeugt. Dazu wird in diesem Beispiel der Titel des Dokuments B als Linktext und die URL als Linkadresse verwendet. Beim Beenden des Workflows werden die in den Metainformationen referenzierten Dokumente erkannt und in ein Metafeld im global Metainfo des Dokuments gespeichert. Zusätzlich wird diese Information in einer Datentabelle (SQLite-Tabelle bei File65) abgelegt. Wenn im Dokument B nun der Titel oder ein anderes Datum geändert wird, so wirkt sich dies aktuell nicht auf das Dokument A aus.

Wichtig

Eine Reaktion auf diesen Sachverhalt wäre durch aus möglich, die durchzuführende Aktion müsste dann an den Anwendungsfall angepasst werden.

Referenzen parsen

Ab imperia 10, werden die Referenzen eines Dokuments beim Beenden des Workflows oder beim Einsatz eines entsprechenden Workflow Plug-ins (z.B. Beenden) geprüft. Dabei werden alle Metainformation des Dokuments überprüft und gefundene Referenzen in das globale Metainfo-Objekt und die Referenztabelle übernommen.

Bitte beachten

• Da die Referenzen erst beim Beenden des Dokuments identifiziert werden, werden referenzierte Dokument innerhalb des Workflows nicht als Referenz betrachtet.
  
• Beim Parsen der Metainformationen wird die Metainformation des Dokuments überprüft, nicht die Metainformationen, die für die Copy-Pages relevant sind.

Bei der Überprüfung werden alle Links innerhalb der Metainformationen berücksichtigt. Links, die nur im Template enthalten sind, können ggf. über den Linkcheck geprüft werden, haben aber keinen Einfluss auf die Referenzen. Zeigt ein gefundener Link auf eine aktuelles imperia-Dokument oder zeigt der Link auf ein ehemaliges imperia-Dokument so wird dieser Link in die Referenzen aufgenommen. Alle anderen Links werden ignoriert und können ggf. über den Linkcheck geprüft werden.

Referenzen darstellen

Gelangt ein Dokument nach der Bestimmung der Referenzen durch das Workflow Plug-in in die Darstellung der Referenzen, so werden in diesem Schritt fehlende Referenzen angezeigt. Nun bestehen folgende Möglichkeiten

• das referenzierte Dokument reimportieren

• letzten Bearbeiter des referenzierten Dokuments informieren und nach 'Wiederbelebung' fragen

• das Dokument bearbeiten und ein anders Dokument referenzieren

In Löschworkflows ist eine umgekehrte Funktionalität notwendig. Durch das Plug-in ABC3 werden nun alle Dokumente angezeigt, die dieses Dokument referenzieren. Daraus lassen sich dann Aktionen ableiten wie

• referenzierendes Dokument importieren.

• letzten Bearbeiter des referenzierenden Dokuments informieren.

• das Dokument nicht löschen, sondern wieder publizieren.

Neben der Darstellung der Referenzen sollten in dem Plug-in nicht nur fehlende Referenzen, sondern auch fehlende Links geprüft und angezeigt werden. Die Linkpüfung sollte optional im Plug-in sein. Während die Referenzen nur auf Basis der Metainformationen berechnet werden, wird die Linkprüfung nur auf Grundlage des HTMLs durchgeführt.

Mögliche Ausgabe

Das Dokument "Im Westen nichts Neues" (/12/153/4553) referenziert die folgenden Dokumente:

	Status	Aktion
"Sonne.jpg" (/15/223)	verfügbar
"Westen.png" (/15/224)	verfügbar
"news.pdf" (/16/77/1023)	gelöscht	"import", "mail"

Solange nicht alle referenzierten Dokumente verfügbar sind, können Sie das Dokument nicht abschließen. Bis dahin können Sie das Dokument weiter "bearbeiten" und ggf. andere Objekte auswählen oder Sie veranlassen, dass die gelöschten Dokumente wieder aktiviert werden.

Der Linkcheck der Seiten Ihres Dokuments ergab für die Seite /westen/neu/inde.html.de:

	Status	Aktion
"/impressum.jpg"	nicht verfügbar	"ignorieren"

Für die Seite /westen/neu/inde.html.en:

	Status	Aktion
"/imprint.jpg"	nicht verfügbar	"ignorieren"

Brechen von Referenzen

Bitte beachten

Referenzen können in imperia 10 nur noch vom Superuser gebrochen werden.

Unter "Brechen einer Referenz" wird folgendes Verstanden:
Ein Dokument verwendet ein Bild z. B. Hotel.jpg und ist auf dem Zielsystem publiziert. Nun stellt der Autor fest, dass das Bild die Rechte anderer verletzt und möchte es sofort unter allen Umständen von der Website entfernen. Dazu konnte er im MAM das entsprechende Bild auswählen und auf Löschen klicken. Im darauffolgenden Dialog wurde ihm dann angezeigt, welche Dokumente dieses Bild verwenden. Hat er an dieser Stelle bestätigt, so wurde das Bild gelöscht und das Dokument hatte einen gebrochen Link. Um diese gebrochenen Links weitgehend zu vermeiden, ist es in imperia 10 nur noch für den Superuser möglich Referenzen zu brechen.

Wie geht's richtig?

Der richtige Weg für das Problem ist, alle Dokumente, die das Bild verwenden zu importieren und an deren Stelle ein anderes Bild auszuwählen.

Was passiert wenn der Superuser eine Referenz bricht?

Voraussetzung

Für die Erklärung der Folgen müssen Sie wissen, wie in imperia 10 Referenzen erkannt werden und welche Bedingungen erfüllt sein müssen.

Ein String ist dann eine gültige Referenz, wenn

• dieser String wie ein Pfad aussieht (/aa/bb)
• dieser String in einem Metafeld des Dokuments steht
• der Pfad im String auf ein existierendes Dokument zeigt

Bricht also der Superuser eine Referenz bei einem Dokument, so wird das referenzierte Objekt gelöscht. Im Dokument, wo dieses Objekt vormals verwendet wurde, verbleibt der String in dem Metafeld, aber da dieses Objekt nicht mehr existiert, ist dieser String keine gültige Referenz mehr. D.h. nach dem Löschen des Objektes hat das Dokument keine gebrochenen Referenszen mehr.

---

Zielsysteme

Die Metainformation des Basissystems wurden im Verzeichnis site/meta gespeichert. Die Metainformationen für die weiteren Zielsysteme werden seit imperia 10 im Verzeichnis site/live gespeichert, wobei für jedes Zielsystem ein eigenes Unterverzeichnis angelegt wird.

Um die Verwendung der Zielsysteme in imperia 10 zu betrachten, muss man den Erstellungszyklus eines Dokuments genauer betrachten:

• Das Dokument wird im Workflow erstellt und beendet.

• Eine Datei-Version (üblicherweise eine HTML-Datei) wird unter dem HTDOCS-Verzeichnis erstellt und eine binäre Datei, in der die Metainformationen enthalten sind, wird in site/meta erstellt.

• Bei der Publikation auf die Zielsysteme werden die beiden (bei Copyseite auch mehr als zwei) Dateien auf die entsprechenden Zielsysteme kopiert.

Die Daten im ersten Schritt werden im Archiv gehalten. Da nicht alle Dokumente den Workflow verlassen, enthält der zweite Schritt nur einen Teil der archivierten Dokumente. Und da nicht zwangsläufig alle erstellten Dokumente auf allen Zielsystemen sind, enthalten die Zielsysteme nur einen Teil der erzeugten Dokumente.

Im Umkehrschluss ergibt sich, dass Dokumente, die auf einem Zielsystem vorhanden sind, auch auf dem Entwicklungssystem (als Datei unter HTDOCS und site/meta) vorhanden sein müssen. Und Dokumente ,die auf dem Entwicklungssystem vorhanden sind müssen zwangsläufig auch in der Datenhaltung (also im Archiv) vorhanden sein.

Zur technischen Umsetzung dieses Sachverhalts überträgt die Freischaltliste in imperia 10 sowohl Schreibaktionen (Dateien) als auch Löschaktionen (Benachrichtigungen) an die Zielssysteme. Grundsätzlich geht imperia davon aus, dass alle Dateien auf alle Zielsysteme übertagen werden. Ausnahme ist das Einschränken der Daten durch die Freischalt-Trigger.

In der Freischaltliste werden nun alle Einträge für jeden Server eingetragen. Dies betrfft das Schreiben der Dateien ebenso wie das Löschen. Wird eine Datei auf ein Zielsystem kopiert, so wird die Metainformation zu diesem Dokument nach site/live/N/ geschrieben. Gleiches erfolgt analog beim Löschen eines Dokuments.

Die Freischaltliste ist eine Art interne ToDo-Liste, die die Aktionen enthält, die durchgeführt werden müssen um das Ziel- an das Entwicklungssystem anzugleichen.

Bitte beachten

DIESE FOLGENDE ENTSCHEIDUNG WURDE ZUNÄCHST FESTGELEGT, ABER DANN REVIDIERT: Eine Bearbeitung z.B. durch das Löschen von Einträgen in der Freischaltliste ist nie erlaubt, da die Systeme dadurch nicht mehr den gleichen Bestand beinhalten würden und die Referenzen somit sinnlos würden. DIESE ENTSCHEIDUNG WURDE WIEDER GESTRICHEN. ES IST NUN DOCH MÖGLICH DELETE-EINTRÄGE ZU LÖSCHEN BZW. SIE ZU ÜBERSCHREIBEN.

Bitte beachten

Löscheinträge werden solange in die Freischaltliste eingetragen, bis sie auf allen Zielsystemen aktiv wurden. Dazu wird die Löschinformation für alle zu löschenden Varianten je Server in das global Metainfo-Objekt des Dokuments eingetragen.

Ist die Freischaltliste komplett abgearbeitet, so existiert auf den Zielsystemen kein Dokument, dass nicht auch auf dem Entwicklungssystem existiert. Und es existiert kein Dokument auf dem Entwicklungssystem, dass nicht auch in der Datenhaltung vorhanden ist.

Bitte beachten

Einzige Ausnahme ist der Zeitbereich bis die Freischaltliste mit den Schreib- und Löschaktionen komplett abgearbeitet wurde. In dieser Zeit können potentiell Dokumente auf dem Entwicklungssystem bereits gelöscht worden sein, während sie auf dem Zielsystem erst durch die noch anstehende Löschaktion entfernt werden.

Diese Grundlagen sind die Voraussetzung für konsistente Referenzen im System. Aus diesen Grundlagen ergeben sich folgende Implikationen für das Löschen von Dokumenten:

• Ein Dokument kann nur dann aus der Datenhaltung (incl. Archiv) gelöscht werden, wenn dieses Dokument auch vom Entwicklungssystem (als Datei unter HTDOCS und site/meta) gelöscht wird.

• Ein Dokument kann nur dann von Entwicklungssystem gelöscht werden, wenn dieses Dokument auch von alle Zielsysteme (als Datei unter HTDOCS und site/meta) gelöscht wird.

• Damit der letzt Punkt sichergestellt werden kann, dürfen die Freischalt-Trigger nie auf die Löschaktivitäten angewendet werden. Ansonsten könnte ein Freischalt-Trigger das publizieren einer Löschanweisung verhindern und ein Zielsystem würde mehr enthalten als das Entwicklungssystem bzw. die Datenhaltung. Das darf im Sinne der Referenzen nicht sein. Aus diesem Grund ignorieren die Freischalt-Trigger die Löschanweisungen in der Freischaltliste.

imperia geht bei getrennten Zielsystemen, z.B. bei der Steuerung durch Freischalt-Trigger, immer davon aus, dass die gleiche Dokumenten-Version auf die Zielsysteme übertragen wird. Unterschiedliche Versionen auf den Zielsystemen stellen aus Sicht der Referenzen einen Fehler dar. Man kann diese Abweichung vom Standard in Projekten akzeptieren, muss sich aber darüber im Klaren sein, dass die Referenzen dann nicht im vollen Umfang funktionieren können.

Zielsystem wiederherstellen

OPTIONALE FUNKTION

Mit den bestehenden Möglichkeiten in imperia 10 kann man jederzeit den Stand auf einem Zielsystem wiederherstellen, in dem man alle Dokumente in /site/live/N/ neu publiziert und dabei den Transfer-Cache ignoriert.

Zur Wiederherstellung könnten zwei unterschiedliche Varianten verwendet werden. 1. Die Re-Publikation der bestehenden HTML-Seiten auf Grundlage der in /site/live/N/ vorhandenen Dokumente. 2. Ein Reparsen der in /site/live/N/ vorhandenen Dokumente.

Beispiele zum Freischalten

Beispiel 1:

Ein Dokument mit der NodeId /1 wird erzeugt in den Sprachen DE und EN; es entstehen die Dateien /index.html.de und /index.html.en im Dateisystem unter HTDOCS. Gleichzeitig wird für jede Datei ein Eintrag in der Freischaltliste erstellt, dass dieses Dokument auf das Zielsystem zu schreiben (W) ist.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
/1	/index.html	DE EN	/1:W:/index.html.de /1:W:/index.html.en

Ein zweites Dokument mit der NodeId /2 wird nur in der Sprache EN erstellt. Es entsteht die Datei /index.html.en im Dateisystem unter HTDOCS. Diese hat nun die dort von Dokument /1 erstellte Version überschrieben. Also überschreibt auch die englische Version von Dokument /2 den Eintrag in der Freischaltliste. Im Dateisystem wurde die Datei /index.html.de nicht verändert, also bleibt auch der Eintrag in der Freischaltliste erhalten.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
/2	/index.html	EN	/1:W:/index.html.de /2:W:/index.html.en *x)

Es erfolgt das Freischalten. Die Dateien /index.html.de (basierend auf Dokument /1) und /index.html.en (basierend auf Dokument /2) werden freigeschaltet.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
Freischalten			<leer>

Nun wird das Dokument /1 reimportiert und ohne Änderung beendet. Es entstehen die Dateien /index.html.de und /index.html.en im Dateisystem. Diese werden genau so in die Freischaltliste eingetragen.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
/1	/index.html	DE EN	/1:W:/index.html.de /1:W:/index.html.en*x)

Es erfolgt erst mal kein Freischalten und das Dokument /1 wird erneut bearbeitet, wobei aber die Sprachvariante EN entfernt wird. Beim beenden wird nun nur noch die deutsche Seite ins Dateisystem geschrieben. Die englische Seite wird aus dem Dateisystem gelöscht. Analog dazu wird in der Freischaltliste die deutsche Datei zum Schreiben und die englische Datei zum Löschen (D) eingetragen.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
/1	/index.html	DE	/1:W:/index.html.de /1:D:/index.html.en

Es erfolgt ein erneutes Freischalten. Die Datei /index.html.de (basierend auf Dokument /1) wird geschrieben /index.html.en (basierend auf Dokument /1) wird gelöscht. Es ist der gleiche Stand wie auf dem Entwicklungssystem hergestellt.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
Freischalten			<leer>

Beispiel 2:

Ein Dokument mit der NodeId /1 wird erzeugt in den Sprachen DE und EN es entstehen die Dateien /index.html.de und /index.html.en im Dateisystem unter HTDOCS. Gleichzeitig wird für jede Datei ein Eintrag in der Freischaltliste erstellt, dass dieses Dokument auf das Zielsystem zu schreiben (W) ist, erstellt.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
/1	/index.html	DE EN	/1:W:/index.html.de /1:W:/index.html.en

Es wird wieder ein zweites Dokument mit der NodeId /2 nur in englisch erstellt. Es entsteht die Datei /index.html.en im Dateisystem unter HTDOCS. Diese hat nun die dort von Dokument /1 erstellte Version überschrieben. Also überschreibt auch die englische Version von Dokument /2 den Eintrag in der Freischaltliste. Im Dateisystem wurde die Datei /index.html.de nicht verändert, also bleibt auch der Eintrag in der Freischaltliste erhalten.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
/2	/index.html	EN	/1:W:/index.html.de /2:W:/index.html.en*x)

Es erfolgt das Freischalten. Die Dateien /index.html.de (basierend auf Dokument /1) und /index.html.en (basierend auf Dokument /2) werden freigeschaltet.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
Freischalten			<leer>

Nun wird das Dokument /1 reimportiert und es wird die englische Variante entfernt. Beim beenden entsteht nun die Datei /index.html.de diese wird auch so zum Schreiben (W) in die Freischaltliste eingetragen. Die englische Datei wurde gelöscht und müsste zum Löschen in die Freischaltliste eingetragen werden. Dies geschieht nicht, da die englische Version Dokument /2 gehört.

NodeId	Dateiname	Sprachvarianten	Freischaltliste
/1	/index.html	DE	/1:W:/index.html.de /2:W:/index.html.en skipped*x)

VORSCHLAG

• Einführung einer SYSTEM-CONF Variablen z.B.: STRICT_PATHS. Wird diese Variable auf einen wahren Wert gesetzt, so wird immer eine Warnung in die Logdatei geschrieben, wenn ein Dokument mit einer anderen NodeId eine bestehende URL überschreibt. (Alle *x) Stellen.)
• Systeme, in denen einzelne Seiten (z.B. die Homepage) immer wieder neu erstellt werden, sollten dann mit dem DocSelctor arbeiten und immer wieder die alte Version >des Dokuments bearbeiten. (Das hält auch die Zahl der Dokumente und Versionen geringer.)
• Der Vorteil ist, dass das System bei Überschreibungen warnt.