Namics auf der JAX 2014

Mit 6 Mitarbeitern war die Namics dieses Jahr auf der JAX 2014 (http://jaxenter.de/events/JAX-2014) in Mainz vertreten. Die JAX ist die führende Konferenz für Java Enterprise-Technologien. An 5 Tagen fanden 230 Vorträge mit 200 Speakern statt. Da war natürlich die neue Java Version 8 ein Hauptthema. Neben Java gab es jedoch noch viele andere spannende Themenbereiche zu entdecken wie Big Data, Mobile, NoSQL Datenbanken, Spring, Continuous Delivery, Agile und Security.

JAX 2014 Rheingoldhalle
Mit bis zu 13 parallelen Tracks fiel die Wahl für den jeweils nächsten Vortrag schwer. Da erwies sich der Besuch als Gruppe von Vorteil. In den Pausen konnte man sich gut über gewonnene Eindrücke und Trends austauschen. Auch den einen oder anderen Namics-Kunden konnte man hier antreffen. (mehr …)

Endnutzer und Redakteur – Wer pflegt die Web-Site?

Je mehr Benutzerdaten und Interaktion auf einer Web-Site verarbeitet werden, desto gefragter werden Web-Applikationen, die in ihren Datenbanktabellen Benutzerbeiträge (auch bekannt als User-Generated-Content UGC) speichern und die Web-Site lebendiger machen. Weiterhin bildet jedoch das Content-Management-System (CMS) des Unternehmens die Grundlage für den darzustellenden Content der Web-Site, sowie dessen Struktur. Redakteure und Endnutzer erstellen nun gemeinsam die Inhalte. Wie können die Vorteile von beiden Welten auf den jeweiligen Web-Seiten vereint werden?

Die Redakteure legen die Content-Struktur im CMS an und verfügen über Seitenvorlagen (auch Templates genannt). Die Seitenvorlagen beinhalten ein Layout und ggf. spezielle technische Funktionen. Die Seitenvorlagen sind somit als Teil der CMS-Lösung bereitgestellt und können meist nur durch technische Implementierung erweitert werden. Durch Anlage einer CMS-Seite, basierend auf einer der Seitenvorlagen, kann der Redakteur nun beliebige Seiten erstellen, Inhalte pflegen und deren Anordnung bestimmen. Die verschiedenen Inhaltstypen, die als Block platziert werden können, nennen wir Komponenten. Für statische Seiten, wie z.B. ein Impressum, sind diese Mittel auch ausreichend.

Mit dem User-Generated-Content erhält man nun eine starke Vervielfachung, da die vielen Endnutzer auch entsprechend viele Beiträge über Web-Applikationen erfassen können. Um nicht für jeden Beitrag eine CMS-Seite anlegen zu müssen, möchte man die Beiträge einbetten, so dass eine CMS-Seite wieder als eine Art Vorlage für viele (dynamische) Web-Seiten dienen kann. Dies erreicht man über individuell angefertigte Komponenten, welche den passenden User-Generated-Content für die zu erzeugende Web-Seite darstellen. Um die richtigen Datensätze auswählen zu können, braucht die CMS-Seite zusätzliche Parameter, die in der URL enthalten sein sollten. Dies kann ein Query-String sein wie „?id=00012324“ oder auch ein Bestandteil des URL-Pfades „/immobilienanzeige/Das+Haus+am+See“. Durch die Definition entsprechender URL-Muster und –Regeln können aus der angefragten URL die CMS-Seite und mögliche Parameter hergeleitet werden.

Mit diesem Ansatz können Redakteure und Endnutzer die Web-Site gemeinsam bereichern.

 

Das Trainingsevent Jax on Tour – Architecture 2012

How Cloud is different

Letzte Woche waren wir auf der Jax on Tour in Wiesbaden von und für Software Architekten. Hier wurde von erfahrenen Architekten viel Praxiserfahrung vermittelt, typische Herausforderungen verdeutlicht und bewährte Praktiken vorgestellt. Hier sind einige Eindrücke zusammengefasst. Cloud Computing war eines … Weiterlesen

Social Business auf der JiveLive Tour

Foto von der JiveLive Tour.

Gestern nahm ich an der JiveLive Tour in Frankfurt am Main teil. Das Thema war Social Business und wurde vorgestellt mit Erfahrungsberichten von Jive Kunden sowie einer Live Demo des Produkts. Darüber hinaus bot die Veranstaltung eine gute Möglichkeit, Kontakte … Weiterlesen

Agile Migration

Vom Plan zum Projektbetrieb

Auch für Migrationsprojekte ist klassische Projektplanung mit Meilensteinen, Aktivitäten und deren Abhängigkeiten unerlässlich. Man sollte sich jedoch bewusst machen, dass hier ein neues System entwickelt wird, während das Alte noch läuft und Veränderungen unterworfen ist. Da i.d.R. das neue System … Weiterlesen

CMS-Migration – Das Projekt planen

Rollout-Strategie Big Bang, zweistufig

Content-Freeze und Code-Freeze Wie bei den meisten IT Projekten bestehen bei einem Migrationsprojekt ebenfalls viele Abhängigkeiten und Rahmenbedingungen, die eine sorgfältige Planung erfordern. Hinzu kommt jedoch, dass bei Live-Gang des neuen Systems ein Zeitraum entsteht, in welchem keine Änderungen an … Weiterlesen

Content-Migration und die Schnittstellen

Migriert man die Daten von einem CMS in ein Neues, so ist aufgrund des Datenumfangs häufig eine automatisierte Migration unumgänglich. Es stellen sich dabei jedoch die Fragen:

  • Welche Schnittstellen sind für diesen Migrationsprozess zu verwenden?
  • Was kann überhaupt automatisiert migriert werden?

Die Abbildung zeigt, welche Metamodellebenen dabei zu betrachten sind. Man beachte, dass nur für die Inhalte eine automatisierte Content-Migration möglich ist, während die Funktionalitäten entweder durch das neue Produkt oder dessen Anpassungen und Erweiterungen abgedeckt werden müssen.

Metamodellebenen einer CMS-Lösung

Metamodellebenen einer CMS-Lösung

Die Content-Migration setzt sich aus Datenexport, Transformation und Datenimport zusammen. Hierbei ist die Wahl der geeigneten Export- und Importschnittstellen entscheidend. Üblicherweise stehen folgende zur Auswahl

  • Schnittstellen des CMS Produkts
  • APIs der darunterliegenden Frameworks
  • Direktzugriff auf die Datenbank

Die Schnittstellen des CMS Produkts eignen sich meist dann, wenn auf eine höhere Version des bereits verwendeten CMS Produkts migriert werden soll, da Hersteller, im eigenen Interesse, Unterstützung anbieten. Im Gegensatz dazu ist der Direktzugriff auf die Datenbank zwar der mächtigste Ansatz, da er alle Daten verfügbar macht, aber auch der aufwändigste, denn das Verständnis der Semantik und Relationen muss sorgfältig aufgebaut werden. Insbesondere Meta-Attribute müssen behandelt werden. Ein Teil dieser Arbeit kann evtl. entfallen, wenn man APIs von verwendeten Frameworks nutzen kann. Beim Datenimport ist zu beachten, dass APIs und Schnittstellen des CMS Produkts mehr Validierung und Konsistenzprüfungen bieten, die dabei helfen, Fehler in den gelieferten Daten aufzuspüren und die referentielle Integrität sicherzustellen. Oftmals lehnen Hersteller sogar die Verantwortung oder Support ab, wenn für den Import nicht die Schnittstellen des CMS Produkts verwendet werden, da eben genau diese Datenqualität nach den Regeln des Herstellers nicht sichergestellt ist.

Die Entscheidung für die zu verwendenden Schnittstellen muss für jede Lösung individuell getroffen werden. Die Schnittstellen des jeweiligen CMS-Produkts sind jedoch zu bevorzugen. Nur in begründeten Fällen sollte man davon abweichen.

Weitere Artikel dieser Blog-Serie

CMS-Migration auf der tekom Jahrestagung 2011

Diese Woche fand in den Rhein-Main-Hallen von Wiesbaden die Jahrestagung der tekom statt. Gebündelt mit der tcworld conference und der tekom Messe hat sie sich mittlerweile zum europaweit größten Event in der Branche entwickelt. Mit einem umfangreichen Programm aus Vorträgen und Workshops wurden viele Themen im Bereich der Technischen Kommunikation erörtert.

Als Referent durfte ich meine Erfahrungen über automatisierte Content-Migration und agilem Vorgehen vorstellen. Von den ca. 150 Zuhörern bestätigten die meisten, dass sie demnächst ein solches Projekt zum ersten mal vor sich haben.

Dies ist auch nicht verwunderlich denn viele Organisationen verfügen bereits über CMS-Systeme. Auslaufende Produktlebenszyklen, technische Neuerungen, aber auch neue Anforderungen motivieren aktuell den Umstieg auf ein anderes CMS Produkt oder eine neuere Produktversion.

4055-Challenge-thumb-500x264-4054.png

Dargestellt ist dies in obiger Abbildung. Sowohl die Content-Management-Application (CMA), zur Pflege der Inhalte, als auch die Content-Delivery-Application (CDA), zur Verteilung der Inhalte, basieren auf einem CMS Standardprodukt A welches durch ein Produkt B abzulösen ist. Dabei kann B eine neue Version von A sein oder ein ganz anderes CMS Produkt.
Die Daten aus dem gemeinsamen Content Repository soll dabei in jedem Fall übernommen werden. Aufgrund des Datenumfangs ist häufig eine automatisierte Migration unumgänglich.

Die reine Überführung der Daten ist jedoch nicht die einzige Herausforderung, die sich dabei stellt. Auch die Herstellung von Benutzerakzeptanz, die parallele Weiterentwicklung des Altsystems, sowie funktionale und inhaltliche Änderungen sind oftmals zu bewältigen.

Aufbauend auf diesen Herausforderungen beschrieb der Vortrag die Kernelemente eines solchen Migrationsprozesses, gab Planungshilfen insbesondere für den GoLive und stellte dar, warum agile Code-Migration in solchen Projekten wichtig ist.

Um diese Inhalte auch jenen zugänglich zu machen, die nicht dabei waren, gibt es sie demnächst zum Nachlesen in dieser Blog-Serie.

Weitere Artikel dieser Blog-Serie