Dashboard — SP Notify

Benachrichtigungskanäle

Scheduler-Intervall

API-Endpunkte

Phasen des Alarmlebenszyklus

Architektur-Highlights

So funktioniert SP Notify

Phase 1

Alarmerstellung & Webhook-Registrierung

Benutzer konfigurieren Alarme über die SPFx ListViewCommandSet-Erweiterung in der SharePoint-Listen-Symbolleiste. Das Backend speichert das Abonnement und registriert automatisch einen SharePoint-Webhook.

SPFx ruft transparent ein Bearer-Token über AadHttpClient ab
Payload enthält AlertType, ChangeType, DeliveryMethod und LastChangedToken
Backend aktualisiert AlertInfo und ruft bei Bedarf WebhookService.RegisterWebhookAsync() auf
Gibt 201 Created mit dem vollständigen gespeicherten IAlertInfo zurück

Phase 2

Änderungserkennung via Webhooks

Wenn sich ein SharePoint-Listenelement ändert, sendet SharePoint innerhalb von Sekunden eine SpNotificationPayload an das Backend. Das Backend speichert ein TriggerEvent und gibt sofort 200 OK zurück.

clientState = "AlertID-{id}" verknüpft den Webhook mit einem bestimmten Alarm
Fire-and-forget-Schreibvorgang in [DS.SP.Notify.TriggerEvent]
SharePoint erfordert eine Bestätigung unter einer Sekunde — hier findet keine Verarbeitung statt
Bei erster Zustellung wird SubscriptionID im AlertInfo-Datensatz bestätigt

Phase 3

Geplante Benachrichtigungsverarbeitung

Alle 5 Minuten verarbeitet SchedulerNotification alle ungelesenen TriggerEvents pro Mandant. Der ChangeManager vergleicht SharePoint via CSOM und sendet Benachrichtigungen an den richtigen Kanal.

Ereignisse werden vor der Verarbeitung nach Listen-GUID dedupliziert
CSOM ruft Änderungen seit LastChangedToken als Delta-Cursor ab
AlertType + ChangeType-Filter nach CSOM-Vergleich angewendet
SPNotifyLog geschrieben und LastChangedToken nach jeder Zustellung weitergerückt

Architektur

Multi-Mandanten-Isolation

Ein Backend bedient unbegrenzt viele SharePoint-Mandanten. Jeder Mandant hat seine eigene Entra-Registrierung, Anmeldedaten und Datenbankzeilen. Die Isolation wird auf jeder Ebene durchgesetzt — keine Datenlecks zwischen Mandanten.

SPTenantID-Header identifiziert den Mandanten bei jeder HTTP-Anfrage
TokenValidatorCache verwaltet OIDC-Signaturschlüssel pro Mandant
Alle SQL-Abfragen enthalten ein TenantID-Prädikat — keine mandantenübergreifenden Abfragen
Scheduler iteriert Mandanten unabhängig mit separaten ChangeManager-Instanzen

Sicherheit

Authentifizierung & Token-Flow

Alle API-Aufrufe sind mit Azure AD Bearer-Tokens gesichert. Die SPFx-Erweiterung ruft Token transparent über SharePoints Token-Brokering ab — kein manueller OAuth-Flow im Frontend-Code erforderlich.

AadHttpClient verwaltet Token-Abruf und -Erneuerung automatisch
Jede Backend-Funktion validiert das Token unabhängig — kein API-Gateway
SPTenantID-Header neben dem Token für Multi-Mandanten-OIDC-Auflösung erforderlich
TokenValidatorCache cacht Signaturschlüssel pro Mandant, um wiederholte Abrufe zu vermeiden

Vollständiger Funktionsumfang

Alles, was SP Notify kann

Alarmkonfiguration

Alarmkonfiguration & -verwaltung

🔔

Benutzerdefinierte Alarmtitel & Ziele

Jeder Alarm hat einen benutzerdefinierten Titel und eine explizite Empfängerliste (SendAlertsTo).

📋

AlertType-Filterung

Benachrichtigung bei allen Änderungen, nur hinzugefügten, nur aktualisierten oder nur entfernten Elementen.

👤

ChangeType-Urheberfilterung

Filtern nach dem Autor der Änderung — jemand, jemand anderes oder jemand anderes, der von Ihnen erstellte oder zuletzt geänderte Elemente geändert hat.

👁

Ansichtsbeschränkte Alarme

Benachrichtigungen auf Elemente in einer bestimmten SharePoint-Listenansicht beschränken mit FilterViewId.

