8.4 KiB
Prüfstatus der ersten Bestandsanbindung
Stand: 1. Oktober 2026.
Aktuelle Umstellung auf den zentralen Datenbankservice
Die neue Anwendung verwendet für jeden Datenbankzugriff database.DatabaseService, einschließlich Anmeldung, Listen, CSV-Leseabfragen, Verbindungstest und Schemadiagnose. Python ist bei der Diagnose nur noch der Launcher des Java-JARs. Der zentrale Schreibzugang bleibt gesperrt. Architekturtests erzwingen die Grenze auch für die Integrationstests; die PHP-Altanwendung bleibt unverändert.
Nach wiederhergestellter Datenbankverbindung wurden am 1. Oktober 2026 um 17:00 Uhr 49 Backend-Tests einschließlich des Integrationstests gegen die Bestandsdatenbank erfolgreich ausgeführt: keine Fehler, keine übersprungenen Tests. Außerdem bestanden alle 10 Python-Tests. Der Integrationstest lädt Aufträge, Kunden und Kuriere über die API und den zentralen Service mit simuliertem Anwendungskonto und echten SELECT-Abfragen.
Die erneute Java-CLI-Diagnose war ebenfalls erfolgreich: MariaDB 11.7.2-MariaDB-ubu2404-log, 13 geprüfte Tabellen, keine fehlenden erforderlichen Spalten. Es wurden keine Daten oder Tabellen geändert. Die Anwendung bleibt gestoppt; nach den Tests waren die Ports 8080 und 5173 frei.
Im ersten erreichbaren Testlauf fiel eine ungeeignete Prüfung von @@session.tx_read_only auf: Dieser Wert beschreibt den Sessionstandard, nicht den Modus der einzelnen Transaktion. Die Prüfung wurde ersetzt und der Service aktiviert nun ausdrücklich DataSourceTransactionManager.setEnforceReadOnly(true). Ein zusätzlicher Test mit echtem Transaktionsmanager und gemockter Verbindung prüft die Reihenfolge SET TRANSACTION READ ONLY → SELECT → COMMIT; es gibt keine Schreibversuche gegen den Bestand. Grundlagen: MariaDB SET TRANSACTION, Spring DataSourceTransactionManager.
Der zuvor bei unterbrochener Verbindung geprüfte Fehlerfall bleibt gültig: Der CLI-Modus liefert bereinigtes JSON mit reason: UNAVAILABLE, Exitcode 1 und startet keinen Webserver.
Durchgeführt
| Prüfung | Ergebnis |
|---|---|
| React-/TypeScript-Produktionsbuild | Erfolgreich |
Spring-Boot clean verify, inklusive gebündeltem React |
Erfolgreich |
| 20 Backend-Tests ohne Bestandszugriff | Erfolgreich: Legacy-Mapping einschließlich Boolean-Flags und mehrwertiger Statuscodes, Rechte, Niederlassung, CSV, gesperrte Schreibmethoden |
| 1 optionaler Integrationstest mit vorhandener Datenbank | Erfolgreich: Auftrags-, Kunden- und Kurier-API über MockMvc mit echten JDBC-Abfragen; Test-Authentifizierung, keine Datenänderungen |
| 7 Python-Konfigurationstests | Erfolgreich: Kommentare, Escaping, Umgebungspriorität, keine PHP-Ausführung |
| 1 HTTP-Integrationstest gegen das gebaute JAR | Erfolgreich: Health, Offline-Systemzustand, geschützte API, öffentliche Logo-Datei |
| Manuelle Browserprüfung im integrierten Browser | Anmeldung mit Testantworten, Auftragsliste, Mehrstoppdetails, Disposition, Touren, Kunden, Kuriere, Abrechnungshinweis, Auswertung, serverseitige Suche, Logout und eingeschränktes Folgekonto geprüft |
| Browserprüfung mit fehlenden Preisen und Terminen | Keine Browserfehler; unbekannte Werte bleiben „–“, Summen als unvollständig gekennzeichnet |
| Abhängigkeiten des Frontends | npm install meldet keine bekannten Sicherheitslücken |
| Verbindung und Schemametadaten der Bestandsdatenbank | Erfolgreich mit scripts/check-database.py: 13 Tabellen geprüft, keine erforderlichen Spalten fehlen; keine Anwendungsdatensätze gelesen und keine Schreibzugriffe |
| Backend nach Neustart mit dem konfigurierten Datenbankkonto | Erfolgreich: GET /api/health liefert status: UP; GET /api/system liefert connected: true, reason: CONNECTED, readOnly: true, schemaChanges: false |
Für die Browserprüfung diente ausschließlich ein separater lokaler HTTP-Testserver mit ausdrücklich markierten Testantworten. Er ist kein Bestandteil der Anwendung und hat keine Datenbank. Es wurden keine Testdatensätze in MySQL angelegt. Die vollständige automatisierte Playwright-Browsersuite ist vorbereitet, konnte hier wegen eines abgewiesenen Chrome-Prozessstarts nicht ausgeführt werden; sie wird nicht als bestanden gewertet. Die entsprechende Bedienung wurde im integrierten Browser geprüft.
Verbindung zur Bestandsdatenbank
Die lokale Verbindungskonfiguration steht in der .env im Projektstamm: DB_URL enthält Host, Port und Datenbanknamen; DB_USER und DB_PASSWORD enthalten das Datenbankkonto. Die Prüfung am 1. Oktober 2026 mit scripts/check-database.py war erfolgreich:
- Verbindung:
connected: true - Serverversion:
11.7.2-MariaDB-ubu2404-log - Geprüfte Tabellen:
checkedTables: 13 - Fehlende erforderliche Spalten:
missingColumns: {} - Gelesene Anwendungsdatensätze:
applicationRowsRead: 0 - Schreibzugriffe:
writes: 0
Die mit dem zuvor verwendeten Datenbankkonto aufgetretene Anmeldungssperre (MySQL-Fehler 1045, auch beim Versuch mit TLS) blockiert den Zugriff mit dem anschließend konfigurierten Datenbankkonto nicht mehr. Die Prüfung hat ausschließlich Server- und Schemametadaten gelesen; sie bestätigt die Existenz der vom Prüfskript benötigten Tabellen und Spalten.
Noch nicht erfolgreich geprüft
Die SQL-Zuordnungen beruhen auf dem vorhandenen PHP-Quellcode. Die drei Listen wurden mit jeweils 500 Bestandsdatensätzen erfolgreich gelesen. Der Fehler beim Kunden-/Kurierlesen wurde zuvor als NumberFormatException bei company.cmp_archived reproduziert: JDBC lieferte einen Boolean, der Mapper erwartete eine Zahl. Der Mapper akzeptiert nun Boolean-Flags; tinyInt1isBit=false erhält außerdem mehrwertige numerische Legacy-Codes. Alle 21 Backend-Tests einschließlich der optionalen Bestandsprüfung bestanden nach der Korrektur.
Die Bestandsprüfung verwendet ausschließlich für den Test eine simulierte Authentifizierung innerhalb einer vorhandenen Niederlassung. Sie bestätigt weder die reale Benutzeranmeldung noch sämtliche Filter und Berechtigungsgrenzen. Diese sowie die fachlichen Ergebnisse sind weiterhin gegen die PHP-Anwendung zu vergleichen.
Tagesansicht der offenen Aufträge
Am 1. Oktober 2026 wurde die Auswahl für das vorhandene Zentralenkonto admin_b zusätzlich mit dessen Niederlassung und Rechten über den echten Leseadapter geprüft: Status DISPOSITION und Abholdatum 1. Oktober 2026 liefern genau einen Auftrag, 21891299. Die zuvor fehlende Datumseinschränkung hatte auch historische und weit in der Zukunft geplante Aufträge geladen. Die Oberfläche verwendet wie die Standardliste im PHP-Bestand den heutigen lokalen Kalendertag als vorbelegten Zeitraum; andere Zeiträume bleiben über die Filter auswählbar. Es gibt keine fest programmierte Konto- oder Auftragsausnahme und keine Statusänderung in der Datenbank.
Frontend- und Backend-Build nach dieser Änderung erfolgreich (20 reguläre Backend-Tests bestanden; die optionale Bestands-Testsuite in diesem Build deaktiviert). Im Browser mit isolierten Testantworten geprüft: Schon die erste Listenanfrage enthält beide Tagesgrenzen; ein bewusst erweiterter Zeitraum zeigt zusätzlich einen Zukunftsauftrag; „Heute“ reduziert die Liste wieder auf den Tagesbestand. Das laufende Backend wurde neu gestartet und liefert den aktualisierten Frontend-Build.
Bewusst noch offene Fachlichkeit
Die neue Oberfläche und der JDBC-Leseadapter sind eine erste Ausbaustufe, keine vollständige fachliche Ablösung. Noch offen sind insbesondere:
- Native Auftragserfassung/-bearbeitung, Disposition mit Fahrerkommunikation, Stationsabschluss und Storno einschließlich Gegenbuchungen.
- Originale Tarife, Preisgültigkeiten, Rabatte, Zuschläge, Kurierabrechnung, Rechnungserstellung und Buchhaltungsexporte.
- Kostenstellenhierarchie, separate Fahrzeuge, Daueraufträge, Tourvorlagen, Lager/Artikel und kundenspezifische Schnittstellen.
- Kunden-/Kurierportale, zusätzliche Niederlassungsrechte, Archiv- und Log-Datenbanken.
- Konfiguration der tatsächlich vorhandenen PHP-Basisadresse
LEGACY_APP_URL, um noch nicht portierte Fachabläufe gezielt aufzurufen.
Die Detailanalyse steht in ALTSYSTEM-ANALYSE.md. Es gibt keine neue Datenbank, keine automatische Schemaänderung und keinen Seed-Mechanismus. Die bisherige PHP-Anwendung wurde durch diese Umsetzung nicht verändert.