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:
- Neue (parallele) Installation von FirstSpirit 5.x
- 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:
- 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
- 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
- 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
- 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>". - 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.
Individuelle Schritte ohne Reihenfolge:
- 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.
- [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.
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.
- 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:
| Migrationsschritt | Erledigt 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) |
|
