Überprüfung der Deadline

[marlonschlosshauer]

Der Check ob ein Ticket die Deadline erreicht hat wäre im Frontend einfach. Kurzes Snippet das es lösen würde:

public getDeadlines(): Observables<Notification[]>  {
  return this.ticketService.getIssueForUser().pipe(
    map(issues => issues.filter(issue => (new Date().valueOf() > issue.deadline.valueOf()))),
    map(issues => issues.map(issue => new Notification(issue)))
  )
}

Ich finde es sollte eine Funktion des Backends sein, da die anderen Nachrichten ebenfalls im Backend generiert werden. Ich bin mir nicht sicher wo in der Frontend Architektur der Code aufgerufen werden würde. Nach dem AuthGuard ? In jeder Komponente ? @BenjaminKuerten wüsstest du wo es rein passen könnte ?

Ich glaube außerdem das das Frontend dann auch die Nachricht im Backend speichern muss. Ich erinnere mich daran das Nachrichten quittiert werden können, was heißen würde das die generierten Nachrichten auch in der Datenbank gespeichert werden sollten. @pheim1, @Namo2 sagt euch das noch was ?

[pheim1]

Da wir ja eh Messages in der Datenbank berücksichtigt haben, ist es kein Problem diese auch vom Backend generieren zu lassen. In meinem Praktikum gibt es für zeitabhängige Aufgaben so genannte Workflows. Ein Workflow kann viele Sachen machen (z.B. Ein Workflow an sich ist dann Abstrakt und die Konkrete Implementierung hängt vom Typ ab -> DeadlineWorkflow), aber auch eben die Generierung von Notification (das überprüfen der Deadlines z.B.) anstoßen. Die Infrastruktur für die Workflows könnte man schön mit Design Patterns (Factory, Strategy, Observer, ...) Implementieren.

Workflows haben ein Intervall indem sie ausgeführt werden, z.B. jede Stunde. Aber man kann ihn auch durch Code auslösen, z.B. wenn sich ein User anmeldet könnte es überprüft werden usw...

Was auch noch eine Lösung wäre ist, dass es im Backend code eine Routine gibt, die beim Start des Backends und bei der Erstellung/Änderung(Der Deadline) eines Tickets für jedes Ticket Timer startet, der dann eine WebSocket-Event an das Frontend sendet, welches dann die Notification in "echtzeit" im Frontend angezeigt werden kann.

[marlonschlosshauer]

Die Workflow Idee gefällt mir. WebSocket etc. wäre dann noch ein nice-to-have. Das Intervall wäre auch human mit einem Tag. Wüsstest du wie du so einen Workflow zu ASP.NET hinzufügst ?

[pheim1]

Workflows werden als Dokument in der Workflow-Collection gespeichert.

Im Backend gibt es dann eine while schleife, die jede x Sekunden alle Workflows von der Datenbank sucht, welche "nextExecution"-Date in der Vergangenheit liegt, folglich ausgeführt werden müssen.

Ein manuelles triggern des Workflows kann dann ein Service machen, der die "nextExecution" auf aktuelle Zeit oder Vergangenheit legt. Die While schleife tut es dann ja im nächsten Intervall ausführen.

[Luk-T]

Was auch noch eine Lösung wäre ist, dass es im Backend code eine Routine gibt, die beim Start des Backends und bei der Erstellung/Änderung(Der Deadline) eines Tickets für jedes Ticket Timer startet, der dann eine WebSocket-Event an das Frontend sendet, welches dann die Notification in "echtzeit" im Frontend angezeigt werden kann.

Ich versuche mal, am Wochenende einen Prototypen dafür zu bauen. Wenn das nicht zu kompliziert ist, würde ich das über die Workflows bevorzugen, weil man das Überschreiten der deadline dann sofort merkt und nicht wie bei einem Workflow eben etwas verzögert.

[pheim1]

Ich versuche mal, am Wochenende einen Prototypen dafür zu bauen. Wenn das nicht zu kompliziert ist, würde ich das über die Workflows bevorzugen, weil man das Überschreiten der deadline dann sofort merkt und nicht wie bei einem Workflow eben etwas verzögert.

Danke dir Lukas, für die WebSocket Geschichte würde ich dir SignalR empfehlen.

[marlonschlosshauer]

Workflows werden als Dokument in der Workflow-Collection gespeichert.

Im Backend gibt es dann eine while schleife, die jede x Sekunden alle Workflows von der Datenbank sucht, welche "nextExecution"-Date in der Vergangenheit liegt, folglich ausgeführt werden müssen.

Das hört sich nach mehr an als wir bräuchten, aber ich habe prinzipiell nichts dagegen.

