Andreas-Knoor
Crownpeak Employee
Crownpeak Employee

Migration auf FirstSpirit 5: Update-Checkliste

In diesem Dokument werden die notwendigen Schritte für ein Update von FirstSpirit 4.2R4 auf FirstSpirit 5.x beschrieben. Ein direktes Update von FirstSpirit 4.2R4 auf FirstSpirit 5.0, 5.1 oder 5.2 wird also unterstützt.

Hinweis: Das hier beschriebene Vorgehen wurde in der Präsentation FirstSpirit5 – Upgrade und Migration noch mal aufbereitet.

I) Migration des Servers:

Der empfohlene Weg für ein Update von FirstSpirit 4.2 auf 5.x ist:

  1. Neue (parallele) Installation von FirstSpirit 5.x
  2. Export der Projekte in 4.2 und Import auf 5.x

In bestimmten Fällen ist dieser Weg nicht möglich, da ein Export/Import die Funktionsfähigkeit von Projekten beeinflusst. Dies ist beispielsweise beim Einsatz von CorporateContent der Fall, da sich hier ein Master-Projekt nicht per Export/Import transportieren lässt.

Für diese Fälle ist auch in "Inplace-Update" eines bestehenden 4.2er Servers möglich. Allerdings sind in diesem Fall einige manuelle Schritte durchzuführen (z.B. Aktualisierung des Suchindizies oder Update des Java-Wrappers). Ein simpler Austausch der Datei "fs-server.jar" reicht hier in jedem Fall nicht aus.

II) Umstellungen im Projekt

Beim Update von FirstSpirit 4.2 auf 5.x sind im Projekt einige Anpassungen durchzuführen. Dabei wird zwischen "zwingend notwendigen" und "optionalen" Umstellungen unterschieden.

Bei den aufgeführten Umstellungen im Projekt ist zu beachten, dass manche Anpassungen bereits im jetzt bestehenden 4.2er Projekt im Rahmen der üblichen Projektwartung durchgeführt werden müssen. Dies hat den Vorteil, dass die verbleibenden notwendigen Schritte bei der 5.x Migration minimiert werden. Einige Aspekte können allerdings nur direkt auf FirstSpirit 5.x durchgeführt werden. Welche Anpassung wo möglich ist, wurde jeweils vermerkt.

Zwingend notwendige Anpassungen:

