Files
votianng/docs/CRON-MIGRATION.md
Sven 33aa4b3682 Erweitere Workflows und Statusmails und bereinige Stadtbote-Tasks
Übernehme die PHP-Fachanpassungen für Foto-Workflows, Mail-Empfänger, Fahrzeugdaten, Nachbearbeitung und PZM-Festpreise.

Beschränke Cron-Funktionen auf Stadtbote, verbessere Java-Typsicherheit und Nullbehandlung und aktualisiere Tests und Dokumentation.

Erhöhe die Backend-Version auf 0.2.1 und passe Maven-Ressourcen sowie VS-Code-Projekteinstellungen an.
2026-11-10 11:32:12 +01:00

8.1 KiB
Raw Permalink Blame History

PHP-Crontab → Stadtbote-Spring-Tasks

Stand: 27.10.2026. Grundlage der Zeitpläne ist die vom Betreiber bestätigte sysadmin/votian_admin/crontab_20211207.sav. Die Geschäftsregeln wurden mit den aktuellen Serverquellen unter 172.16.0.158:/data/0/votian-test/html abgeglichen. Der frühere lokale PHP-Bestand wurde nicht verwendet.

Verbleibender Stadtbote-Umfang

PHP-Aufruf NG-Gruppe Termin Europe/Berlin Verhalten
do_auto_logout_by_autorevokes courier-logout Jede halbe Stunde NL 3, mindestens zwei automatische Entzüge in 30 Minuten, keine Annahme/Ablehnung, numerische Standort-PLZ; Belegungsprüfung, LOGOUT, PDA-Kommando mit 16 Stunden Gültigkeit, Audit 143.
do_cron_STB_MAILS stb-compliance Mo–Fr 04:00 78 getrennte Tasks: 1710, 1623, 1717–1720, 1629 für NL 1–11; 1715 nur NL 8. Datumswarnungen und PBSG/COV/FZ/GDP/BMS-Filterpflege.
do_cron_export_SB sb-master-export Täglich 20:45 30 Tasks: Debitoren, Kreditoren, Fahrzeuge für NL 1–9 und 11. Originale Benutzer, RETRANS-Profile, Nummern und Dateinamen; Dateispeicherung, Änderungskennzeichen und FTP-Übergabe.
mysql_status.php mysql-status Alle fünf Minuten Zähler der konfigurierten Anwendungsdatenbank, Gesamt-/Intervallraten, 62 Tage Historie, monatlicher CSV-Download.
do_cron_monitor_replication · STB replication-monitor Alle 15 Minuten Vergleich erledigter Stadtbote-Aufträge; Alarm bei mehr als vier fehlenden Aufträgen oder Nichterreichbarkeit.

Das sind 111 einzeln protokollierte Tasks in fünf Gruppen. Die sechs separaten NG-Dauerdienste (Auftragsabschluss, Daueraufträge, Statusmail, Angebote, Angebotsentzug, BWV-Retouren) behalten ihre bisherigen Schalter. Allgemeine Lager-, Artikel-, Kundenportal- und Abrechnungsfunktionen bleiben erhalten.

Entfernte Funktionen

Auf Betreiberwunsch wurden am 27.10.2026 vollständig aus der neuen Anwendung entfernt: HHA-Safebag-Berichte, beide PTnova-SOAP-Importe, Replikationsprüfungen für HTG/HTM/HTM_OLD/HHA/INT/MUH sowie Kompression und Bereinigung der alten PHP-/mps2-Serverdateien. Dazu gehören Implementierungen, Zeitpläne, Konfigurationsfelder und ausschließlich dafür benötigte Abhängigkeiten. Die zwei schon zuvor verworfenen HHA-Aufrufe für Disposition und Export bleiben ebenfalls ausgeschlossen. Diese Punkte sind keine offenen Migrationen.

Entfernte Gruppen können nicht mehr über SPRING_TASK_GROUPS aktiviert werden; eine solche veraltete Gruppenauswahl verhindert den Start mit einer Fehlermeldung. Die Replikationskonfiguration akzeptiert ausschließlich den Schlüssel STB. Fremde Gruppen werden vor Datenbankzugriff oder Alarmversand abgewiesen. Bereits vorhandene Daten und historische Laufbelege werden nicht gelöscht.

Docker-Betrieb ohne Cron

Das Image setzt SPRING_TASK_GROUPS auf die fünf Stadtbote-Gruppen und plant beim Start 111 Aufgaben im Spring-ThreadPoolTaskScheduler ein. Der Hauptprozess ist java -jar /app/app.jar; es werden kein Cron-Daemon, keine Crontab, kein PHP und keine Shell-Wrapper für die Aufgaben verwendet. Die Cron-Ausdrücke sind lediglich das Zeitplanformat innerhalb von Spring Boot.

Die Image-Vorgabe lässt sich überschreiben:

  • -e SPRING_TASK_GROUPS=mysql-status: ausschließlich Datenbankdiagnose.
  • -e SPRING_TASK_GROUPS=: alle fünf zeitgesteuerten Gruppen deaktivieren.
  • Eine kommagetrennte Auswahl aktiviert nur die genannten Gruppen.

SPRING_TASK_GROUPS hat Vorrang vor LEGACY_CRON_JOBS. Ein leerer alter LEGACY_CRON_JOBS-Eintrag in einer .env schaltet die Image-Vorgabe nicht ab. Beim direkten Java-Start ohne SPRING_TASK_GROUPS gilt der bisherige Fallback LEGACY_CRON_JOBS, standardmäßig leer.

