SignalR – Real-time Web mit SharePoint

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)
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
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
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
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
Bild:StartUp Code

SimpleChat

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

Bild: SimpleChat als WebPart in 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
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
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
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
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
Bild: Aufbau vom Projekt

Zusätzliche .NET Libraries (DLLs)

Bild: SignalR Client Bibliothek
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)
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
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
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
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
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
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
Bild: Der WHOTSHub

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

Der WebPart

Bild: WebPart ascx Control
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
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.

Erfahren Sie mehr

Office 365 Groups als Evolution von SharePoint?
Blog
Blog

Office 365 Groups als Evolution von SharePoint?

Zusätzlich zu SharePoint erlauben die Office 365 Groups es mir als Anwender, schnell und einfach neue Gruppen anzulegen und selbständig Benutzer hinzuzufügen.

Das neuste Mitglied der Office 365 Familie: Delve
Blog
Blog

Das neuste Mitglied der Office 365 Familie: Delve

Microsoft legt nach: Mit Delve startet eine neue Form des Suchens und des Auffinden von Dokumenten und Informationen.

Nov
07
Webcast mit Microsoft: Das Intranet zu Ende gedacht
Webinar
Webinar

Webcast mit Microsoft: Das Intranet zu Ende gedacht

Am 07. November findet erneut eines unserer Webinare gemeinsam mit Mircosoft statt. Das Thema dieses Mal: Das Intranet zu Ende gedacht – Die Informationszentral...

Auf Goldkurs in der Cloud
News
News

Auf Goldkurs in der Cloud

Die novaCapta hat ihren Partnerstatus bei Microsoft zusätzlich vergoldet: Auch in der Sparte Cloud Productivity haben wir jetzt den Goldstatus.

Valo ist neuer Partner der novaCapta für Intranets
News
News

Valo ist neuer Partner der novaCapta für Intranets

Durch die Partnerschaft mit Valo, dem Ready-2-Go Intranet-Baukasten aus Finnland baut die novaCapta ihr Angebot bei der Umsetzung von schnellen und funktionalen...

novaCapta auf der Fachtagung für Interne Revision
Event
Event

novaCapta auf der Fachtagung für Interne Revision

Das Expertenteam der novaCapta präsentiert am 15. und 16. November ihre innovative Audit Management Lösung auf dem DIIR-Kongress in Dresden. Besuchen Sie unsere...

Mit der HoloLens ein Stück Berlin nach Köln holen
News
News

Mit der HoloLens ein Stück Berlin nach Köln holen

Im Rahmen eines zweitägigen Hackathons haben sich einige Mitarbeiter der novaCapta der Microsoft HoloLens und dem Thema Mixed Reality gewidmet. Dabei haben wir...

Oct
12
PCDE #3 Event am 12.10. in Stuttgart
Event
Event

PCDE #3 Event am 12.10. in Stuttgart

Developer und IT-Professionals aufgepasst! Das novaCapta-Team nimmt am 12. Oktober am Pitch Club Developer Edition (PCDE) in Stuttgart teil. Dort stellen wir Ih...

May
04
novaCapta auf der dotnet Cologne
Event
Event

novaCapta auf der dotnet Cologne

In nächster Nachbarschaft zu unserem Kölner Büro findet am 04. und 05. Mai die dotnet Cologne im KOMED statt. Wir von der novaCapta sind auch dabei.

Theobald Software neuer Partner von novaCapta
News
News

Theobald Software neuer Partner von novaCapta

Komplexe SAP-Prozesse direkt in SharePoint durchführen – dabei unterstützt uns unser neuer Partner Theobald Software.

novaCapta ist Sitecore Implementierungspartner
News
News

novaCapta ist Sitecore Implementierungspartner

Sitecore ist die führende.NET Enterprise Content- und Customer Experience Management-Plattform für ihr strategisches Online-Marketing. novaCapta hat sich als Si...

Jan
25
Webcast mit Microsoft: Fit für die digitale Arbeitswelt
Webinar
Webinar

Webcast mit Microsoft: Fit für die digitale Arbeitswelt

Die digitale Transformation und die Veränderung der Arbeitswelt ist längst in vielen Unternehmen und in den öffentlichen Einrichtungen angekommen. Dennoch stell...