Skip to content

Latest commit

 

History

History
134 lines (95 loc) · 4.64 KB

TEC-3822.md

File metadata and controls

134 lines (95 loc) · 4.64 KB

Ausgangslage

TEC-3655 "B4LCH - Monitoring 900 - mehrere Druckjobs von Serviceaufträgen auf Lieferscheindruck auf in Arbeit stehen geblieben"

Bei einigen Report Jobs geht der Status nicht auf Beendet, obwohl bis zum Output alles ausgeführt wurde.

Korrektur für TEC-3655

Unter anderem versuchen wir, die Report Job Events im Cluster zu synchronisieren, so dass sie alle Server erhalten:

  graph TD;
      A[Generierungsserver n]--Rptjob_Generierung_beendet-->B[Cluster Server 1];
      A--Rptjob_Generierung_beendet-->C[Cluster Server 2];
      A--Rptjob_Generierung_beendet-->D[Cluster Server 3];
      A--Rptjob_Generierung_beendet-->E[Cluster Server 4];
      B-->F[Gruppen Ausgabe 1];
      C-->G[Gruppen Ausgabe 2];
      D-->H[Gruppen Ausgabe 3];
      E-->I[Gruppen Ausgabe 4];
Loading

Effekt: Der Gruppen-Ausdruck erfolgt 4 Mal, statt nur 1 Mal. (Der Einzel-Ausdruck funktioniert nach wie vor).

TEC-3822 "B4LCH - Rechnungen werden 4 fach gedruckt (pro Server im Cluster)"

Korrektur für TEC-3822

Die Gruppen-Ausgabe wird direkt auf dem generierenden Server angestossen:

  graph TD;
      A[Generierungsserver n]--Generierung_beendet-->B[Server 1];
      A--Generierung_beendet-->C[Server 2];
      A--Generierung_beendet-->D[Server 3];
      A--Generierung_beendet-->E[Server 4];
      A-->O[Gruppen Ausgabe n];
Loading

Effekt: Der Gruppen-Ausdruck erfolgt nur noch 1 Mal.

Zoom auf den Generierungsserver

  graph TD;
      A[Generierungsserver]-->G[Generierung];
      G--Generierung_beendet-->C[Event Konsument = neuer Thread];
      C-->B[Update Generierungsstatus];
      G-->T[Test alle generiert?];
      T-->O[Gruppen Ausgabe];
Loading

Da der Update des Generierungsstatus in einem separaten Thread statt findet, kann es sein dass beim Test der Status auf der RDB noch nicht sichtbar ist.

Weitere Korrektur für TEC-3822

Der Generierungsstatus wird sofort persistiert:

  graph TD;
      A[Generierungsserver]-->G[Generierung];
      G-->B[Update Generierungsstatus];
      B--Generierung_beendet-->C[Event Konsument = neuer Thread];
      B-->T[Test alle generiert?];
      T-->O[Gruppen Ausgabe];
Loading

Somit findet der Test für die Gruppenausgabe immer die aktuellsten Stati vor.

Natürlich muss auch im Fehlerfall korrekt persistiert werden: TEC-3846 "PQ: Generierung bleibt auf in Arbeit bei ReportJobGruppe mit einem Fehlerhaften Reportjob" gab noch eine kleine Ehrenrunde.

2-fach Ausdruck, nur im LCH Cluster (TEC-3860)

Leider wurden in der Landi Schweiz Produktion die Rechnungen immer noch doppelt ausgedruckt.

Der Generierungsprozess für einen einzelnen Report Job sieht so aus:

  graph TD
     G(Start)
     G --> H(Status Rptjob auf 'In Bearbeitung' => Commit auf RDB)
     H --> I(Generierung)
     I --> J(*: Status Rptjob auf 'Generierung beendet' => Commit auf RDB)
     J --> K{Monitor noch OK?}
     K -->|Ja| O{Rptjob gehört zu einer Gruppe?}
     O -->|Nein| P(Einzel-Ausgabe anstossen)
     O -->|Ja| L(**: Stati aller Rptjob der Gruppe ab RDB einlesen)
     K -->|Nein| Y(Ende)
     L --> M{Gruppe bereit zur Ausgabe?}
     M -->|Nein| Y
     M -->|Ja| N(Gruppen-Ausgabe anstossen)
     N --> Y
Loading

Falls es die beiden letzten Rptjob in der Gruppe schaffen, ihren Status 'Generierung beendet' auf die RDB zu committen bevor sie alle Stati wieder einlesen, dann kann die Ausgabe 2 Mal erfolgen.

Die Lösung - vom Kunden bereits bestätigt - ist eine Objektsperre (Objlck) auf der Report Job Gruppe. Die RDB stellt sicher, dass nur eine einzige Sperre geschrieben werden kann:

  graph TD
     L(**: Stati aller Rptjob der Gruppe ab RDB einlesen)
     L --> M{Gruppe bereit zur Ausgabe?}
     M -->|Nein| Y(Ende)
     M -->|Ja| N{Kann die Rptjobgrp gesperrt werden?}
     N -->|Ja| O(Gruppen-Ausgabe anstossen)
     N -->|Nein| Y
     O --> Y
Loading

Nach Beendigung der (asynchron erfolgenden) Gruppenausgabe wird die Sperre auf der Report Job Gruppe wieder entfernt.

Zusammenfassung

  • Durch Anstossen der Ausgabe auf dem generierenden Server (Sender statt Empfänger) verhindern wir mehrfachen Output.
  • Durch sofortiges Persistieren des Generierungsstatus (Sender statt Empfänger) liefern wir den Nachfolgern die korrekte Information.
  • Durch eine Objeksperre auf der Report Job Gruppe stellen wir sicher, dass im Cluster die Gruppe nur 1 Mal augegeben wird

Alle Korrekturen sind in den folgenden Frame Versionen enthalten:

  • 57.0.0
  • 56.0.1
  • 55.0.3
  • 54.0.3 (TEC-3860 vorbreitet auf 54.0-patch)
  • 53.0.3

Wir sind zuversichtlich, dass diese Korrekturen auch zu einer Verbesserung des ursprünglichen Problems beitragen. Dies muss in der Produktion jedoch noch bestätigt werden.