Folgende Schritte sind nacheinander durchzuführen:

  1. Prüfen, ob eine Datenmigration notwendig ist:
    Wenn in einem FirstSpirit-Projekt Daten aus älteren FirstSpirit Versionen (3.x, 4.0, 4.1) stammen und somit ein altes Format haben, müssen diese zuerst auf die Migration "vorbereitet" werden.
    Ob dieser Schritt notwendig ist, kann man prüfen indem man im bereits bestehenden 4.2R4 Projekt (>=4.2.468) eine Vollgenerierung ausführt und die Auftragslogs untersucht.
    Wenn eine der folgenden Meldungen auftaucht, dann muss unbedingt Schritt 2 (und am Ende Schritt 5) ausgeführt werden, andernfalls kann bei Schritt 3 fortgefahren werden:

    INFO 22.11.2012 12:03:26.180 {...} (de.espirit.firstspirit.client.access.editor.LinkEditorValueImpl): 
    Deprecated FirstSpirit-3.1 data found. Try saving your data with FirstSpirit4 once.’ Tag=null FormName=imageWithLink' (project=..., project_id=...)

    Die alten Datenformate können von FirstSpirit 5.x nicht mehr gelesen werden. Dies hat zur Folge, dass Versionen mit dem alten Datenformat in FirstSpirit 5.x nicht mehr zuverlässig wiederhergestellt und editiert werden können. Es kann sinnvoll sein, die inkompatiblen Daten mit Hilfe einer Projektarchivierung zu entfernen.

    Umstellung in: 4.2R4


  2. Initiales Ausführen des Skripts "DataMigration" - nur notwendig, wenn Deprecated Meldungen im Log erscheinen:
    Daten, welche aus älteren FirstSpirit Versionen stammen, müssen für die Migration erst vorbereitet werden. Hierfür ist das Skript "DataMigration" zu verwenden, welches über den Helpdesk der e-Spirit AG bezogen werden kann.
    Die genaue Vorgehensweise ist in der Dokumentation des Skripts beschrieben.

    Umstellung in: 4.2R4

  3. Umstellung alter Eingabekomponenten:
    Bereits mit FirstSpirit 4.2R4 wurden neue Eingabekomponenten eingeführt, die mit dem Namenskürzel FS_* beginnen (z.B. FS_LIST oder FS_REFERENCE) und andere (alte) Eingabekomponenten ablösen (z.B. CMS_INPUT_PICTURE).
    Die Verwendung der neuen Eingabekomponenten ist in FirstSpirit 5.0 Pflicht. Projekte die noch mit alten Komponenten arbeiten, müssen auf die neuen Komponenten umgestellt werden.
    Insgesamt sind folgende Komponenten betroffen: CMS_INPUT_FILE, CMS_INPUT_PICTURE, CMS_INPUT_PAGEREF, CMS_INPUT_OBJECTCHOOSER, CMS_INPUT_CONTENTAREALIST, CMS_INPUT_CONTENTLIST, CMS_INPUT_LINKLIST, CMS_INPUT_SECTIONLIST, CMS_INPUT_TABLIST

  4. Umstellung alter Linkvorlagen auf generische Links:
    Schon seit der Einführung von FirstSpirit 4.0 besteht das Konzept der "generischen Verweisvorlagen". In FirstSpirit 5.0 sind nur noch diese Art von Verweisvorlagen erlaubt. Evtl. vorhandene alte Verweisvorlagentypen müssen auf die generischen Verweisvorlagen umgestellt werden.
    Die Verwendung von alten Link-Templates kann über das Generierungslogfile ermittelt werden. Die passende Meldung ist "usage of deprecated old link template <name>".  
  5. Finales Ausführen des Skripts "DataMigration" - nur notwendig, wenn Schritt 2 notwendig war:
    In diesem Schritt werden die Daten endgültig ins neue Format konvertiert. Hierfür wird das Skript "DataMigration" erneut ausgeführt (siehe Schritt 2), welches über den Helpdesk der e-Spirit AG bezogen werden kann.
    Die genaue Vorgehensweise ist in der Dokumentation des Skripts beschrieben.
      • Umstellung in: 4.2R4

Individuelle Schritte ohne Reihenfolge:


  • Einbau von Content-Highlighting und WebEdit:
    In FirstSpirit 4.x konnten die Konzepte "Content-Highlighting im Java-Client" und "Support von WebEdit" über passende Template-Konstrukte aktiviert werden.

    Mit der Einführung von FirstSpirit 5.0 wird dies deutlich einfacher, da beide Konzepte sich mit einem gemeinsamen (neuen) Template-Markup aktivieren lassen. Die alten Tags müssen somit aus dem Projekt entfernt und das neue Konstrukt eingebaut werden.

      • Umstellung in: 5.x
      • Details:siehe dazu 5.0er Release-Notes, Kapitel 5.2 "Vorlagenanpassung für Content Highlighting und WebEdit 5.0"

  • Anlegen von "Snippets" in Templates:
    Mit FirstSpirit 5.0 werden für Templates sogenannte "Snippets" eingeführt. Snippets sind Kurzdarstellungen eines Content-Elementes, z.B. in Suchergebnissen oder in Übersichtslisten. Besonders der 5er WebClient nutzt diese Technik ausgiebig. Alle bestehenden Templates müssen mit passenden Snippet-Definitionen ausgestattet werden.

      • Umstellung in: 5.x
      • Details: siehe dazu 5.0er Release-Notes, Kapitel 5.5.2 "Gestaltung von Suchtreffern (Register "Schnipsel")

  • [für eigene Module] Neu-Compilierung gegen FirstSpirit 5.0 API:
    Alle selbst entwickelten Module müssen vor einem Einsatz im FirstSpirit 5.0 einmal gegen die 5er-API neue gebaut/compiliert werden.
    Zusätzlich ist noch darauf zu achten, dass FirstSpirit 5.0 sowohl für JDK 1.6 als auch JDK 1.7 freigegeben ist. Für Modulentwicklungen bedeutet dies, dass das Modul sowohl unter JDK 1.6 als auch JDK 1.7 getestet werden muss.

      • Umstellung in: 5.x

  • [für eigene Skripte/Module] Prüfung auf Deprecations:
    Wie in jeder Major-Version können in FirstSpirit 5.0 Funktionen, die in 4.x als "deprecated" markiert waren, entfallen.
    Bei der Verwendung der FirstSpirit API in Beanshell Skripten oder Modulen muss geprüft werden, ob keine Deprecated-Funktionen verwendet worden sind. Falls doch, muss stattdessen die passende neue API-Funktion verwendet werden. Insgesamt wurde bei FirstSpirit 5.0 darauf geachtet, diese API-Änderungen so minimal wie möglich zu halten.

      • Umstellung in: 5.x

Optionale Anpassungen:


  • Verwendung von dynamischen Formularen:
    Ab FirstSpirit 5.0 gibt es das Konzept der dynamischen Formulare, welches mehr Interaktivität und Logik in den Eingabemasken erlaubt. Falls diese Funktion verwendet werden soll, sind passende Formularlogiken ins Projekt zu integrieren.

  • Umstellung von allowEmpty auf dynamische Formulare
    Das allowEmpty="no" für Eingabekomponenten verhält sich unter FirstSpirit 5.1 strenger als unter FirstSpirit 4.2R4. In mehrsprachigen Projekten kann unter 4.2 das Formular gespeichert werden, obwohl noch nicht alle Felder in allen Sprachen gefüllt sind. Das Speichern wird erst verhindert, wenn mindestens ein Feld in einer Sprache gefüllt wurde. Unter FirstSpirit 5.0 ist diese Spezialbehandlung entfallen. Hier wird das Speichern verhindert, bis alle Felder in allen Sprachen gefüllt sind. Ist dies nicht gewünscht, so sollte auf die Verwendung von allowEmpty="no" verzichtet werden. Stattdessen kann das gewünschte Verhalten über dynamische Formulare und Regeln abgebildet werden. Siehe dazu den vorherigen Punkt.
      • Umstellung in: 5.x

  • Verwendung von SEO-URLs:
    FirstSpirit 5.0 verfügt über eine (optional wählbare) neue Logik bei der Erzeugung von URLs. Neu sind Funktionen wie sprachabhängige URLs, Short-URLs oder sprechende Dateinamen bei Datenquelleninhalten.

III) Weitere Hinweise

Index-Aktualisierung:

Es ist zu beachten, dass nach einem Update auf FirstSpirit 5.0 der FirstSpirit-interne Suchindex komplett neu aufgebaut wird. Das gilt für den Fall eines Projekt-Exports und Imports nach 5.0 ebenso wie für ein Inplace-Update.

Dauer der Indizierung: Diese Index-Aktualisierung kann bei großen Projekten einen langen Zeitraum in Anspruch nehmen (viele Stunden bis wenige Tage). Dies gilt insbesondere für Projekte, die viele oder große Datenquellen beinhalten oder lesend angebunden haben.

Während einer kompletten Neuindizierung ist das System ggf. so stark belastet, dass ein redaktionelles Arbeiten nur eingeschränkt möglich ist.

Es wird daher unbedingt dazu geraten vor der Umstellung des Produktionssystems die Aktualisierung (inkl. Neuindizierung) auf einem Testsystem mit identischen Datenmengen zu überprüfen. Nur so kann der notwendige Zeitraum für die Neuindizierung sinnvoll abgeschätzt und eingeplant werden.
Optimierung der Indizierung:Im FirstSpirit ist konfigurierbar, welche "Index-Tiefe" bei der Indizierung von Datenquellen mit Fremdschlüsselverbindungen verwendet werden soll. Per Default ist dieser Wert auf "so tief wie möglich" eingestellt. In Projekten mit vielen verschachtelten Fremdschlüsselbeziehung ist es häufig sinnvoll, diesen Wert zu reduzieren. Unser Helpdesk hilft gerne bei der Festlegung des richtigen Wertes für ihr Projekt.

Performance-Optimierung für Datenquellen:


Ab FirstSpirit 5.0 werden wird in den Datenquellen eine neue technische Spalte für Tabellen eingeführt (GID-Spalte). Gegen den Inhalt diese Spalte werden viele Anfragen gestellt. Für Migrationsprojekte ist es daher sinnvoll, auf alle GID-Spalten manuell einen Datenbank-Index zu setzen, da dies nicht von FirstSpirit eigenständig übernommen wird. Unser Helpdesk unterstützt sie dabei gerne.