Startlogs nennen Anzahl und Gruppen der tatsächlich eingeplanten Aufgaben. Beim Herunterfahren werden noch nicht fällige Aufgaben verworfen; laufende Aufgaben erhalten bis zu 30 Sekunden zum Abschluss. Für Docker --stop-timeout 40 setzen. Verpasste Termine werden nicht nachgeholt. Europe/Berlin gilt unabhängig von der JVM-/Container-Zeitzone.

Produktionskonfiguration

Die Vorlage .env.example enthält die benötigten Einstellungen. Eine Einplanung bestätigt noch keine erfolgreiche fachliche Ausführung. Fehlende Voraussetzungen erscheinen beim Lauf im Betriebsstatus.

  • STB-Berichte: SMTP und SMTP_FROM einrichten. Empfänger kommen aus MAIL_CRON_106_TO_ADDRESS, für EG-Lizenz aus MAIL_CRON_102_TO_ADDRESS (NL, dann global). Entwickler-Fallbacks und feste PHP-Bcc-Adressen werden nicht übernommen.
  • SB-Exporte: Exportablage, FTP-Parameter, Konten, Rechte, RETRANS-Profile und Felddefinitionen müssen vorhanden sein. Fehlende Voraussetzungen sperren den betreffenden Task. NL 90 bleibt wie in PHP ausgeschlossen.
  • STB-Replikation: LEGACY_CRON_REPLICATION_TARGETS ist beispielsweise {"STB":["primary.example:3391","replica.example:3391"]}. Der erste Eintrag ist der Primärserver, weitere Einträge sind Replikate. Zugang über LEGACY_CRON_REPLICATION_USER / _PASSWORD, Alarmempfänger über _MAIL_TO. Es werden keine fest codierten Produktionsserver aus PHP übernommen.
  • MySQL-Status: Nutzt DB_URL. Daten und Raten liegen in genericdatacontainer, nicht im Dateisystem. Download: /api/administration/cron/database-status?month=2026-10. Ohne Vorgängermessung oder nach Datenbankneustart bleiben Intervallraten leer.

Die fünf Zeitpläne können über die in .env.example dokumentierten Variablen überschrieben werden; Spring erwartet sechs Felder mit Sekunden.

Laufkontrolle und Wiederanlauf

Verwaltung → Betriebsstatus zeigt nur die registrierten Stadtbote-Aufgaben, Termine und Ergebnisse. Belege liegen in genericdatacontainer.gdc_obj_type='ngcron'. Vor der Verarbeitung gespeicherte Belege und datenbankweite Sperren verhindern doppelte Verarbeitung durch mehrere NG-Instanzen. Wartende Aufgaben behalten ihren ursprünglichen Termin.

Ein unterbrochener Lauf bleibt RUNNING oder UNCERTAIN und wird auch am nächsten Tag nicht automatisch wiederholt. Vor Freigabe mögliche Teilwirkungen prüfen, insbesondere SMTP-Logs, Exportdateien und FTP-Eingang. Exportvorgänge lassen sich im Datentransfer unter dem jeweiligen Exportkonto fortsetzen. Danach im Betriebsstatus „Bisherige Teilwirkungen und Versandprotokolle geprüft“ markieren und „Nächsten Termin freigeben“ wählen.

Die API POST /api/administration/cron/{id}/review erwartet {"slot":"<slot aus Betriebsstatus>","reviewed":true} sowie Sitzung und CSRF-Token. Sie prüft Mitarbeiterverwaltungsrecht, Laufversion und laufende Ausführung und protokolliert die Freigabe. Freigegeben wird nur der nächste reguläre Termin, kein sofortiger Neuversand.

Bewusste Korrekturen gegenüber PHP: ungültige Kalenderdaten blockieren den Lauf; Filterupdates erhalten fremde Tokens und verwenden die richtige Kurier-ID statt des PHP-Tippfehlers crvid. Bei fehlenden PLZ-Fahrzeiten verwendet die Belegungsprüfung 30 Minuten. Leere Fristen ändern keine Filter. Führungszeugnis plus sechs Monate behält den PHP-Monatsüberlauf. Skript 1629 prüft wie im aktuellen PHP-Code Feld 441.

Prüfung und Bereitstellung

Nach Entfernung der fachfremden Funktionen wurde am 27.10.2026 ein vollständiges clean verify gegen eine isolierte MariaDB ausgeführt: 1.637 Tests bestanden, drei ausschließlich für eine Bestandsdatenbank vorgesehene Prüfungen ausgelassen, keine Fehler. Die Prüfungen umfassen Scheduler, Gruppenauswahl, Ablehnung fremder Replikationsgruppen und die verbliebenen Datenbankabläufe. Im neu gebauten JAR sind die entfernten SOAP- und Dateiwartungsklassen nicht mehr enthalten.

Das daraus gebaute Docker-Image wurde ohne Netzwerk, Produktionszugänge, eingebundene Verzeichnisse oder veröffentlichte Ports gestartet. Das Startlog bestätigt 111 von 111 eingeplante Tasks in den fünf Stadtbote-Gruppen, auch bei leerem LEGACY_CRON_JOBS. Java läuft als PID 1; PHP, cron und crond sind nicht vorhanden. Das Herunterfahren erfolgt ohne Scheduler-Timeout. Beide Testcontainer wurden anschließend entfernt.

Die Produktionsbereitstellung steht weiterhin aus. Eine fachliche Ausführung mit Produktionsdiensten wurde nicht getestet; laufende Fremdprojekte wurden nicht neu gestartet.