Notlage Topic:
Kafka Topic: Notlage.t
"idOrigin" ist die ID des Events, aus dem wir die Notlage generiert haben. Diese sollte eine UUID sein.

{  
  "notlageId":1,  
  "dvp":
      {"dvpID":1442},  
  "status":"IN_BEARBEITUNG",   
  "idOrigin":"4",  
  "geloest":false,  
  "bestaetigt":false,  
  "extraData":
      {"data":"zusatz Info"},  
  "offen":true,  
  "notlageBestaetigung":
      {"istBestaetigt":false,"notlageBestaetigungid":null},  
  "notlageLoesung":
      {"istGeloest":false,"notlageLoesungid":null}  
}  

BP Kontext BeN Topic (Bezugsperson, Kontext: "Behebung einer Notlage"-Topic):
Kafka Topic: BPMeta.t

Dies hier ist nur das grobe Konzept, was auf dem Kafka Topik gepostet werden soll.

bp_id
bp_id_ext
kontaktdaten
anwesenheitList
kommunikationskanalList

Ungewöhnliches Verhalten liegt vor

Event wird von externen Domänen generiert und informiert darüber, dass sich eine DVP ungewöhnlich verhält. Daraus bildet der MS-Notlage eine Notlage, über die BPs informiert werden sollen.

DVP befindet sich an ungewöhnlichem Ort

Event wird von externen Domänen generiert und informiert darüber, dass sich eine DVP an einem für sie ungewöhnlichen Ort befindet. Daraus bildet der MS-Notlage eine Notlage, über die BPs informiert werden sollen.

Bezugsperson verändert

Event informiert über geänderte Daten zu einer Bezugsperson, wird von externen Domänen generiert. Der MS-BP prüft, ob Informationen des Events relevant sind.

Notlage wurde angelegt

MS-Notlage generiert eine Notlage und teilt diese über den Notlage Topic Event-Stream. MS-BP lauscht darauf und benachrichtigt die entsprechenden Bezugspersonen über die Notlage. Dieses Event wird auch für Änderungen an der Notlage genutzt.

Notlage wurde bestätigt Externer API-Call führt dazu, dass der Zustand der Notlage sich ändert. Es wird eine aktuelle Version veröffentlicht.

Daten der Bezugsperson in dem Kontext unserer Domäne haben sich geändert

MS-BP generiert bei Änderung an einer Bezugsperson ein Event, auf das der MS-FA lauscht.

API-CALL: Bezugsperson hat eine Notlage bestätigt und schickt sich an, diese zu lösen

MS-BP nutzt die API "Notlage bestätigen" des MS-Notlage, um mitzuteilen, dass eine Notlage bestätigt wurde.

API-CALL: Bezugsperson hat eine Notlage in der echten Welt gelöst

MS-BP nutzt die API "Notlage lösen" des MS-Notlage, um mitzuteilen, dass eine Notlage gelöst wurde.

Version 1

1. Notlage wird erzeugt
2. BP-Service/N-Service holen sich die Notlage
3. Benachrichtigung an BPs senden
4. Benachrichtigung wird angenommen
5. Notlage als "angenommen" kennzeichnen
6. BP-Service/N-Service holen sich die Notlage
7. Notlage wird gelöst
8. Notlage ist gelöst α. Verfügbarkeit geändert β. neue Informationen zu BP-Service

Version 2

Änderung zu Version 1:

• Es gibt nicht nur einen Owner des Notlage-Topics der veröffentlicht.
  -> Notlage-Microservice lauscht auf Topics, die Notlagen erkennen(Ungewöhnliches Verhalten, ungewöhnlicher Ort). Veröffentlicht in Notlagen-Topic
• Bezugspersonen-Microservice pushed auf Bezugspersonen-Topic und ist nicht Owner
  -> BP-Microservice lauscht auf Bezugsperson-Topic und veröffentlicht in BP Metadaten
  -FA nicht berücksichtigt, da nicht Teil des Szenarios
  -> FA berücksichtigt

Version 3

Änderung zu Version 2:

• API-Call umbenannt, da Notlage nur BP intern bestätigt wird, aber in dem Notlagen-Microservice gelöst wird.

• Leichte Anpassung.

• Saubere Darstellung.

• Legende hinzugefügt.

Version 4 Änderung zu Version 3:

• Benennung angepasst.
  • Topic Bezeichnung mit anderen Teams abgeglichen
• Notlage bestätigen API hinzugefügt
• BP konsumiert BP-Core Daten statt FA

Abbildung s.o.