Agon Newsletter 03 / 2014.

Zurück

Ein Erfahrungsbericht zur Liferay Migration auf Version 6.2 CE

Bei einem  Finanzdienstleister werden seit etwa 5 Jahren Portal-Applikationen zur Kommunikation mit seinen Partnern und zum Kampagnenmanagement eingesetzt. Diese Portal-Lösung basierte auf Liferay Portal 5.2.2 Community Edition (CE). Agon Solutions wurde beauftragt, die Portal-Software auf den neuesten Stand zu bringen – Stand heute ist das die Liferay Version 6.2. Zusätzlich musste die Portlet-Technologie bestehend aus Liferay-Struts-Portlets ersetzt werden, da diese in der neuen Version nicht mehr unterstützt wird. Mit der Version 6.2 bietet Liferay als CMS- und Portal-Lösung viele verbesserte Möglichkeiten im Vergleich zur Version 5.2, wie z.B. Content Workflow, Benutzerverwaltung, Dokumentenverwaltung oder Responsive Design.

Übersicht über das System

Auf dem System werden insgesamt 5 Portal-Applikationen betrieben. Eine Portal-Applikation wird jeweils in einer Liferay Site (eine virtuelle Portal-Instanz) abgebildet. Innerhalb einer Site sind mehrere Portal-Seiten mit Portlets eingerichtet. Das Backend ist mit Hilfe von Liferay Services entwickelt, die die Datenbasis für die Portlets bilden.

Neben den Standard-Funktionen eines Portals, wie Struktur-, Layout-, User-Management und Authentifizierung, werden die folgenden Liferay-Funktionen genutzt:

  • Web Content, zum Einstellen von Hilfetexten und Überschriften
  • Bildergalerie, zum Einstellen und Verwalten von Bildmaterial
  • Tags, zur Kennzeichnung der eigenen Entitäten
  • Custom Attributes, zur Konfiguration der Portal-Applikation
  • Scheduled Jobs, zur zeitlich gesteuerten Auslösung von Funktionen
  • Web Form, für Kontakt-Anfragen
     

Herausforderungen und Aufgaben

Die Aufgabe der Agon Solutions bestand darin, das System auf die neueste Liferay Version 6.2 CE zu migrieren. Zwischen der Ausgangs- und Zielversion lagen vier Major-Releases sowie der Übergang von der Liferay Version 5 auf 6. Das bedeutet, dass viele Liferay-APIs, die im alten System benutzt wurden, nicht mehr vorhanden waren oder sich sehr stark geändert haben. Eine besondere Herausforderung waren die unvollständige Übersicht der geänderten Liferay-APIs und deren fehlenden Migrationspfade.

Die ursprünglich verwendete Liferay-Struts-Portlets-Technologie ist in der Zielversion den Liferay-internen Portlets vorbehalten. Deshalb mussten zunächst die Portlets auf eine Technologie gehoben werden, die weiterhin von Liferay unterstützt wird. Hier hat sich Agon Solutions bewusst für die Liferay MVC Portlet Technologie entschieden, da sie für die Anforderungen in den Applikationen die bestmögliche d.h. effektive und schlanke Technologiebasis bietet. Liferay MVC Portlet Framework bietet eine optimale Trennung zwischen Model, View und Controller Ebene. Damit können alle Vorteile von Liferay Portlets API optimal genutzt werden. Es basiert auf GenericPortlet und bietet die volle Funktionalität vom JSR 286: Portlet Specification 2.0.

Unsere technische Lösung

Die neu konzipierte und eingerichtete Software-Entwicklungsumgebung der Agon Solutions kam bei diesem Projekt erstmalig zum Einsatz. Diese besteht neben der Liferay IDE (basierend auf Eclipse) aus den folgenden Werkzeugen:

  • Gitlab, zur Verwaltung von Git-Repositories
  • Jenkins, zur Integration der Entwicklungen
  • Sonar, für einen statischen Code-Review
     

Git ist eine Open-Source Software für eine verteilte Versionsverwaltung, die auch eine nicht-lineare Entwicklung anbietet. Jeder Benutzer besitzt ein eigenes Repository, das mit dem zentralen Repository synchronisiert wird. Dies ist bei einem verteilten Entwicklerteam von großem Nutzen. Jenkins bietet ein zentrales Bild System und in Verbindung mit dem Versionsverwaltungssystem wird damit der vollständige Prozess vom Test bis zum Deployment auf Jenkins abgebildet.

Sonar wurde als Code-Review Tool eingesetzt. Dies sollte schon in der Entwicklung doppelten Code, Komplexität oder potenzielle Fehler vermeiden.

Während der Entwicklung waren noch die folgenden Punkte zu berücksichtigen:

Liferay EXT SDK:

Seit Liferay 6 bietet der Portalsoftware Hersteller das Liferay Extension SDK nicht mehr an. Mit Hilfe des Liferay Extension SDK konnte der Entwickler in den vorherigen Liferay Versionen das Liferay Portal erweitern und auch die Liferay Funktionalität überschreiben. Das neue Plugin Konzept von Liferay 6 sieht vor, dass auch eine Erweiterung als Liferay-Plugin eingebunden wird. Entsprechend musste das vorhandene Liferay Extension SDK in ein Plugin überführt werden.

Image und Document Library:

