Real-time Web mit SharePoint (SignalR)

//Real-time Web mit SharePoint (SignalR)

Real-time Web mit SharePoint (SignalR)

Was ist Real-time Web?

„Real-time Web“ definiert sich aus Technologien und Vorgehensweisen, die dem Benutzer ohne jegliche Interaktion Änderungen an der Quelle zeitnah bereitstellen.

Was bedeutet das konkret?
Eine Webanwendung, die eine Real-time Web Komponente beinhaltet, gewährleistet in der Regel, dass Änderungen innerhalb der Anwendung allen Clients zeitnah bereitgestellt werden.
Diese Methodik ist nicht neu und wird im Real-time Computing schon länger eingesetzt, z.B. über den Observer Design Pattern. Beim Observer Design Pattern gibt es einen „Beobachter“ und alle Clients registrieren sich bei diesem Beobachter. Bei Änderungen an einem Datensatz/Zustand der Quelle werden die Registrierten Clients vom Observer benachrichtigt.

Der Wunsch nach jederzeit aktuellen Daten in der Webanwendung ist nicht neu, es gab bereits diverse Lösungsansätze um diese Anforderung zu erfüllen. Ein einfaches Beispiel wäre z.B. in bestimmten Intervallen die Quelle per Ajax anzufragen und bei Änderungen die aktuelle Ansicht per JavaScript anzupassen. Das ist eine typische Client-zu-Server Verbindung; es wird ein Kanal in eine Richtung eröffnet, vom Client zum Server. Diese Vorgehensweise nennt sich „Polling“. Durch die ganzen (ggf. unnötigen) Anfragen entsteht allein durch die Request Header und Response zusätzlicher Netzwerk Load auf dem Server.

Ein weiterer Ansatz ist das „Long-Polling“, hier wird nach dem Aufruf vom Client ein weiterer Kanal zum Server geöffnet. Sobald sich ein Zustand ändert, wird der Kanal abgebrochen und nochmal aufgebaut bis sich wieder der Zustand der Quelle ändert. Hier ist der Einfluss auf die Netzwerkauslastung auf dem Server geringer als beim Polling, aber es wird durch den Aufbau eines weiteren Kanals trotzdem Last erzeugt.

Polling sowie Long-Polling sind bedingt durch das HTTP (halbduplex) nicht wirklich als Methoden für das Real-time Web anzusehen, es sind eher Workaraounds für ein Problem.

Mit dem WebSocket-Protokoll kommt ein neuer Standard ins Spiel und zwar ein fullduplex Protokoll, bei dem ein einziger Kanal in beide Richtungen aufgebaut wird (bidirektional). Der Client baut zusätzlich keine weiteren Kanäle zum Server auf, d.h. die Auslastung auf dem Server ist gegenüber den genannten Polling-Methoden deutlich geringer. Änderungen am Zustand der Quelle werden vom Server an die registrierten Clients bereitgestellt.

Beispiele

Traditionelles Web (Client -> Server)

1.      Ein Benutzer öffnet eine Seite mit Inhalt

2.      Der Autor der Seite öffnet die Seite zeitgleich mit dem Benutzer

3.      Der Autor nimmt Änderungen im Inhalt vor und speichert die Seite ab, der Benutzer bekommt von den Änderungen nichts mit.

4.      Der Benutzer aktualisiert die Seite (z.B. per F5 im Browser) und erhält die Änderungen, die der Autor getätigt hat.

Real Time Web (bidirektional)

1.      Ein Benutzer öffnet eine Seite mit Inhalt

2.      Der Autor der Seite öffnet die Seite zeitgleich mit dem Benutzer

3.      Der Autor nimmt Änderungen im Inhalt vor und speichert die Seite ab, der Benutzer bekommt die Änderungen zeitnah angezeigt.

 

Browser mit WebSockets Unterstützung

Laut can i use werden die unten aufgeführten Browser in den entsprechenden Versionen unterstützt.

SignalR