📅

Ablaufdaten

Alarme können ein ExpirationDate erhalten, nach dem sie nicht mehr ausgelöst werden, und jederzeit aktiv/inaktiv geschaltet werden.

Zustellung

Zustellungskanäle & Planung

📧

E-Mail via Microsoft Graph

HTML-formatierte E-Mails via POST /v1.0/users/{sender}/sendMail. Empfängernamen werden via Graph aufgelöst.

💬

SMS via HTTP-Anbieter

Anbieteragnostische SMS-Zustellung. Optional wird die URL des geänderten Elements mit dem SendUrlInSms-Flag angehängt.

🟣

Microsoft Teams Adaptive Cards

An ein bestimmtes Team + Kanal via Bot Connector gesendet. Team und Kanal werden bei der Alarmerstellung vom Benutzer ausgewählt.

🟢

WhatsApp via Business API

Sofortnachrichten an das WhatsApp-Konto des Empfängers via WhatsApp Business API. Kein Corporate-Client erforderlich.

⚡

Sofortige Benachrichtigungen

Verarbeitung im nächsten Scheduler-Zyklus (≤5 Minuten). Keine Bündelungsverzögerung für Sofortbenachrichtigungen.

📆

Tägliche & wöchentliche Zusammenfassungen

Änderungen über einen Tag oder eine Woche in eine einzige Zusammenfassungsbenachrichtigung aggregieren mit konfiguriertem SummaryDay und SummaryTime.

Infrastruktur

Backend & Infrastruktur

🔗

SharePoint-Webhook-Abonnementverwaltung

Das Backend registriert und verfolgt automatisch SharePoint-Webhook-Abonnements pro Liste via WebhookService.RegisterWebhookAsync().

🔄

CSOM Change-Token-Delta-Cursor

Verwendet SharePoints LastChangedToken als persistenten Cursor, um nur neue Änderungen seit dem letzten Benachrichtigungslauf abzurufen.

🗄

Azure SQL-Persistenz

Alle Alarmabonnements, Trigger-Ereignisse, Webhook-Einträge und Zustellungsprotokolle in Azure SQL mit mandantenspezifischen Abfragen gespeichert.

⏰

Timer-gesteuerter Scheduler

SchedulerNotification läuft als Azure Functions-Timer-Trigger alle 5 Minuten und verarbeitet alle Mandanten nacheinander.

🧹

TriggerEvent-Deduplizierung & Bereinigung

Mehrere schnelle Änderungen an derselben Liste werden vor der Verarbeitung nach Listen-GUID dedupliziert. Ereignisse werden nach erfolgreicher Zustellung gelöscht.

Sicherheit

Sicherheit & Multi-Mandantenfähigkeit

🔐

Azure AD / Entra JWT-Validierung

Jede HTTP-Funktion validiert das Bearer-Token gegen die OIDC-Signaturschlüssel des Mandanten. Kein zentrales API-Gateway erforderlich.

🏢

Unbegrenzte Mandantenunterstützung

Eine Backend-Bereitstellung, unbegrenzt viele Mandanten. Jeder Mandant hat isolierte Anmeldedaten, DB-Zeilen und Scheduler-Kontext via TenantConfiguration.

⚡

TokenValidatorCache

OIDC-Metadaten und Signaturschlüssel pro Mandant im Speicher gecacht, um wiederholte Roundtrips zu Azure AD bei jeder Anfrage zu vermeiden.

🎫

OBO & zertifikatsbasierte MSAL-Token

Backend ruft On-Behalf-Of-Token für Webhook-Registrierung und zertifikatsbasierte Client-Anmeldedaten für Scheduler-CSOM-Aufrufe ab.

🔑

Transparentes SPFx-Token-Brokering

AadHttpClient verwaltet den gesamten Token-Abruf über SharePoints Brokering — keine manuellen OAuth-Flows oder Weiterleitungen im Frontend-Code.

API-Oberfläche

REST-API-Kurzübersicht

Alle Endpunkte — Bearer-Token + SPTenantID-Header erforderlich

Vollständige Dokumentation →

POST/api/alertmngr/create201

POST/api/alertmngr/update200

POST/api/alertmngr/delete204

GET/api/alerts4list/{listGuid}200

GET/api/alerts/{id}200

GET/api/alertlog/{alertId}200

POST/api/configmngr/create201

POST/api/configmngr/update200

POST/api/configmngr/delete204

GET/api/configmngr/tenant/{tenantId}200

Systemübersicht & Funktionen