Als einer unserer Kunden vor einiger Zweit mit dieser Anforderung auf uns zu kam, habe ich noch vermutet, dass diese Art der Navigation ein Spezialfall ist und Microsoft deshalb keine out-of-the-box-Lösung in Form eines Navigation Providers dafür bereitstellt.

Der von Microsoft präferierte Ansatz diesbezüglich geht über die Verwendung der MySite als zentrales Medium, um anhand der Mitgliedschaften eine farmweite Navigation zu allen Websitesammlungen (im Rechtekontext) zu ermöglichen. Diesem Ansatz zu Grunde liegt die zentrale SharePoint-Suche.

Allerdings bevorzugen einige Kunden die “Klassische”, hierarchische Navigation direkt auf der Portaleinstiegsseite. Aus diesem Grund möchte ich diesem interessanten Thema einen Artikel widmen.

Eine Hauptnavigation (Top-Navigation) ist im SharePoint-Umfeld in der Regel drei-stufig aufgebaut:

1. Der Navigation Provider: Stellt die Gesamtmenge aller Navigationsknoten für die Navigation bereit

2. Die Data Source: Bietet eine Filterung/Einschränkung der Gesamt-Knoten-Menge aus dem Provider 

3. Das ASPX Menü Control: UI-Komponente, um die Navigationspunkte darzustellen.

Wenn eine Erweiterung der klassischen SharePoint Hauptnavigation ansteht, dann kann diese auf einer dieser drei Ebenen oder auf mehreren Ebenen gleichzeitig erfolgen.  

Der Websitesammlungsübergreifender Ansatz:

Das Erweitern der Hauptnavigation für einen Websitesammlungsübergreifenden Ansatz sollte in den meisten Fällen auf der Ebene des Navigation Providers stattfinden, da in der Regel die Optik der Navigation und die Einstellungsmöglichkeiten nicht beeinträchtigt werden sollen. Bei der Realisierung dieser Navigationserweiterung gibt es diverse Aspekte, die unbedingt berücksichtigt werden müssen.

Fachliche Aspekte:

Ein wichtiger, fachlicher Aspekt bei der Realisierung einer Websitesammlungsübergreifenden Hauptnavigation ist die Anordnung der zusätzlichen Websitesammlungs-bezogenen Navigationsknoten. Denkbare Szenarien wären eine flache Anordnung am Ende der Navigation oder eine Strukturierung bspw. nach Themengebiet oder „verwalteten Pfaden“.

Um eine Strukturierung zu realisieren, kann auf erster Hierarchie-Ebene in der Portalstruktur ein “Anker”-Knoten (bspw. Website) angelegt werden, der über ein konfiguratives Mapping  alle Websitesammlungen oder nur die unter einem verwalteten Pfad zugeordnet bekommt.

Beispielhaftes Mapping:
Navigationsknoten (Website)-Name = “news”  zu  “Verwalteter Pfad”-Name = “news

Sobald der Navigation Provider während der Verarbeitung einen Portal-Knoten findet, dem er einen verwalteten Pfad (via Namen) zuordnen kann, dann werden die zusätzlichen Websitesammlungs-Navigationsknoten (alle Websitesammlungen unter dem verwalteten Pfad auf die der User auf dem Zugriff hat) diesem Navigationsknoten hinzugefügt.

Technische Aspekte:

Aus technischer Sicht ist die Performanz einer Websitesammlung-übergreifenden Navigation die größte Herausforderung. Daher ist dieser Ansatz auch mit einigen Kompromissen verbunden! Generell ist zu sagen, dass mit wachsender Anzahl der Websitesammlungen die Performanz immer weiter abnimmt. Die Hauptursache dafür liegt in der Notwendigkeit der Iteration über alle Websitesammlungen und der Validierung der Berechtigungen für den jeweiligen Anwender, damit nur Links in der Navigation auftauchen, die in den Berechtigungskontext des Anwenders gehören.

Zu empfehlen ist zudem, die User-Berechtigungen nur auf der Root-Website der jeweiligen Websitesammlung zu prüfen. Die Validierung der Berechtigung auf Subwebsite-Ebene wäre ein wahrer Performanz-Killer! Selbst ohne Subwebsite-Validierung kommt man über die Verwendung eines performanten Caching-Mechanismus nicht hinweg.

Da ein Navigation Provider in der web.config registriert werden muss, läuft dieser auch nur in deren Kontext und kann daher nicht Webapplikationsübergreifend arbeiten!

Aus der Praxis:

Für unseren Kunden wurde die Hauptnavigation exakt nach dem hier skizzierten Ansatz  erweitert. Für jeden verwalteten Pfad in der Webapplikation wurde eine Subwebsite mit gleichem Namen  auf oberster Ebene im Portal angelegt. Der Navigation-Provider prüft alle Websitesammlungen aus dem (via Mapping zugewiesenen) verwalteten Pfad und hängt die Links unter den Website-Navigationspunkt im Menü.

Das Auslesen der Websitesammlungen findet nur beim ersten Aufruf der Seite statt und wird dann im Cache (pro User) gehalten. Nach zwei Minuten Inaktivität gibt der Cache die Objekte wieder frei, so dass auch  neue Websitesammlungen zeitnah angezeigt werden.

Aus programmiertechnischer Sicht erbt der eigene Navigation Provider von der Klasse “PortalSiteMapProvider” und hat somit schon mal alle Navigationsknoten, die sich aus der Portal-Struktur ergeben. In der überlagerten Methode “GetChildNodes” können nun die zusätzlichen Websitesammlungsknoten ermittelt und der Gesamtmenge der Navigationsknoten hinzugefügt werden.

Fazit:

Der Ansatz ist charmant und funktioniert bereits produktiv ohne Beanstandung. Es muss allerdings bewusst sein, dass eine Websitesammlung ein relativ mächtiges SharePoint-Konstrukt ist und eine dynamische, Websitesammlungsübergreifenden Hauptnavigation nicht die performanteste Lösung sein kann! Allerdings gibt es auch keine wirkliche Alternative!

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Time limit is exhausted. Please reload the CAPTCHA.