SignalR ist eine .NET Bibliothek mit der Webanwendungen mit Real-time Web Kommunikation umgesetzt werden können. Die Kommunikationsschnittstelle wird Hub genannt. Unser Client baut eine bidirektionale Streck zu dem Hub auf und kommuniziert mit diesem.
Sofern client- sowie serverseitig verfügbar, wird WebSocket als Protokoll verwendet. Falls der Client oder der Server WebSocket nicht beherrschen sollte, wird auf weitere Methoden zurückgegriffen (z.B. Long-Polling), der Entwickler kann dementsprechend alle Fälle mit einer Implementierung abdecken.
Die genaue Beschreibung sowie die Voraussetzungen für die einzelnen Fallbacks kann hier nachgelesen werden.

Für die Server-seitige WebSocket Unterstützung muss mindestens Windows Server 2012 R2 oder Windows 8 mit installiertem .NET Framework 4.5 verwendet werden. Zusätzlich muss im IIS das WebSocket Feature installiert werden.

Sofern ein WebSocket Handshake nicht zu Stande kommen sollte, können folgende Fallbacks verwendet werden:

  • Server Sent Events (Fallback, sofern von Client unterstützt, i.e. keine Unterstützung)
  • Forever Frame (Fallback, ein IFrame mit einer stetigen Verbindung wird auf Seite platziert)
  • Long Polling (Fallback, falls alles andere nicht anwendbar ist)
    SignalR kann ganz einfach über das Nuget Paket „Microsoft.AspNet.SignalR“ einem Visual Studio Projekt hinzugefügt werden.
    Über Nuget werden die Abhängigkeiten – und das sind nicht gerade wenige – komplett aufgelöst.

Bild: SignalR Abhängigkeiten

Bevor mit der Entwicklung gestartet werden kann, muss IIS zuerst dazu gebracht werden, WebSockets zu verstehen. Dafür muss die Rolle installiert werden.
Innerhalb des „Feature & Roles Wizard“ muss das WebSocket Protokoll angehakt werden.

Bild: IIS WebSocket aktivieren

SignalR mit SharePoint verheiraten

SignalR ist eine .NET Library. Theoretisch können wir SignalR innerhalb von SharePoint hosten.
Das bedeutet, dass wir eine SharePoint Full Trust Farm Solution erstellen können und dieser SignalR inkl. aller Abhängigkeiten hinzufügen können.
Damit der IIS und SharePoint SignalR verwenden können, sind Änderungen innerhalb der WebConfig nötig. Auf dieser Seite werden die einzelnen Einträge gut erläutert. Ein Vorteil dieser Lösung ist, dass man sich um keine weiteren Zertifikate, IIS/Server, etc. kümmern muss, weil eben alles innerhalb von SharePoint läuft.
Die Nachteile überwiegen jedoch bei dieser Methode. Der Load innerhalb von SharePoint steigt dadurch und je nach Anzahl der Clients kann sich das ziemlich schnell auf die Performance auswirken. Ein weiterer Nachteil ist, dass eine Lösung in dieser Form ziemlich unflexibel ist, da diese nur in einer On-Premise SharePoint Farm laufen kann.

Unsere Beispiel-Solution „nC.SP.SignalR“ übernimmt beim Aktivieren des WebApplication Features die Aufgabe der Erstellung der WebConfig Einträge automatisch, es müssen lediglich die Handler manuell auskommentiert werden.

<!– remove name=”ExtensionlessUrl-ISAPI-4.0_64bit” / –>

<!– remove name=”ExtensionlessUrl-ISAPI-4.0_32bit” / –>

Die direkt in SharePoint integrierte Lösung ist suboptimal, da der Load des jeweiligen w3wp Prozesses ansteigt, trotz dass WebSocket verwendet wird.
Daher ist das ausgelagerte Hosten von SignalR die bessere Variante. Hierfür kann ein normales Web Projekt Template in Visual Studio verwendet werden.
Die Beispiele „nC.SP.SimpleChat“ und „nC.SP.WHOTS“ verwenden jeweils einen externen Hub, der innerhalb der „SignalRTest“ Solution implementiert wurde.
Durch diese Methode ist ein Betrieb in O365 auch möglich, z.B. als Provider Hosted Add-In und die Leistung auf dem SharePoint Server wird dadurch nicht beeinflusst.

