Real-time Web mit SharePoint (SignalR)

Update: Es gibt einen weiteren Teil der Serie, wo die erstellten Beispiele noch einmal angepasst werden. Dieser Beitrag wurde leider nie veröffentlicht. Der Beispiel Source Code - ganz unten ist der Link - ist daher gehend bereits angepasst.

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, gewehrleistet in der Regel dass Änderungen innerhalb der Anwendung allen Clients zeitnah bereitgestellt werden.
Diese Methodik ist nicht neu und wird in der Real-time Computing schon länger eingesetzt, z.B. über den Observer Design Pattern. Beim Observer Design Pattern gibt es einen „Beobachter“, alle Clients registrieren sich bei diesem Beobachter. Bei Änderungen an einem Datensatz/Zustand der Quelle, werden die Registrierten Clients vom Observer „benachrichtigt“.

Der Wunsch für immer aktuelle Daten in der Webanwendung ist nicht neu, es gab bereits Lösung Ansä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. Hierbei ist der impact der Netzwerkauslastung auf dem Server geringer als wie beim Polling, aber es wird trotzdem durch den Aufbau eines weiteren Kanals Last erzeugt.

Polling sowie Long-polling sind bedingt durch das http Protokoll (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 wo 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 Server-Seitig 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), ergo der Entwickler kann 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, ie keine Unterstützung)
• Forever Frame (fallback nur ie, ein IFrame mit einer stätigen 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.

Danach kann mit der Entwicklung gestartet werden, naja… fast.
Wir müssen IIS zuerst dazu bringen WebSockets zu verstehen, dafür muss die Rolle installiert werden.
Innerhalb des „Feature & Roles Wizard“ muss das WebSocket Protokoll angehakt werden.

Nachdem die Rolle installiert wurde, kann IIS auch das WebSocket Protokoll.

SignalR wie 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 kann, 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 der, 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 Feature diese 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 wir WebSocket verwenden.
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
Das ist das VS Projekt welches SignalR und alle benötigten Komponenten beinhaltet, diese Lösung kann unabhängig von SharePoint auf einer dedizierten IIS-WebSite bereitgestellt werden.

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

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

Die Lösung besteht aus 2 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 sehen ist, ist diese Lösung nicht für den Produktiv Betrieb 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.

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.

Falls ihr den Source Code selber testen möchtet, müsst ihr in den Zeilen 78 und 144 jeweils den Pfad zu eurer SignalR Installation anpassen, ansonsten wird die Anwendung nicht funktionieren.

In der Zeile direkt darunter (145) wird auf den Hub zugegriffen. Nachrichten an den Hub schicken wir in Zeile 174 und empfangen diese wiederum in Zeile 147.

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.

Das ist die komplette Anwendung.

What happens on this site
Mit „What happens on this site“ können wir nachverfolgen was auf unserer SiteCollection so alles passiert.

Die Anwendung besteht wie SimpleChat aus 2 Komponenten, aus 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).

Zusätzliche .NET Libraries (DLLs)

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.

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

Nach dem 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 3 EventReceiver die auf SiteCollection Ebene mit dem SiteCollection scoped Feature registriert werden.

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.

DieSignalRClientKlasse
DieSignalRClientKlassebeinhaltetnurdieSendMessageMethode,indereinKanalzumHubaufgebautwird(Zeile14).

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 Klassen-Name des Hub.
In Zeile 17 wird der Kanal zum Hub aufgebaut und in Zeile 18 wird dann die Hub Methode aufgerufen.

Der Hub
Befindet sich innerhalb des SignalRTest Visual Studio Projekts.

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.

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

Der WebPart

Falls ihr den Source Code selber testen möchtet, müsst ihr in den Zeilen 78 und 130 jeweils den Pfad zu eurer SignalR Installation anpassen, ansonsten wird die Anwendung nicht funktionieren.

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 Umsetzungs-Varianten sind jedoch sehr komplex.
Es sind viele Parameter und potenzielle Fallstricke vorhanden, die einen unbedachten Einsatz bestrafen könnten, also Vorsicht bei der Planung, Vorsicht bei der Auswahl des Zielsystems und Vorsicht bei dem Verfügbaren Protokoll.