Für in FirstSpirit >= 5.0 neu angelegte Tabellen ist dieser Schritte nicht notwendig. In diesem Fall erzeugt FirstSpirit eigenständig die notwendigen Indizies.

IV) Check-Liste für die Migration

Hier noch mal die Migrationsschritte als Checkliste:

MigrationsschrittErledigt für mein Projekt?
Prüfung und ggf. Durchführung einer Datenmigration
Umstellung alter Eingabekomponenten
Umstellung alter Linkvorlagen auf generische Links
Einbau von Content-Highlighting und WebEdit
Anlegen von "Snippets" in Templates
Neu-Compilierung gegen FirstSpirit 5.0 API [nur für eigene Module]
Prüfung auf Deprecations [nur für eigene Skripte/Module]
[optional] Verwendung von dynamischen Formularen
[optional] Umstellung von allowEmpty="no" auf dynamische Formulare/Regeln
[optional] Verwendung von SEO-URLs
Einplanung der notwendigen Zeit für die Index-Aktualisierung (nur bei sehr großen Projekten)

Labels (1)
Comments

Hallo.

Zwei Fragen hierzu und ein Hinweis, dass der Umbau der FS_* Komponenten nur erforderlich ist, wenn man WebEdit5 nutzen möchte. Es muss also nicht immer zwingend umgebaut werden wie es oben beschrieben steht!

Siehe https://community.e-spirit.com/message/9487#9487

Ist der Umbau des Content-Highlighting zwingend notwendig oder funktioniert die alte Syntax, wenn man nur den JavaClient benutzt weiter?

Bekome ich eine Warnung in den Logs, wenn ich Funktionen verwende die deprecated sind?

Viele Grüße,

Daniel

Der Umbau des ContentHighlighting ist zwingend notwendig, auch wenn kein WebClient verwendet wird.

Bei alten Links gibt es eine Warnung, wenn noch das alte Format verwendet wird. Bei API-Aufrufen ist dies ebenfalls so. Das ist aber sicherlich nicht für alle Funktionalitäten der Fall, die mit Version 5 depracted sind. Ein Beispiel wären Eingabekomponenten. Es gibt für den Entwickler keinen Warnhinweis, wenn er die in ein Formular einfügt.

Sehr geehrte FirstSpirit Community,

wie verhält es sich mit den als "Snippets" benannten Funktionen? Sind diese zwingend bereitzustellen oder vielleicht doch nur optional?

Wenn wir die Liste oben richtig verstehen und interpretieren, müsste es sich aus unserer Sicht um Teile handeln, die Voraussetzung für einen Betrieb und Einsatz von FirstSpirit 5.0 sind.

Hallo Herr King,

genau, die Snippet sind fuer WebEdit-5 zwingend notwending. Nicht jedoch fuer den JavaClient.

Hallo,

Sie schreiben, dass das Anpassen der Eingabekomponenten unter 4.2 oder 5.0 möglich ist.

Folgende Frage dazu:

Wäre es möglich einen inplace-Update des Builds zu machen von 4.2 auf 5.0 ohne die Komponenten anzufassen um zu sehen wie sich all unsere Templates, Skripte und sonstigen Komponenten verhalten.

Danke für die Antwort !

Grüße Torsten Kupetz

Hallo Herr Kupetz,

Wäre es möglich einen inplace-Update des Builds zu machen von 4.2 auf 5.0 ohne die Komponenten anzufassen um zu sehen wie sich all unsere Templates, Skripte und sonstigen Komponenten verhalten.

das kann man einzeln beantworten:

  • Templates: Ja, kann man in 5.0 bewerten
  • Skript: Sind auch in 5.0 zu bewerten
  • "Sonstige Komponenten": Die Eingabekomponenten können wie gesagt in 4 oder 5 umgestellt werden. Wenn man den 5er Schritt möglichst klein halten will, erledigt man das am besten direkt in 4.x, was aber kein Zwang ist.

Interessant ist vermutlich noch dieses Dokument, wo ein paar weitere Migrationsaspekte beschrieben sind:

FirstSpirit5 – Upgrade und Migration

Hallo Herr Knoor,

