SharePoint als RSS Generator

von Roland Rickborn

Übersicht

RSS Logos strömen aus einer Box mit SharePoint Logo

Bei einem großen Kunden wurde für ca. 45.000 Mitarbeiter ein neues Intranet auf Basis von Microsoft SharePoint 2013 On-premise eingeführt. Im Intranet befinden sich sowohl redaktionelle Inhalte der globalen Unternehmenskommunikation, als auch Inhalte von lokalen Kommunikationsabteilungen und anderer Unternehmensorganisationen. Die redaktionell erstellten Inhalte werden von verschiedenen Teams in mehreren Subsites gepflegt. Alle Subsites befinden sich in einer einzigen Site-Collection.

Problemstellung

Die redaktionell erstellten Inhalte sollen mittels RSS Feed für andere Anwendungen zugänglich gemacht werden. Damit soll es z.B. möglich sein, diese Inhalte in einer App anzuzeigen. Im Rahmen einer Evaluation wurden verschiedene Möglichkeiten ermittelt, wie dabei solche Feeds erstellt werden können. Bevorzugt wurde nach einer Out-of-the-box-Lösung gesucht, da an der On-premise Installation möglichst nichts verändert werden soll. Zu erwähnen ist allerdings, dass jQuery und die jQuery Library SPServices [1] auf der Zielplattform zur Verfügung stehen.

Die Anwendung, die den RSS Feed lesen soll, darf als Eigenentwicklung betrachtet werden. Hier ist eine beliebige Implementierung möglich. Bevorzugt wäre natürlich ein richtiger RSS Feed.

Lösungsansatz

SharePoint ist schon seit Langem in der Lage, seine Inhalte als RSS Feed zu exportieren [2]. Allerdings ist dieser Lösungsansatz auf einzelne Listen oder Bibliotheken beschränkt. Im vorliegenden Fall befinden sich die infrage kommenden Inhalte zwar alle in einer einzigen Site-Collection, aber sie sind auf mehrere Subsites verteilt.

Beispielsweise gibt es eine Subsite Germany und eine Subsite France. Beide Subsites enthalten ihrerseits weitere Subsites, z.B. für jeden Monat. Nun soll es einen einzigen RSS-Feed geben, der alle Seiten aus allen Seiten-Bibliotheken der Subsite Germany und allen darunter liegenden Subsites exportiert. Die in [2] aufgezeigte Lösung kann also nicht angewendet werden.

Die folgenden beiden Lösungsansätze wurden verfolgt:

  1. Verwendung der RSS Funktion des Content Query Web Parts (CQWP) [3]
  2. Per SPServices über die SharePoint Search Query API die entsprechenden Inhalte ermitteln und als XML Feed an die Anwendung durchreichen (Beschreibung folgt im nächsten Blogpost)

Vor- und Nachteile der CQWP Lösung

Der Lösungsansatz mit dem CQWP hat einige Vor- und Nachteile. Er ist zu bevorzugen, weil er vollständig aus Standardkomponenten besteht. Das Webpart gehört zur Standardinstallation und kann mittels Library Type und Filter umfangreich konfiguriert werden. Außerdem verfügt es über eine RSS-Funktion, die bereits einen richtigen RSS Feed bereitstellt. Dieser kann von der Zielanwendung problemlos interpretiert werden, sofern eine RSS Library zur Verfügung steht.

Als Nachteil ist zu nennen, dass das Webpart Probleme hat, wenn Versionierung und Freigabeprozesse im Spiel sind. So erkennt es z.B. Minor Versions nicht. Das führt dazu, dass unveröffentlichter Inhalt im RSS Feed erscheint. Gerade im redaktionellen Umfeld hat man aber genau damit zu tun. Abbildung 1 zeigt die Einstellungen zur Versionierung in den infrage kommenden Seiten-Biliotheken.

Und in Abbildung 2 sieht man die Einstellung, mit der angegeben wird, welche Anwender Entwürfe (Draft) sehen dürfen. Das CQWP berücksichtigt diese Einstellungen leider nicht. Die in [4] angegebenen Tipps scheinen nicht zu funktionieren.

Schon alleine die Tatsache, dass das CQWP die expliziten Einstellungen der Seiten-Bibliothek nicht berücksichtigt, disqualifiziert es eigentlich als Lösung für unser Problem. Ein weiterer Nachteil des Webparts besteht in seiner schlechten Performance-Statistik. Wie in [5] zu lesen ist, kann es bei Quellen mit mehr als 5.000 Elementen zu Performanceproblemen mit dem Webpart kommen.

Webpart einrichten und verwenden

Trotz der genannten Nachteile wurde die Eignung des Webparts weiter untersucht. Der große Vorteil des CQWP besteht darin, dass es Inhalte aus mehreren Sites gleichzeitig anzeigen kann, siehe Abbildung 3.

Wie in Abbildung 3 zu sehen ist, kann das Webpart:

  • Elemente aus allen Sites einer Site-Collection anzeigen
  • Elemente einer bestimmten Site und aller Subsites anzeigen oder
  • Elemente einer bestimmten Liste anzeigen.

Nachdem man sich auf eine Site oder Liste festgelegt hat, muss man in den Properties des Webparts definieren, welcher Content Type angezeigt werden soll, siehe Abbildung 4.

Bei der Auswahl des anzuzeigenden Content Types in den Einstellungen des Webparts, wie in Abbildung 4 gezeigt, stehen alle verfügbaren Inhaltstypen der Site zur Verfügung, also sowohl vordefinierte, als auch selbst angelegte. In diesem Abschnitt können auch Einstellungen hinsichtlich der Zielgruppe (Target Audience) angegeben werden.

In Abbildung 5 sieht man die Möglichkeit, wie Filter konfiguriert werden. Die Konfiguration ist ähnlich zur Konfiguration einer Listenansicht (Abschnitt Filter). Es können maximal drei Filter angegeben werden, die sich mit UND oder ODER verknüpfen lassen.

Zuletzt kann in den Einstellungen noch angegeben werden, wie der gefundene Inhalt angezeigt und ob er als RSS Feed zur Verfügung gestellt werden soll, siehe Abbildung 6.

Ergebnis

Wurde die Option Enable feed for this web part aktiviert, dann stellt das Webpart einen RSS Feed zur Verfügung. Zusätzlich wird in der rechten unteren Ecke in der Ausgabe des Webparts das bekannte RSS Icon angezeigt. Damit hat jeder Anwender die Möglichkeit, die Adresse des Feeds zu ermitteln und ihn zu abonnieren, siehe Abbilungen unten.

Ausblick

Das CQWP kann ein sehr nützliches Webpart sein! Sollen große Mengen von Elementen angezeigt werden, muss Vorsicht geboten sein. Die Probleme mit der Sichtbarkeit von Entwürfen lassen sich vermutlich in den Griff bekommen, wenn man bereit ist, seine Umgebung anzupassen (z.B. Version als Managed Data einstellen und danach filtern!).

In meinem nächsten Posting stelle ich einen zweiten Lösungsansatz vor, der auf SPServices basiert.

Kategorien: Sharepoint

Zurück