Suche

über alle News und Events

 

Alle News

 

Durable Function ist eine Erweiterung der...

Weiterlesen

Wir haben eine gute, vor allem spannende und hoch...

Weiterlesen

Am 09.05.2022 wurde ein Artikel von Microsoft...

Weiterlesen

Neben den altbekannten Logic Apps (Consumption),...

Weiterlesen

Im Jahr 2022 fallen eine Reihe von .Net Versionen...

Weiterlesen

SAP in die Power Platform integrieren – In einem...

Weiterlesen

Bicep Templates benutzen eine deklarative Syntax...

Weiterlesen

In BizTalk gibt es einige Alternativen, wie...

Weiterlesen

Wir sind auf ein seltsames Phänomen bei einem...

Weiterlesen

Nach der Migration konnten in VS 2019 „normale“...

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