das Dokument scheint in einem geschützten Bereich zu liegen. Teilen Sie uns die Zugriffsmöglichkeiten mit?

Ich habe jetzt den korrekten Link eingefügt (s.o.).

Hallo,

bei der Update-Schulung haben wir gehört, dass nach der Konvertierung der alten Verweisvorlagen jede Seite/Datenquelle, wo ein Link vorkommt einmal entsperrt, gespeichert und wieder entsperrt werden muss; es wird hierfür seitens e-Spirit ein entsprechendes Script bereitgestellt;

ist es tatsächlich so und wenn ja, wann ist damit zu rechnen ?

Danke & Gruß,

Michael

Hallo Michael,

ja, das ist für "alte" Verweisvorlagen korrekt. Die notwendigen Datenmigration kann entweder manuell (sperren/speichern/entsperren) oder per Skript ausgeführt werden.

Das Skript wird im Laufe des Januars verfügbar sein.

Das beschriebene Skript für die Datenmigration ist inzwischen beim Helpdesk erhältlich.

Hallo Herr Knoor,

ein Kunde von uns möchte von FS 4.2 auf 5.0 updaten.

Neben dem Migrationsaufwand im Projekt, welche Kosten entstehen weiterhin z.B. für Lizenz oder ähnliches?

Vielen Dank vorab!

Mit freundlichen Grüßen

Betty

Hallo,

Neben dem Migrationsaufwand im Projekt, welche Kosten entstehen weiterhin z.B. für Lizenz oder ähnliches?


                   


das kommt auf den Wartungsvertrag des Kunden an.

Fast alle Kunden haben einen Wartungsvertrag mit dem Recht auf neue Major-Versionen zu gehen, ohne neue Lizenzgebühren dafür bezahlen zu müssen.

Falls neue Module gewünscht oder notwendig sind, sind diese natürlich wie gewohnt zu lizensieren.

Bitte gehen Sie für eine konkrete Aussage auf den zuständigen Vertriebsmitarbeiter von e-Spirit zu.

Angenommen man will eine Migration von 4.2R4 auf 5.1 durchführen - wären dann die gleichen Schritte wie bei der Migration von 4.2R4 auf 5.0 durchzuführen?

Oder gibt es zusätzliche 4.2R4-Features, die in Version 5.0 noch funktionieren aber in Version 5.1 nicht mehr unterstützt werden?

Ich benötige die Info für eine Kalkultaion.

Hallo in die Runde,

meines Erachtens gibt es ein Problem bei der Reihenfolge der Checkliste.

Um eine CMS_INPUT_LINKLIST in eine FS_LIST umzubauen, muss ich zuvor die Verweivorlagen konvertiert haben, oder? Somit wären Punkt 3. und 4. zu tauschen?!

Des Weiteren stellt sich uns die Frage, ob das Skript zur Datenmigration in jedem Fall angewendet werden muss, wenn statische Link-Editoren im Rahmen der Migration auf generische Links umgestellt wurden?

Außerdem sieht es so aus, als würden bei der Umstellung die Vorgabewerte nicht übernommen werden.

Gibt es, wie bei der Projektkonvertierung von FS 3 nach FS 4 ein Skript zur Übernahme der Vorgabewerte?

Vielen Dank und viele Grüße

Sabrina Schneider

Um eine CMS_INPUT_LINKLIST in eine FS_LIST umzubauen, muss ich zuvor die Verweivorlagen konvertiert haben, oder? Somit wären Punkt 3. und 4. zu tauschen?!


                   

Solange man die Komponente nicht speichert, kann die Konvertierung später gemacht werden.

Des Weiteren stellt sich uns die Frage, ob das Skript zur Datenmigration in jedem Fall angewendet werden muss, wenn statische Link-Editoren im Rahmen der Migration auf generische Links umgestellt wurden?


                   

Es kommt auf die Historie (3.1/4.0) des Projektes an? Generell empfehlen wir daher das Skript zu starten.

Außerdem sieht es so aus, als würden bei der Umstellung die Vorgabewerte nicht übernommen werden.

Gibt es, wie bei der Projektkonvertierung von FS 3 nach FS 4 ein Skript zur Übernahme der Vorgabewerte?


                   

Leider gibt es das nicht. Da man das Formular eh anpassen muss, können auch die Vorgabewerte von Hand übernommen werden.

