---

Liste aller BPs. (Suchfragment)
Informationen zu einer spezifischen BP
Wert der Zuverlässigkeit

Liste aller Kommunikationskanäle
Formular zum bearbeiten von Kommunikationskanälen
Verfügbarkeit Kalender Blacklist
Verfügbarkeit Kalender Whitelist
Verfügbarkeit Kalender Blacklist und Whitelist bearbeitbares Formular

Liste aller aktiven Notlagen in bezug zu einer BP (Vermerk: Link zu der UI Diskussion)
Informationen zu einer spezifischen Notlage
Aktionsmöglichkeiten zu einer Notlage
Chatfunktion zu einer speziellen Notlage (Vermerk: Wie umsetzen)

Allgemein sind alle UIs Teil eines Frontends, eines großen Frontend Programms, bezogen auf das ganze Projekt. Es gibt Verlinkungen zum Hauptmenü von jeder UI Komponente. Die UI Komponenten sind Komplette Webseiten, auf die Verlinkt werden kann vom Hauptmenü. Übergeordnet muss eine andere Domaine für die Verwaltung der Berechtigungnen und Login Daten zuständig sein. Die Backends stellen nur Funktionen bereit und keine eigenen Ui Komponenten.

Es gibt 4 Komponenten
1: Notlage
Diese Seite informiert über die Vorliegende Notlage. Die Seite kann nur über einen speziellen Link erreicht werdeb, der den Bps zugesendet wird. Es werden Funtkionalitäten der MSs Notlage und BP benötigt. Diese werden über Rest-Aufrufe verwendet. Es werden Nachrichten an die Bps gesendet. Diese informieren darüber, dass eine Notlage vorliegt. Diese Benachrichtigung beinhaltet den Namen der betroffenen DVP, sowie einen Link zu der Web-Oberfläche. Funktional sollen Status Informationen abrufbar sein, welche über den Zustand der DVP und der Notlage informieren. Weihterhin soll es möglich sein, dass sich eine BP als "Zuständig" einträgt, und meldet, wenn die Notlage behoben ist.

Zusätzlich zum Inhalt des Bildes soll auhc eine Karte angezeigt werden, wlehce die Position der DVP anzeigt und, wenn angebracht, die zurückgelegte Route. Dazu muss auf Inhalte der Domain Teams "Ungewöhnliche Route" und "Ungewöhnliches Verhalten" zugegriffen werden. Weiterhin gibt es eine Chatfunktion. Der Verlauf wird nicht gespeichert.

2: BP Kalender
Hier wird nur der Ms BP benötigt. Es gibt keine weiteren Abhängigkeiten. Andere MSs können über Rest Aufrufe oder die published Events alle Informationen über die verfpgbarkeit der BP erlangen. Es werden keine fertigen Komponenten bereitgestellt. Es werden keine weiteren Aspekte von anderen MSs verwendet. Es kann zum Hauptmenü zurück navigiert werden.

3: BP Kommunikationskanäle
Hier wird nur der Ms BP benötigt. Es gibt keine weiteren Abhängigkeiten. Hier können die BPs ihre Kommunikationskanäle mit Kontaktdaten konfigurieren. Es kann zum Hauptmenü zurück navigiert werden.

4: Fachliche Administration
Hier wird nur der MS Fachlicher Administrator benötigt. Es werden keine weiteren MSs benötigt. Der FA kann die Zuverlässigketien der BPs abrufen.

Aus unserer Sicht machen eine UI für einen "Self-Contained System (SCS)" weniger Sinn, da es in unserer Domäne Überschneidungen zu anderen Domänen gibt. Beispiele sind hierfür Kontaktdaten, die einer Bezugsperson zugeordnet sind. Für einen Benutzer ist es ein Hindernis unterschiedliche Kontaktdaten in voneinander abgetrennten UIs zu bearbeiten. Zudem können keine allgemeinen UI-Komponenten von anderen Domänen genutzt werden.

Aus unserer Sicht würde ein solches Vorgehen sinn machen. Hier durch wäre die Möglichkeit gegeben eine UI zu erstellen, um Nutzerdaten für Bezugspersonen anzupassen. Wir sehen die Domäne "Dementiell Veränderte Personen" als führend wenn es um persönliche Daten von Bezugspersonen geht. In das UI welches sich mit den persönlichen Daten befasst könnten die die UI-Fragmente eingebettet werden. Für unseren Kontext würde es bedeuten, dass wir ein UI-Fragment erstellen über welches Kontaktdaten einer Bezugsperson bearbeitet werden können und in dem Verfügbarkeiten in einen Kalender eingetragen werden können.

Die Daten sind aktuell fachlich nur für unsere Domäne interessant. Durch den Micrfrontend-Ansatz bleibt die Hoheit der Komponenten in userer Domäne. Aus Sicht des Nutzer existiert nur ein Ort an dem alle persönlichen Daten angepasst werden.

Ein weiterer Punkt der für den Ansatz spricht ist, dass wir auch von allgemeinen UI-Fragmenten provitieren können. Ein Beispiel hierfür ist die Darstellung einer DVP auf einer Karte. Durch eine allgemeines UI-Fragment, dass die Position einer DVP auf einer Karte anzeigt, kann Entwicklungsaufwand minimiert werden. Wir sehen das Projektteam „Ungewöhnliche Route draußen" als führend zum Entwickeln einer solchen UI-Komponente.

Nein, da wir sonst die Unabhängigkeit verlieren. Wir möchten entscheiden wann unsere fachlich stark gebunden UIs deployed und ausgeliefert werden.

Microservice BP

• Erstellen von UI-Fragmenten, die in das UI eingebunden wird in dem Nutzerdaten angepasst werden(vermutlich Projektteam "Dementiell Veränderte Personen")

Notlage

• Fachlich alleine in unserem Kontext relevant
• Dementsprechend ist die UI in unserer Hand und muss auch nicht anderen bereitgestellt werden.
• Nutzen einer Karten-UI-Fragements, wenn in einer Notlage ein ungewöhnlicher Ort/Route enthalten ist(vermutlich Projektteam "Ungewöhnliche Route draußen").

Fachliche Administrator

• UI komplett losgelöst von anderen Services
• Bewertung der Zuverlässigkeit von BPs steht fachlich nur mit unserer Domäne in Verbindung.