Problematik

Die Problematik bei einem solchen Nachrichten-Dienst ist, dass das Erkennen von Zuständen und das Senden von Nachrichten aus Stabilitätsgründen nicht in demselben Service stattfinden sollte. Es wird also eine Lösung benötigt, in welcher diese Abgrenzung logisch gelöst wird.
 

Lösungsansatz

Aus der Problematik ergibt sich der Lösungsansatz grundsätzlich automatisch.

Es werden zwei Services dazu benötigt:

• Service für das Erkennen von Zuständen
• Service für das Senden von Nachrichten

Service Workflow

Service für das Erkennen von Zuständen                             

Bei dem «Service für das Erkennen von Zuständen» verwenden wir eine Konfiguration, in der die Zustände definiert sind. Als Beispiel «CPU Auslastung». Diese definieren wir mit dem Wert «> 90 %» und einem Scheduler von 30 Sekunden. Nun kontrolliert der Service alle 30 Sekunden, ob die CPU Auslastung grösser als 90 % ist. Sobald dieser Zustand eintrifft, erstellt der Service einen Eintrag in der Tabelle «Incident» und prüft dies in 30 Sekunden erneut.

Sinnvoll hierbei wäre sicher, dass man das Auftreten von Zuständen in definierten Zeiträumen zusammenfasst und nicht alle 30 Sekunden neue «Incident»-Einträge erzeugt.
 

Service für das Senden von Nachrichten

Der «Service für das Senden von Nachrichten» hingegen prüft lediglich, ob sich neue Einträge in der Tabelle «Incident» befinden und arbeitet diese ab. Das heisst, er nimmt sich den ersten Eintrag mit dem definierten Status für «offen» und selektiert sich dazu die erfassten Abonnenten/Subscriber (die Benutzer oder Gruppe, welche die Nachricht zu diesem «Incident» erhalten sollen). Diesen schickt der Service eine Nachricht mit dem definierten Nachrichten-Typen (PopUp/Email/SMS), setzt den Status auf «verarbeitet» und beginnt mit dem nächsten «Incident».
 

ERD

Anbei ein Beispiel für den Aufbau des Entity-Relationship-Diagramms für dieses Nachrichten-Dienst-Beispiel.

Fazit

Es gibt natürlich viele Arten von Möglichkeiten, um einen solchen Nachrichten-Dienst zu konzeptionieren und zu entwickeln. Dennoch wird das Konzept meist in etwa gleich aussehen, sofern eine getrennte Service-Architektur verwendet wird.

Ein Beitrag von Alain Germann, Software Architekt, QUIBIQ Schweiz AG