Seitens e-Spirit wird eine Anwendung zur Datenmigration angeboten. Die Frage, die wir uns gerade stellen:

  • migriert die Anwendung auch Inhalte in an FirstSpirit angebundenen relationalen Datenquellen?
  • können Daten in relationalen Datenquellen für die Datenmigration ignoriert werden oder besteht die Verpflichtung auch die in FirstSpirit-verwalteten relationalen Datenquellen inhaltlich auf Migrationsnotwendigkeiten hin zu überprüfen?

Interne Datenquellen werden mit konvertiert. Dies ist technisch auch notwendig, damit die Migration funktioniert.

Externe (Readonly-) Datenbanken bleiben natürlich unangetastet.

jst

3. Umstellung alter Eingabekomponenten:

...

  • Umstellung in: 4.2R4

...


Ist das ein Schritt, welcher Zwingend in Version 4.2R4 erledigt werden muss. Ggf. man hat ein dreistufiges System (DEV, QAS und Prod) und hat diese Änderung im DEV-System bereits durchgeführt. Könnte man dann die QAS und PROD Projekte "einfach" exportieren und in eine 5.1 Version importieren und die Vorlagen inkl. Eingabekomponenten via "Externe Synchronisierung" aktualisieren?

So hätte man die Arbeit der Aktualisierung von Eingabekomponenten nur einmal gehabt.

Viele Grüße

Jörn

AuM

Hallo zusammen,

ich habe noch eine Frage zu Kapitel II) Umstellungen im Projekt, konkret geht es dabei um die Datenmigration.

Da die Ausführung der bereitgestellten Applikation - bei entsprechend viel Content - eine Weile braucht, würde ich gern verstehen warum wir das Tool zwei mal ausführen müssen. Gibt es da ggf. einen Weg drumrum?

Vielen Dank und Gruß

Martin

Hallo Martin,

das kommt auf das Alter des Projektes an. Ist das Projekt noch aus 4.0 Zeiten? Wenn noch alte Link-Daten in den Datensätzen sind, müssen diese zuerst migriert werden.

Gruß

Gerrit

AuM

Hallo Gerrit,

erstmal vielen Dank für das Feedback!

Ich glaube ich habe mich in obigem Post etwas unklar ausgedrückt, ich versuche mal etwas mehr Kontext zu geben. Es geht um Projekte die bereits seit FS3 bestehen und wir haben die Linkvorlagen um Zuge der regelmäßigen Wartung bereits vor langer Zeit auf generische Linkvorlagen umgestellt. Da nun die FirstSpirit 5 Migration ansteht haben wir die Notwendigkeit einer Datenmigration positiv aufgrund von "deprecated..." Logmeldungen in den Generierungslogs festgestellt.

Was mich an der Stelle  verwundert ist, dass wir die Datenmigration einmal vor (Schritt 2) und einmal nach (Schritt 5) dem Update der Formularkomponenten (Schritt 3) auf das neue Format (FS_*) ausführen müssen.

Vielen Dank und Gruß

Martin

Hallo Martin,

der Grund sind die Daten innerhalb von FirstSpirit. Das Datenformat muss erst in eine neues Format überführt werden, bevor auf eine neue Eingabekomponente umgestellt wird.

Gruß

Gerrit

rkl

Hallo Herr Knoor,

bezugnehmend auf Ihren Kommentar vom 22.05.

Interne Datenquellen werden mit konvertiert. Dies ist technisch auch notwendig, damit die Migration funktioniert.

Externe (Readonly-) Datenbanken bleiben natürlich unangetastet.

möchten wir nachhaken. Besteht für externe Datenquellen welche aber durch FristSpirit verwaltet werden der Bedarf einer Datenmigration?
Kleine Randinformation: Das betreffende Projekt wurde uner FirstSpirit 4.2 angelegt.

Danke für eine kurze Rückmeldung hierzu.

Hallo Herr Kloppmann,

externe Datenquellen sind bei Ihnen dann "readonly Datenquellen", die aber in einem (anderen) Projekt schreibend eingebunden sind?

In diesem Fall ist aus Sicht des Projektes, welches die Daten lesend einbindet, nichts zu tun.

Aber aus Sicht des Projektes, welches die Datenquelle beschreibt, muss eine Konnvertierung durchgeführt werden.

rkl