Was auch noch eine Lösung wäre ist, dass es im Backend code eine Routine gibt, die beim Start des Backends und bei der Erstellung/Änderung(Der Deadline) eines Tickets für jedes Ticket Timer startet, der dann eine WebSocket-Event an das Frontend sendet, welches dann die Notification in "echtzeit" im Frontend angezeigt werden kann.

Ich versuche mal, am Wochenende einen Prototypen dafür zu bauen. Wenn das nicht zu kompliziert ist, würde ich das über die Workflows bevorzugen, weil man das Überschreiten der deadline dann sofort merkt und nicht wie bei einem Workflow eben etwas verzögert.

Super! WebSocket wäre optional. Setzt du dafür auch ASP.NET ein oder wie würde dein Projekt aussehen ?

[pheim1]

Workflows werden als Dokument in der Workflow-Collection gespeichert. Im Backend gibt es dann eine while schleife, die jede x Sekunden alle Workflows von der Datenbank sucht, welche "nextExecution"-Date in der Vergangenheit liegt, folglich ausgeführt werden müssen.

Das hört sich nach mehr an als wir bräuchten, aber ich habe prinzipiell nichts dagegen.

Sag mal einen Gegenvorschlag wie man dann eine Notification generiert, sobald eine Deadline überschritten ist ?

[Luk-T]

Ich würde versuchen den Prototyp möglichst klein zu halten. Ich würde glaube ich auf das Frontend erstmal komplett verzichten. Im Backend werden Requests zum Erstellen/Ändern der Ticket simuliert. Ansonsten werde ich die Architektur, die Philipp beim Workshop gezeigt hat nachbauen (Service, Repository), und auf Websockets erstmal verzichten - Erstmal nur eine Konsolenausgabe, wenn die Deadline erreicht wird.

[marlonschlosshauer]

Sag mal einen Gegenvorschlag wie man dann eine Notification generiert, sobald eine Deadline überschritten ist ?

Die Grundidee wäre die gleiche. Workflows in einer Collection zu speichern wäre für mich aber zu viel. So wie ich das verstanden habe macht ihr das weil ggf. mehrere Workflows vorhanden sind. Zur Abstraktion und möglicherweise auch zur Quittierung für ein verteiltes System. Falls wir noch eine Aktivität finden die asynchron vom Server abgearbeitet werden müsste, würde ich den Mehrwert von dem Speichern in der DB in einer Collection sehen.

[Luk-T]

Ein erster Prototyp steht => Ordner TicketDeadline. Feedback ist natürlich erwünscht.

Das Grundprinzip ist, dass für jedes Ticket ein asynchroner Task läuft, der beim Ablauf der Ticketdeadline aufgeweckt wird.

Im Kern steht das Interface IEvent, das Eine Zeit angibt und einen Callback hat (OnTimeReached), der um diese Zeit ausgeführt werden soll. Die Klassen in Scheduler.cs sorgen dann dafür, dass das Event zu dieser Zeit auch wirklich ausgelöst wird und ermöglichen außerdem das Cancellen eines Events (falls z.B eine neue Deadline für das Ticket gesetzt wird. Als konkrete Implementierung für IEvent gibt es im Moment nur das TicketDeadlineEvent. In der Klasse wird auch eine Liste aller aktuell laufenden Deadlines verwaltet. In Program.cs werden zum Testen TicketDeadlineEvents erstellt, sodass das Anlegen / Ändern eines Tickets simuliert wird.

Ich war zu faul, MongoDB irgendwo aufzusetzen und wollte auch nicht Philipp's einfach so Datenbank verwenden, deswegen fehlt in TicketDeadlineEvent.OnTimeReached noch der eigentlich Inhalt. Ebenfalls fehlt eine Funktion, die beim Starten des Backends ein TicketDeadlineEvent für jedes Ticket in der Datenbank erstellt, aber ich denke das wäre beides keine besonders großen Probleme wären.

[marlonschlosshauer]

Gute Arbeit Lukas. Das IEvent könnten wir auch für ein TicketStartEvent verwenden, um ein Ticket bei seinem Startzeitpunkt zu starten.

Was haltest du von dem Scheduler @pheim1 ?

[pheim1]

Was haltest du von dem Scheduler @pheim1 ?

Auch ich finde deinen Prototyp sehr gut Programmiert. Könnten wir "so", gerne im Projekt implementieren.

[marlonschlosshauer]

Sehr schön. Ich würde den Prototyp erst mal auf Eis legen. Nachdem wir unseren "Vertical Slice" implementiert haben verwenden fügen wir den Code dann in unsere Codebase ein.