Ab Liferay 6.2 gibt es keine getrennten Bibliotheken für Bilder und Dokumente mehr. Alles wurde unter Documents and Media in einer Komponente zusammengefasst. Bei der Migration traten Probleme mit der Versionierung der Dokumente auf. Die Versionsnummern wurden nicht einheitlich formatiert. Dies konnte durch einen manuellen Eingriff in die Datenbank gelöst werden.

Responsive Design:

Das Frontend von Liferay 6.2 ist mit dem Responsive Design Framework Bootstrap 2.3.2 umgesetzt. Liferay benutzt CSS Media Queries und Compass Framework. Damit ist eine passende Darstellung von Webseiten auf verschiedenen Devices wie Smartphone, Tablet etc. mit ihren unterschiedlichen Bildschirmauflösungen möglich. Die gleichen Inhalte können in jeweils passendem Design auf unterschiedlichen Gerätetypen angezeigt werden. Insbesondere die Navigation der Webseite wird aus Platzgründen auf einem Smartphone vollständig anders dargestellt als auf einem Standard-Webbrowser. Auf dem Smartphone werden beispielsweise  bestimmte Inhaltselemente wie komplexe Grafiken oder Bilder nicht angezeigt, sondern nur die wesentlichen Inhalte. Zudem wurde die Javascript Bibliothek jQuery durch YUI ersetzt. Damit war das alte UI-Design (in Liferay „Theme" genannt) nur schwer zu migrieren. Deshalb fiel die Entscheidung, das alte Theme durch ein neues schlankes Theme zu ersetzen und es nicht zu migrieren. Das neue Theme basiert auf dem Liferay Standard Theme mit wenigen Anpassungen, wie Einstellungen zu Farben und Layout. Die vorhandenen Javascript-Funktionen, die im alten System mit jQuery umgesetzt worden waren, konnten nahezu 1:1 übernommen werden, da sich die Bibliothek in Liferay 6.2 zusätzlich einbetten lässt.

Liferay APIs:

Große Änderungen gab es in der Liferay API. Die API für Template Engine mit Velocity, Tags und Categories, ExpandoBridge und IntervalJobs wurde in der neuen Liferay Version stark verändert. Die Liferay-API-Funktionen wurden im alten System direkt im Businesscode der bestehenden Portlets verwendet und waren über die Anwendung verstreut. Durch die Kapselung der Liferay Funktionen in einer eigenen Zwischenschicht wurde diese enge Koppelung im neuen System aufgelöst.

Vorgehensweise bei der Migration

Zur Verringerung des Risikos wurde die Migration in drei Teilschritten durchgeführt:

  1. Umwandlung der Portlets
  2. Liferay Datenbank Upgrade von 5.2 auf 6.2
  3. Migration der Liferay API und der Themes


Abb. 1: Ablauf Migration Liferay

1. Umwandlung der Portlets

Die Umwandlung der Portlets wurde noch auf der Liferay Version 5.2 durchgeführt. Neben der Migration konnten auch neue Features eingebaut und das Portal erfolgreich in Betrieb genommen werden.

2. Liferay-Datenbank Upgrade von 5.2 auf 6.2

Im zweiten Schritt wurde die Liferay-Datenbank aktualisiert. Das Liferay-Datenbank Upgrade erfolgte in vier Schritten, da jedes Major-Release auf dem vorherigen Major-Release aufbaut und nicht übersprungen werden kann.

Ab dem Liferay Release 6.0 gibt es einen Wechsel im Algorithmus zur Ermittlung der Berechtigungen für Sites, Seiten, Portlets usw. Die vorhandenen Tools im Liferay Control-Panel haben dabei geholfen, die Daten entsprechend umzustellen.

Die Installation der folgenden Releases 6.1 und 6.2 verlief erfolgreich und ohne weitere Probleme.

3. Migration der Liferay API und der Themes

Abschließend wurde die verwendete API entkoppelt sowie die neue Anbindung an Liferay und das Theme implementiert.

Unser Fazit

Eine Migration der Liferay-Daten verläuft nur dann ohne Fehler, wenn die Daten keine ungültigen Fremdschlüssel enthalten. Diese können entstehen, wenn die Daten durch direkte Eingriffe in die Datenbank verändert werden. Die Daten sicher manuell oder durch Fremdsoftware zu ändern, erfordert tiefe Kenntnisse von Mechanismen und Funktionen in Liferay. Deshalb empfehlen die Autoren, nicht direkt auf die Daten zuzugreifen, ohne die Liferay API zu benutzen.

Das Projekt stand vor der Entscheidung, den Code in Liferay 6.2 Portlets zu überführen oder ein Refactoring vorzunehmen. Das Risiko im ersten Ansatz erschien als zu hoch. Eine Überführung mag zunächst einfacher klingen, da man in einem „neuen sauberen" System arbeitet, jedoch läuft man auch Gefahr, Funktionalitäten neu zu schreiben oder zu vergessen. Die Autoren sind bei einigen Artefakten auf solche Probleme gestoßen. Die Entscheidung fiel bei einem Großteil der Portlets für das Refactoring und letztendlich war die Migration so erfolgreich.

Je weiter man sich vom Standard eines verwendeten Frameworks entfernt, desto schwieriger und aufwendiger wird ein Upgrade. Die Erfahrungen aus dieser Migration zeigen, dass das auch oder vielleicht sogar besonders für das Portalframework Liferay gilt.