71 lines
8.4 KiB
Markdown
71 lines
8.4 KiB
Markdown
# 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](https://mariadb.com/docs/server/reference/sql-statements/administrative-sql-statements/set-commands/set-transaction), [Spring DataSourceTransactionManager](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/datasource/DataSourceTransactionManager.html#setEnforceReadOnly(boolean)).
|
|
|
|
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.
|