Verbesserung der Dokumentation und implementierung von automation funktion in pck_auto_import
This commit is contained in:
@@ -13,7 +13,7 @@
|
||||
| **OCI Object Storage** | Zwischenspeicher — Eingangsordner, Zielordner nach Verarbeitung |
|
||||
| **Oracle DB / APEX** | Verarbeitung — liest Dateien aus OCI, importiert Daten |
|
||||
|
||||
Details zum Dateieingang Service: `agent-backend/docs/Architecture.md`
|
||||
Details zum Dateieingang Service: `quarkus-automaton/docs/Architecture.md`
|
||||
Details zur DB-Verarbeitung: `database/docs/plan_pck_net_storage.md`
|
||||
|
||||
---
|
||||
@@ -23,9 +23,11 @@ Details zur DB-Verarbeitung: `database/docs/plan_pck_net_storage.md`
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ APEX Automation (stündlich) │
|
||||
│ → pck_auto_import.p_run_ba_korrespondenz_dateieingang_automation │
|
||||
│ │
|
||||
│ 1. Unterordner in eingang/ mit Marker vorhanden? │
|
||||
│ → ja: Dateien verarbeiten (gleiche Logik wie Schritt 4-6) │
|
||||
│ 1. p_process_incoming_ba_data aufrufen │
|
||||
│ → OCI-Batches mit Marker verarbeiten (Fallback: ORDS-Aufruf │
|
||||
│ im letzten Quarkus-Lauf fehlgeschlagen) │
|
||||
│ │
|
||||
│ 2. Dateieingang Service aufrufen (fire & forget) │
|
||||
│ HTTP POST /api/process-incoming (Header: X-Api-Key) │
|
||||
@@ -44,13 +46,13 @@ Details zur DB-Verarbeitung: `database/docs/plan_pck_net_storage.md`
|
||||
│ hochladen │
|
||||
│ 3e. ZIP auf SFTP umbenennen (.processed oder .error) │
|
||||
│ → erst NACH erfolgreichem Marker-Upload │
|
||||
│ 3f. ORDS-Endpunkt aufrufen (pck_auto_import.p_process_incoming)│
|
||||
│ 3f. ORDS-Endpunkt aufrufen (pck_auto_import.p_process_incoming_ba_data)│
|
||||
│ 3g. Lokale Arbeitsdateien löschen │
|
||||
└────────────────────────────┬────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Oracle DB (via ORDS-Endpunkt oder APEX Automation) │
|
||||
│ Oracle DB (via ORDS-Endpunkt) │
|
||||
│ │
|
||||
│ 4. Unterordner in eingang/ auflisten │
|
||||
│ 5. Für jeden Unterordner mit Marker: │
|
||||
@@ -85,7 +87,9 @@ bucket/
|
||||
```
|
||||
|
||||
Der Marker bleibt solange erhalten bis **alle** Dateien des Unterordners
|
||||
erfolgreich verarbeitet wurden. Fehlgeschlagene Dateien werden beim nächsten Lauf erneut versucht.
|
||||
verarbeitet wurden. Fehlgeschlagene Dateien bleiben im Ordner.
|
||||
Wenn ein Import-Lauf alle Dateien im Ordner einmal versucht hat zu importieren, und min. eine Datei übrig geblieben ist, für die der automatische Import also nicht funktioniert hat, dann wird für jede dieser Dateien eine Wiedervorlage für die Sachbearbeiter erstellt und eine Marker Datei für die Sachbearbeiter wird im Ordner abgelegt.
|
||||
Daran können die Sachbearbeiter erkennen, dass der Ordner nicht mehr automatisch importiert wird, sondern sie manuell tätig werden müssen.
|
||||
|
||||
---
|
||||
|
||||
@@ -104,13 +108,30 @@ erfolgreich verarbeitet wurden. Fehlgeschlagene Dateien werden beim nächsten La
|
||||
**DB: Verarbeitung einer einzelnen Datei schlägt fehl**
|
||||
- Rollback — Datei bleibt in `eingang/<zip-name>/`
|
||||
- ERROR in `lg_app_log` mit `log_object_ref = eingang/<zip-name>/datei.csv`
|
||||
- Marker bleibt erhalten → nächste Dateien im Batch werden weiterverarbeitet
|
||||
- Beim nächsten Lauf wird die fehlgeschlagene Datei erneut versucht
|
||||
- Nächste Dateien im Batch werden weiterverarbeitet
|
||||
|
||||
**DB: Batch-Abschluss (nach dem Datei-Loop)**
|
||||
- DB-Marker (`_READY_FOR_DB_PROCESSING_`) wird **immer gelöscht** — kein automatischer Retry
|
||||
- Liegen noch Dateien im Unterordner: SB-Marker (`_BITTE_PRÜFEN_`) wird angelegt → Sachbearbeiter müssen manuell eingreifen
|
||||
- Alle Dateien erfolgreich: INFO in `lg_app_log`, Unterordner ist leer
|
||||
|
||||
**DB: p_move_object schlägt nach erfolgreichem Import fehl**
|
||||
- Rollback des Imports → sauberer Ausgangszustand
|
||||
- Datei bleibt in `eingang/<zip-name>/`, Marker bleibt erhalten
|
||||
- Nächster Lauf versucht es erneut
|
||||
- Datei bleibt in `eingang/<zip-name>/`
|
||||
- DB-Marker wird trotzdem am Ende des Loops gelöscht; falls noch Dateien übrig → SB-Marker
|
||||
|
||||
---
|
||||
|
||||
## Warum ruft die APEX Automation p_process_incoming_ba_data auf, obwohl Quarkus das auch tut?
|
||||
|
||||
`p_process_incoming_ba_data` wird in jedem Stundenlauf **zweimal** aufgerufen:
|
||||
|
||||
1. Direkt durch `p_run_ba_korrespondenz_dateieingang_automation` (Schritt 1)
|
||||
2. Indirekt — von Quarkus via ORDS, nachdem der Upload abgeschlossen ist (Schritt 3f)
|
||||
|
||||
Der direkte Aufruf in Schritt 1 ist ein **Fallback**: Wenn der ORDS-Aufruf in einem vorherigen Quarkus-Lauf fehlgeschlagen ist, liegt der Marker bereits in OCI, aber `p_process_incoming_ba_data` wurde nie aufgerufen. Ohne Schritt 1 würde dieser Batch erst beim nächsten Quarkus-Lauf verarbeitet — und nur dann, wenn Quarkus beim nächsten Mal auch wieder erfolgreich bis zum ORDS-Aufruf kommt. Mit Schritt 1 ist die DB-Verarbeitung unabhängig davon, ob Quarkus den ORDS-Aufruf erfolgreich abgeschlossen hat.
|
||||
|
||||
Das heißt: Quarkus ist der **schnelle Pfad** (Upload + sofortiger DB-Trigger), die APEX Automation ist die **Absicherung** (findet Marker, die noch nicht verarbeitet wurden).
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user