Beispiele

In diesem Abschnitt werden wir unsere Beispiel-Solution näher betrachten.

SignalRTest

Dies ist das VS-Projekt welches SignalR und alle benötigten Komponenten beinhalte t. Diese Lösung kann unabhängig von SharePoint auf einer dedizierten IIS-WebSite bereitgestellt werden.

Bild: Aufbau des Projekts

Das Projekt ist recht einfach aufgebaut. Innerhalb von Configuration befindet sich die StartUp Datei für OWIN mit der die SignalR Route beim Start registriert wird. Unter Hubs befinden sich die Hubs, mit denen die Anwendungen letztendlich kommunizieren werden.

Bild:StartUp Code

SimpleChat

SimpleChat ist, wie der Name bereits suggeriert, eine einfache Chat-Anwendung für SharePoint.

Bild: SimpleChat als WebPart in SharePoint

Die Lösung besteht aus zwei Komponenten, zum einen die SharePoint Solution (nC.SP.SimpleChat), die den WebPart beinhaltet und zum anderen die dedizierte SignalR (SingalRTest) Lösung. Wie bereits aus dem Screenshot zu erkennen ist, ist diese Lösung nicht für den Produktivbetrieb gedacht. Es ist eher eine Spiel-Lösung, die inkl. aller Komponenten weniger als eine Stunde Entwicklungszeit verbraucht hat. Der Source Code kann hier heruntergeladen werden.

Der WebPart

Die nC.SP.SimpleChat Solution ist ziemlich einfach aufgebaut. Konkret beinhaltet diese nur einen WebPart und die benötigten JavaScript Dateien.

Bild: Aufbau vom Projekt

Da innerhalb dieser Solution auf keinen Backend Code zugegriffen wird, hätte diese Lösung auch in Form eines Add-Ins umgesetzt werden können.
Alles passiert innerhalb des ASCX Controls.

Bild: Anpassungen Zeile 78 & Zeile 144

Falls der Source Code selbst getestet werden soll, muss in den Zeilen 78 und 144 jeweils der Pfad zu der entsprechenden SignalR Installation angepasst werden.

Bild: SignalR und die Chatlogik

In der Zeile direkt darunter (145) wird auf den Hub zugegriffen. Nachrichten an den Hub werden in Zeile 174 geschickt und in Zeile 147 empfangen.

Der SignalR Hub

Wie bereits erwähnt, befindet sich der Hub für diese Lösung in einer eigenen Solution (SignalRTest), die unabhängig von SharePoint innerhalb eines IIS betrieben werden soll. Der Hub für dieses Beispiel ist sehr simpel aufgebaut, alle registrierten Clients erhalten alle die gesendeten Nachrichten.

Bild: Der SignalR Hub für SimpleChat

Das ist die komplette Anwendung.

 

What happens on this site

Mit „What happens on this site“ kann nachverfolgt werden, was auf der SiteCollection alles passiert.

Die Anwendung besteht, wie SimpleChat, aus zwei Komponenten, einer SharePoint Solution und der dedizierten SignalR Umgebung.
Der Source Code kann hier heruntergeladen werden.

Die SharePoint Komponenten

Anders als die SimpleChat Lösung werden hier mehrere SharePoint Standard Komponenten verwendet. Ein WebPart für die Anzeige, mehrere EventReceiver auf SiteCollection Ebene und die JavaScript Dateien aus dem Layouts Ordner. Auch hier hätte man ein Add-In erstellen können (provider hosted inkl. remote EventReceiver).

Bild: Aufbau vom Projekt

Zusätzliche .NET Libraries (DLLs)

Bild: SignalR Client Bibliothek

Die EventReceiver in der Anwendung kommunizieren mit dem SignalR Hub. Um per Backend-Code auf SignalR zugreifen zu können, benötigen wir die Microsoft.AspNet.SignalR.Client Library, die wiederum die Newtonsoft.Json Library benötigt.
Beide Libraries werden über unsere nC.SP.WHOTS SharePoint Solution zur Verfügung gestellt.

