Suche

über alle News und Events

 

Alle News

 

Wir haben während unseres...

Weiterlesen

Azure Functions benötigen oft einen...

Weiterlesen

In der heutigen Zeit nehmen Erreichbarkeit,...

Weiterlesen

Viele unserer Kunden überlegen derzeit, was sie in...

Weiterlesen

Lösungsansatz – was benötigt man dafür:

  • Einen...
Weiterlesen

Es gibt im Preview die Möglichkeit Azure Blob...

Weiterlesen

Die wichtigste Konferenz zu Integration auf der...

Weiterlesen

In diesem Blogeintrag werden wir drei sichere und...

Weiterlesen

Im vergangenen Jahr war bei uns in Hamburg viel in...

Weiterlesen

Heutzutage werden Token für die Authentifizierung...

Weiterlesen

How-to: Async Service-Based Notification Concept – Identify incidents and send notifications

Bei dem Thema «Async Service-Based Notification Concept» sehen wir uns ein Konzept für das Erkennen von spezifisch erwarteten Zuständen und das Senden von dafür definierten Nachrichten an gewünschte Abonnenten an. Dieses Konzept wird sowohl eine serviceorientierte als auch eine asynchrone Verarbeitung unterstützen. Wir nennen das Ganze in diesem Artikel «Nachrichten-Dienst».

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 

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz