FirstSpirit Object Service - Dokumentation für Entwickler
1. Einleitung
Mit FirstSpirit lassen sich kundenspezifische Projekte, die unterschiedlichsten Anforderungen unterliegen, umsetzen. Oftmals ist eine dieser Anforderungen, die im Content-Management-System (CMS) gepflegten Inhalte auf einen Portal-Server zu übertragen und dort zu nutzen.
FirstSpirit bietet durch seine offene und erweiterbare Systemarchitektur optimale Voraussetzungen, um redaktionelle Inhalte in unterschiedliche Portal-Server, wie SAP, IBM, Liferay oder Sharepoint, zu integrieren.
Besondere Vorteile lassen sich durch die Kombination eines Portal-Servers mit dem CMS FirstSpirit immer dann erzielen, wenn einzelne technische Eigenschaften einer reinen Portal-Server-Lösung, wie beispielsweise eine aufwändige Navigationsanpassung, durch funktionale Stärken des FirstSpirit-Systems ergänzt und in ein erfolgreiches Gesamtsystem überführt werden.
Eine Portal-Integration mit FirstSpirit besteht immer aus zwei Bereichen:
-
FirstSpirit-seitige Komponenten
Diese Komponenten dienen der Ermittlung, Aufbereitung und Übertragung der notwendigen redaktionellen Daten an den Portal-Server. Sie sind in der Regel generisch, d.h. unabhängig vom konkreten Portal-Server, an den die Daten übertragen werden.
-
Portal-seitige Komponenten
Diese Komponenten dienen der Verarbeitung und Überführung der redaktionellen Inhalte aus dem CMS in einen konkreten Portal-Server. Damit sind sie immer spezifisch für einen Portal-Server.
In diesem Dokument werden die FirstSpirit-seitigen Komponenten und ihre Funktionalitäten erläutert, um so die Anforderungen für die Implementierung der benötigten Portal-seitigen Komponente darzustellen. Die Beschreibung der Portal-seitigen Komponente erfolgt in einer getrennten Dokumentation.
|
Das vorliegende Dokument richtet sich an Portal-Entwickler, die mit der Hilfe der Dokumentation die Integration für ein Portal implementieren können sollen. Es ist kein Handbuch für FirstSpirit-Entwickler oder Redakteure. Es wird vorausgesetzt, dass der Leser sicher in der Verwendung mit FirstSpirit Version 5.x ist und sich bereits mit der UX-Bridge vertraut gemacht hat. |
1.1. Architektur
Die Anbindung eines Portals an FirstSpirit wird über eine Architektur aus miteinander gekoppelten Komponenten realisiert (vgl. Abbildung Architektur).
Diese Komponenten sind:
- das auf dem FirstSpirit-Server installierte FirstSpirit Object Service-Modul
- die UX-Bridge inkl. des UX-Busses
- der FirstSpirit Object Service (FOS) inkl. seiner internen Persistenzschicht
- der Portal-Server inkl. des portalspezifischen Portal-Plugins
Das Portal-Plugin übernimmt den Import der Inhalte in das angebundene Portal. Es wird durch den jeweiligen Portal-Anbieter bereitgestellt und von ihm in einer eigenen Dokumentation ausführlich beschrieben.
Das Zusammenspiel der einzelnen Komponenten erfolgt immer nach dem folgenden Schema:
- Eine auf dem FirstSpirit-Server durchgeführte inhaltliche Änderung erzeugt im Rahmen einer Generierung Nachrichten, die auf dem UX-Bus bereitgestellt werden. Diese Nachrichten enthalten alle relevanten Informationen zu den geänderten Daten.
- Der FirstSpirit Object Service (FOS) empfängt die Nachrichten und aktualisiert den in seiner internen Persistenzschicht gespeicherten Datenbestand. Anhand des dabei durchgeführten Datenabgleichs ermittelt er, welche Daten sich genau geändert haben. Das Ergebnis des Abgleichs gibt der FOS durch Event-Nachrichten über den UX-Bus an das Portal-Plugin des angebundenen Portals weiter, nachdem er den Beginn des Auftrags zunächst durch den Versand einer Status-Nachricht gekennzeichnet hat. Potentielle Änderungen an Inhalten werden dem Portal über sogenannte ChangedContent-Nachrichten mitgeteilt. Die Übermittlung der Informationen wird durch eine weitere Status-Nachricht abgeschlossen.
- Das Portal-Plugin nimmt diese Service-Nachrichten entgegen und stößt die Aktualisierung des Livestandes der Daten innerhalb des Portals an. Je nach Portal können die in einer Event-Nachricht enthaltenen Informationen für die Aktualisierung nicht ausreichen. In dem Fall fordert das Portal-Plugin die benötigten Daten vom FOS über dessen REST-Schnittstelle an, um die Aktualisierung durchführen zu können.
Die Inhalte aus FirstSpirit (Bilder, Texte etc.) werden vom FOS nicht übertragen. Ist es gewünscht, dass diese zur Verfügung stehen, müssen sie gesondert übermittelt werden. Hier gibt es mehrere Vorgehensweisen bei der Umsetzung. Beispielsweise ist eine Übermittlung der Inhalte über die UX-Bridge möglich. Empfohlen wird aber eine Lösung über ein Dateisystem.
1.2. Portal-Plugin
Das Portal-Plugin stellt das Verbindungselement in der Kommunikation zwischen dem FirstSpirit Object Service (FOS) und dem Portal dar. Es empfängt die vom FOS über den UX-Bus gepushten Service-Nachrichten und nutzt seinerseits die REST-Schnittstelle des FOS, um mit diesem zu kommunizieren (vgl. Abbildung Kommunikation zwischen dem FOS und dem Portal-Plugin).
Die REST-Schnittstelle wird dazu verwendet, weitere Daten vom FOS abzufragen, wenn die übermittelten Informationen für eine Aktualisierung des Datenbestands im Portal nicht ausreichend sind. Im Optimalfall entfällt dieser Schritt.
Im Fall einer Voll-Generierung wird das betroffene Projekt im FOS in den Wartungsmodus versetzt und das Portal-Plugin über dessen Beginn und Ende informiert. Ein Versand weiterer Informationen findet nicht statt und auch die Abfrage von Daten für dieses Projekt über die REST-Schnittstelle ist nicht möglich (siehe Kapitel Wartungsmodus).
Nach der Beendigung des Wartungsmodus führt das Portal-Plugin eigenständig einen Komplettabgleich durch, indem es den gesamten bisherigen Datenbestand des Portals verwirft und ihn über die Verwendung der REST-Schnittstelle neu einliest.