Hallo Herr Knoor,

danke für die prompte Rückmeldung! An und für sich ist diese auch klar - allerdings möchte ich nochmals explizit darauf hinweisen, dass das betreffende Projekt unter FirstSpirit 4.2 angelegt wurde.

Ist dennoch eine Datenmigration notwendig?

Ja, auch in diesem Fall.

Hallo Herr Knoor,

wir haben jetzt wiedersprüchliche Aussagen. In der Dokumentation zur Datenmigrations-Anwendung "linkdatamigration" steht einleitend die Aussage:

...Für Projekte, die mit FirstSpirit 4.2 erstmalig aufgesetzt wurden, sind keine weiteren Aktionen notwendig.
                   

Auch Herr Leinich sah den Zwang einer Datenmigration in diesem Fall bisher nicht.

Könnten Sie das intern nochmals klären und begründen, warum die Datenmigration hier notwendig wird? (bitte für den Fall, dass in einem unter FS 4.2 aufgesetzten Projekt initial durch die Datenmigration migrierte Eingabekomponenten "CONTENTAREALIST" bzw. "LINKLIST" benutzt wurden?)

Hallo Herr King,

wir haben beide Recht Smiley Wink

Die Datenmirgration muss ja potentiell 2x durchgeführt werden:

a) 1x vor der Umstellunge der Eingabekomponenten (um alte 2.x und 3.x Formate in das 4er Format zu überführen)

b) 1x nach der Umstellunge der Eingabekomponenten


Herr Leinich sprach von Schritt a). Den kann man sich bei einem 4er Projekt sparen.

Ich sprach von Schritt b). Dieser ist immer durchzuführen.

Hallo Herr Knoor,

In der Update-Checkliste haben Sie freundlicher Weise daraufhingewiesen, dass ein direktes Update auf 5.1 unterstützt wird.

"Ein direktes Update von FirstSpirit 4.2R4 auf FirstSpirit 5.1 wird also unterstützt."

Ich nehme an, dies gilt auch für ein direktes Update von 4.2R4 auf die neue Version 5.2?!

Freundliche Grüße

Carsten Noetzel

Ja, eine Migration eines Projektes von 4.2R4 auf 5.2 ist ebenfalls möglich. Ich habe den Text im Blogposting angepasst.

Hallo, eine vielleicht unpassende Frage. Müssen vor einer Migration von 4.2 auf 5.x folgende Dinge "erledigt" seien

- entfernen ungültiger Referenzen die man im Java Client über "Suchen" -> "Suche nach ungültigen Referenzen" aufgelistet bekommt

- akutell werden bei der Generierung der Seiten noch Errors und Warnings ausgegeben. Müssen diese vor der Migration komplett aufgeräumt werden?

Vielen Dank für die Unterstützung.

MfG C. Thumser

Hallo,

abgesehen von der allgemeinen Empfehlung, immer in ein "sauberes" Projekt zu investieren, kann man zu den konkreten Punkten sagen:

- entfernen ungültiger Referenzen die man im Java Client über "Suchen" -> "Suche nach ungültigen Referenzen" aufgelistet bekommt

Wenn man nach der Migration keinen "Broken-Links" (mehr) haben möchte: Ja, ist notwendig.

- akutell werden bei der Generierung der Seiten noch Errors und Warnings ausgegeben. Müssen diese vor der Migration komplett aufgeräumt werden?

Hier ganz klar: Ja, das ist für eine ordentliche Migration auf jeden Fall notwendig!

Der Grund ist einfach: Wenn man das nicht macht, kann man die Fehler/Warnings, die durch die Migration hervorgerufen werden (und beseitigt werden müssen) nicht klar erkennen.

Wenn man nach der Migration keinen "Broken-Links" (mehr) haben möchte: Ja, ist notwendig.

Das auch - allerdings lassen sich manche Objekte auch einfach nicht speichern, wenn da ein Broken-Link enthalten ist. Damit funktioniert dann die Datenmigration nicht. Hat also nicht nur einen "Schönheitseffekt", sondern ist - je nach Projektalter und Migrationspfad - zwingend notwendig.

Dear Andreas Knoor,

Could you also post this information in English? There are more customers that are English based and doesn't speak German very well?

If that is possible, it would be very fine to use it for our FirstSpirit system 🙂