Seiteninhalt:
WCMS-/Portal-Integration
Bei der Einführung einer Portal-Lösung gehört die Integration bestehender Anwendungen, Datenquellen und Inhalte regelmäßig zu den wichtigsten Zielen: Die hier bereits getätigten Investitionen sollen geschützt werden, die Anwender sind mit den bestehenden Systemen vertraut. Während sich viele Applikationen über die von WebSphere Portal mitgelieferten Portlets relativ problemlos einbinden lassen, wirft die Integration der inzwischen weit verbreiteten Web Content Management Systeme (WCMS) Fragen von besonderer Relevanz auf.
Doppelte Pflege von Navigationsstrukturen
Alle redaktionellen Inhalte, die im Portal an den verschiedensten Stellen veröffentlicht werden, sollten aus Effizienzgründen auch nach der Integration im WCMS gepflegt werden. Genau wie das Portal weist aber auch das Web Content Management System eine eigene Navigationsstruktur auf. Bei der Integration des WCMS stammt die Head-Navigation, aus der jeder Hauptnavigationspunkt auf eine eigene Portalseite verweist, aus dem Portal. Der untere Bereich der Portalseite wird meist aus dem WCMS „befüllt“. Dabei ist eine Aufteilung in Navigation auf der linken Seite und Content auf der rechten Seite üblich. Ein Navigations-Portlet „erzeugt“ die Navigation, ein Standard-Content Portlet die Inhalte. Soll bei diesem „gegebenen“ Seitenaufbau ein neuer Content-Bereich erstellt werden, so ist dieser sowohl im Portal als auch im WCMS anzulegen. Mit der Konsequenz, dass die gleiche Navigationsstruktur in zwei Systemen gepflegt werden muss. Diese parallele Pflege ist nicht nur unnötig zeitaufwändig, sondern auch fehlerträchtig.
Aufbau einer Portalseite mit über Navigations-Portlets erzeugter Navigation
Keine Flexibilität bei Einsatz von Standard-Portlets
Werden bei der WCMS-/Portal-Integration die von den WCMS-Herstellern mitgelieferten Standard-Portlets verwendet, werden alle Inhalte in der gleichen Portalseite angezeigt. Dadurch ist der Aufbau der Portalseite jedoch vielfach zu starr festgelegt: Auf einer einzelnen Contentseite des Portals können dann keine zusätzlichen Portlets angezeigt werden, ohne dass diese auf allen aus dem WCMS befüllten Contentseiten des Portals erscheinen. So ist es dann nicht möglich, nur auf einer oder mehreren ausgewählten Portalseiten beispielsweise ein elektronisches Kontaktformular oder jede andere als Portlet realisierte Anwendung anzuzeigen.
Dieses Problem läßt sich im WebSphere Portal nur vordergründig „lösen“: Soll aus dem Content auf eine Anwendung, die über ein Portlet angebunden ist, verlinkt werden, so öffnet sich beim Klicken eine neue Portalseite. Diese Vorgehensweise ist jedoch von der Navigationstruktur her nicht stringent, weil der Nutzer der ursprünglichen Portalseite nach dem Aufruf der Anwendung auf einer anderen Portalseite ist als vorher und damit den Überblick verliert.
Anforderungen der Redakteure berücksichtigen
Portal-Redakteure stellen nicht nur Anforderungen in punkto Flexibilität bei der Gestaltung von Contentseiten. In der Regel müssen sie Inhalte auch mehrsprachig einstellen, Content für einzelne Abteilungen oder Bereiche personalisieren und ein effizientes zentrales Management der im Portal veröffentlichten Links durchführen können. Auch diese Anforderungen lassen sich mit den von den WCMS-Herstellern mitgelieferten Standard-Content Portlets nicht erfüllen.
Effiziente und nachhaltige WCMS-/Portal-Integration von RADIGEWSKI Informatik
RADIGEWSKI Informatik sorgt auf der Grundlage langjähriger Erfahrung in den Bereichen Content Management und Portal-Lösungen für eine effiziente und nachhaltige WCMS-Integration in das WebSphere Portal. Dazu wird die komplette Portal-Navigationsstruktur als eigene Portalseite angelegt, die sich dann nicht mehr aus einem Navigations-Portlet speist, sondern aus dem Portal. Jede Content-Seite erhält damit eine eigene Portalseite.
Voraussetzung für diese Vorgehensweise ist ein implizites oder explizites Mapping der gesamten Content-Struktur des WCMS. Mit diesem Mapping wird im WCMS jedem Inhalt genau die Portalseite zugewiesen, auf der er erscheinen soll. Damit erhalten die Redakteure die benötigten Freiheitsgrade, weil der Seitenaufbau im Portal individuell den Bedürfnissen des jeweiligen Contents angepasst werden kann. Und damit Portalseiten zum Beispiel weitere Portlets mit anderen Anwendungen beinhalten oder sogar in einem anderen Layout erscheinen können. Auch die Portal-Nutzer profitieren, weil sie zusätzliche Anwendungen nutzen können, ohne in eine andere Navigationsstruktur „umgeleitet“ zu werden.
Durch den Einsatz der von RADIGEWSKI Informatik entwickelten intelligenten Content Display Portlets lassen sich weitere Vorteile realisieren. So kann die Verwaltung von Leserechten vollständig über das Portal abgewickelt werden, lassen sich Inhalte problemlos mehrsprachig im Portal anzeigen ohne sie über separate Webseiten pflegen zu müssen und können Inhalte verlinkter Seiten auf der gleichen Portalseite angezeigt werden. Die aufwändige doppelte Pflege der Navigationsstrukturen von WCMS und Portal entfällt, weil die Redakteure ausschließlich im WCMS arbeiten.
Lesen Sie hier, mit welchem bewährten Projektablauf wir bei der WCMS-/Portal-Integration vorgehen, auf welche Technologien wir dabei setzen und für wen wir in der Vergangenheit bereits erfolgreich tätig waren.