Bild: Einbinden der Bibliotheken innerhalb des SharePoint Pakets (Solution/WSP)

Zusätzlich muss für die Newtonsoft.Json Library ein webconfig Eintrag erstellt werden, dies bewerkstelligen wir über ein WebApplication scoped Feature.

Bild: WebApplication Feature für die Modifikation der WebConfig

Nachdem das Feature auf der Ziel-WebApplication aktiviert wurde, kann unser Code auf die SignalR Client Library zugreifen und einen Kanal zum Hub öffnen.

Die EventReceiver

Die WHOTS Anwendung beinhaltet insgesamt drei EventReceiver, die auf SiteCollection Ebene mit dem SiteCollection scoped Feature registriert werden.

Bild: SiteCollection Feature

Item Events

  • ItemAdded
  • ItemUpdated
  • ItemDeleted
  • ItemCheckedIn
  • ItemCheckedOut
  • ItemUncheckedOut
  • ItemAttachmentAdded
  • ItemAttachmentDeleted

List Events

  • FieldAdded
  • FieldDeleted
  • FieldUpdated
  • ListAdded
  • ListDeleted

Site Events

  • WebDeleted
  • WebMoved
  • WebProvisioned

Jedes ausgelöste Ereignis ruft die SignalRClient.SendMessage Methode auf, die wiederum die Informationen an den SignalR Hub weiterleitet.

Bild: Ein Beispielevent

Die SignalRClient Klasse

Die SignalRClient Klasse beinhaltet nur die SendMessage Methode, in der ein Kanal zum Hub aufgebaut wird (Zeile14).

Bild: Die Client Logik

In der Zeile 14 muss die URL zum Hub angegeben werden. In Zeile 16 wird der Hub Proxy erzeugt, der Name vom Hub muss exakt genauso eingegeben werden, wie der Klassenname des Hub.
In Zeile 17 wird der Kanal zum Hub aufgebaut und in Zeile 18 wird dann die Hub Methode aufgerufen.

Der Hub

Der Hub befindet sich innerhalb des SignalRTest Visual Studio Projekts.

 Bild: Der Hub in der SignalRTest Solution

Die Hub Implementierung unterscheidet sich marginal von der Umsetzung für die SimpleChat Anwendung. Es gibt eine Property vom Typ IHubContext, der im Standard Constructor der HubContext zugewiesen wird. Dieser HubContext wird für die Kommunikation von unserem Backend-Code (SignalRClient Klasse in nC.SP.WHOTS) aus benötigt.

Bild: Der WHOTSHub

Die SendEventMessage Methode schickt an alle registrierten Clients die von einem der Events übermittelte Nachricht.

Der WebPart

Bild: WebPart ascx Control

Falls der Source Code selbst getestet werden soll, muss in den Zeilen 78 und 130 jeweils der Pfad zur SignalR Installation angepasst werden, ansonsten wird die Anwendung nicht funktionieren.

Bild: Zeile 73 URL zu den dynamischen Hub Scripts

Die Logik ist ähnlich wie bei der SimpleChat Lösung und bedarf keiner weiteren Erläuterung.
Eine Verbindung zu SignalR wird aufgebaut, der Hub wird instanziiert und das war es schon.

Fazit

Die Integration von SignalR in SharePoint gestaltet sich recht einfach. Sofern mit der Real-time Web Materie bis dato kein Kontakt hergestellt wurde, kann durch den Einsatz der SignalR Bibliothek ziemlich einfach diese Lücke geschlossen werden.
Die Thematik an sich ist recht einfach, die Umsetzungsvarianten jedoch sehr komplex.
Es sind viele Parameter und potenzielle Fallstricke vorhanden, die einen unbedachten Einsatz bestrafen können, also Vorsicht bei der Planung, Vorsicht bei der Auswahl des Zielsystems und Vorsicht bei dem verfügbaren Protokoll.

Der Beispiel-Source Code kann hier heruntergeladen werden.

By | 2017-07-12T15:23:20+00:00 July 12th, 2017|SharePoint|0 Comments

About the Author:

Advanced Technology Specialist

Leave a Reply

%d bloggers like this: