Ausgangslage
Im Rahmen eines Migrationsprojekts von SharePoint 2010 nach SharePoint Online durften wir eine bestehende Lösung – welche nachfolgend beschrieben wird – neu konzipieren und mit modernsten Technologien umsetzen. Die Lösung wird vollständig auf Microsoft Azure Services betrieben und ist somit zukunftssicher und state of the art.
Anforderungen
Unser Kunde, welcher im Bausektor tätig ist, betreibt eine SharePoint Online Plattform, auf welcher er mit seinen Subunternehmen Dokumente zu den jeweiligen Bauabschnitten austauscht. Nebst dem Kollaborationsbereich gibt es einen weiteren Bereich, welcher nur für interne Zwecke genutzt wird. In beiden Bereichen werden täglich mehrere hundert Dokumente erstellt bzw. geändert. Über diese Änderungen müssen die jeweiligen Stakeholder wie Bauingenieure, Geologen sowie auch interne Mitarbeiter täglich per E-Mail informiert werden.
Die bestehende Lösung, welche noch für SharePoint 2010 konzipiert wurde, war veraltet, langsam sowie fehleranfällig und konnte somit nicht 1:1 für die neue Umgebung verwendet werden. Zudem wäre sie nicht cloudfähig gewesen, was wiederum den Ansprüchen unseres Kunden nicht gerecht wurde.
Entscheid und Umsetzung
Als Plattform für den Bau unserer Lösung entschieden wird uns für Azure Functions. Hier kann man kleine Code-Stücke oder eben «Funktionen» laufen lassen, ohne sich dabei Gedanken über die Infrastruktur machen zu müssen. Azure Functions unterstützt eine Vielzahl von Sprachen wie beispielsweise C#, JavaScript oder PowerShell. Eine vollständige Übersichtsliste sämtlicher unterstützter Sprachen findet man hier.
Unsere Lösung namens «AlertMailer» haben wir mit C# auf dem kundeneigenen Office 365 Tenant realisiert. Für den Versand der teilweise bis zu 1000 E-Mails pro Tag wird aufgrund der einfachen Anbindung der E-Mail Service SendGrid verwendet.
Die Authentifizierung gegenüber SharePoint Online erfolgt nicht via Benutzername und Passwort sondern über eine Application im Azure AD. Die Autorisierung und Authentifizierung geschieht dann via OAuth 2.0. Bei erfolgreicher Authentifizierung wird ein Zugriffstoken für SharePoint Online ausgestellt, welcher den Zugriff dann via App-ID und Token autorisiert.
Die eigentliche Azure Function ist in mehrere Module (intern, extern) aufgebaut und somit beliebig erweiterbar. Jedes Modul hat einen Input und 0-n Outputs. Der Informationsaustausch unter den einzelnen Modulen wird mittels Queues und Tabellen (NoSQL) realisiert. Diese Speichertechnologien werden von Azure Functions nativ zur Verfügung gestellt und können somit relativ einfach verwendet werden. Das Handling übernimmt hierbei Azure und die In- und Outputs werden via Dependency Injection in das Modul geladen. Als Starttrigger dient ein Timer, welcher zu einer bestimmten Zeit am Tag, die geänderten Dokumente abfragt. Die einzelnen Module laden anschliessend die seit dem letzten Crawl geänderten Dokumente via Such-API von SharePoint, laden deren Rechte, extrahieren die einzelnen User und sammeln die Dokumente pro User und verpacken diese in eine E-Mail. Das anschliessende Versenden dieser E-Mails wird die bereits angetönt über SendGrid realisiert.
Module
*CrawlChangedContentTrigger
Die beiden Crawlermodule nehmen die jeweiligen Suchabfragen (interner und externer Bereich) mit den jeweiligen Properties vor. Der Start dieser Module ist ein TimerTrigger. Die Skalierung ist horizontal, weshalb auch beliebige andere Crawler hinzugefügt werden könnten.
AlertMailerItemQueueTrigger
Liest die ChangedItemTable aus und sammelt für jedes Dokument die entsprechend berechtigten User, welche für dieses Dokument notifiziert werden sollen.
EmailNotifications
Hier wird die E-Mail erstellt und als zusammengefasster Bericht pro User verschickt.
Queues und Tables
ChangedItemQueue
Speichert die Anzahl der gecrawlten Items der jeweiligen Suchabfragen. Deren einzige Funktion ist das Anstossen des Moduls AlertMailerItemQueueTriggers.
ChangedItemTable
Speichert sämtliche Informationen (Managed Properties) jedes einzelnen gecrawlten Dokuments. Die Tabelle wird bei jedem neuen Suchlauf gelöscht.
UserDocumentMappingQueue
Hierbei handelt es sich um eine simple Zuweisung Benutzer:Dokumente in 1:n.
SettingsTable
Hier sind die Settings für den Timestamp des letzten Crawls des jeweiligen Crawlermoduls eingetragen.
Nachfolgend ein Codeauschnitt:
Die Benutzer der Plattform erhalten nun täglich eine Zusammenfassung der für sie relevanten Dokumente per E-Mail.
Sonstiges
Die Konzeption und Realisierung der Lösung ergab einen Aufwand von rund 5 Tagen. Die neue Lösung ist im Vergleich zur alten um Welten schneller. Dauerte der Durchlauf der einzelnen Module früher um die 8 Stunden, so benötigt das Abfragen der Änderungen sowie der Versand der E-Mails heute nur wenige Sekunden. Die für den Kunden monatlich anfallenden Kosten sind ebenfalls sehr moderat. Der Betrieb der Functions (Azure consumption) kostet pro Monat einige wenige Rappen! Dagegen fallen die zusätzlichen monatlichen Kosten von $9.95 für SendGrid schon fast hoch aus 😉
Beitrag teilen
Geschrieben von
Sandro Ineichen
Projektleiter
Profil anzeigen