Technische Dokumentation
Analyse-Flow der SAP Import Queue: Vom CSV-Upload bis zur fertigen Import-Liste für das Zielsystem Y10.
1 Übersicht
Diese Anwendung bestimmt, welche SAP-Transporte nach einer Systemkopie P10 → Y10 noch aus dem Testsystem T10 in das Zielsystem Y10 importiert werden müssen. Dabei werden sechs CSV-Exporte aus den SAP-Systemen analysiert, um eine chronologisch sortierte Import-Queue zu erzeugen — unter Berücksichtigung von Abhängigkeiten und Downgrade-Schutz.
2 Input-Dateien
Sechs CSV-Exporte aus den SAP-Systemen werden benötigt:
3 Analyse-Pipeline
Der Kern-Flow in acht aufeinanderfolgenden Schritten. Für das vollständige Detail (21 Blöcke, 5 Phasen, inkl. Audit/Reproduzierbarkeit) siehe Logic-Tab → Pipeline.
trFilter auf bekannte TRs eingeschränkt — Fremd-System-TRs werden ignoriert.
uploads/blacklist.json): blacklisted TRs werden aus History/E071/VRSD entfernt.
Pro Objekt mit blacklistetem newest-TR wird der nächst-neueste Non-Blacklist-TR als Ersatz eingesetzt.
Cutoff-Date anwenden (Stichtag der Systemkopie). TR-Sets bilden:
Workbench, Customizing, ToC, LANG, PIECE.
R3TR CLAS, FUGR, MSAG, etc. nur als Master-Eintrag;
VRSD trackt aber jede Sub-Object-Version einzeln. Diese Brücke wird hier gebaut für:
CLAS→METH/CINC/CLSD/CPRI/CPRO/CPUB/DOCU,
INTF→METH/CINC/INTD/DOCU,
MSAG→MESS,
DOMA→DOMD/DOCU,
DTEL→DTED/DOCU,
TABL→TABD/CHDO/DOCU,
PROG→REPS/REPT/DYNP/CUAD/VARX/AVAS/DOCU,
FUGR→FUNC/REPS/DYNP/CUAD/DTEL/DOCU/TABT/WAPP.
Naming-Convention via Trie-Lookup + E071-Co-Occurrence-Fallback (multi-Master per Sub-Name-Prefix).
trNumber).
Transitive Tabellen-Cascade: spätere TRs auf gleicher Tabelle werden mitgenommen.
trNumber).
CSV-Spalten: Position, TR-ID, Type, List, Import Date, Import Time, T10-Importreihenfolge, T10-Anomalie, Plausi-Downgrade, Plausi-Downgrade-Objekte, Plausi-Downgrade-Objektliste.
4 TR-Typen
5 Wichtige Regeln
- TR-Nummer-Vergleich statt VRSD-Version: Der Coding-Resolver vergleicht TR-Nummern, nicht VRSD-Versionsnummern. Grund: Transport of Copies (ToCs) inflaten die Versionsnummern, da sie als eigene Version im Versionsregister auftauchen. Die TR-Nummer hingegen ist stabil und repräsentiert die tatsächliche chronologische Reihenfolge.
-
Master → Sub-Object Bridge:
E071 listet Master-Objekte (R3TR CLAS/MSAG/PROG/FUGR/…) als einen Eintrag pro TR.
VRSD trackt aber jede Sub-Object-Version (METH, MESS, REPS, …) separat.
Die Bridge stellt das für 8 Master-Typen wieder her, damit ein
R3TR CLASauch alle seine Sub-Objekte als „berührt“ markiert. Naming-Convention via Trie + E071-Co-Occurrence für FUNC/DOCU/TABT/WAPP. - VRSD-Nebenprodukte filtern: VRSD listet Sub-Objekte mit dem TR der sie zuletzt versioniert hat — aber dieser TR muss das Objekt nicht zwingend in seinem E071-Inhalt haben (Side-Effect-Eintrag). Coding-Resolver und Plausi-Check verwenden einen E071-Cross-Check: Objekte werden nur berücksichtigt, wenn der TR sie auch real in E071 enthält.
- Downgrade-Schutz (transitive Cascade): Bringt ein Transport ältere Versionen mit (ToC oder CLAS-Rebuild), werden automatisch alle neueren TRs für dieses Objekt mitgenommen. Plus „CLAS-Sub-Object-Cascade“ für die Repair-Liste: ein Repair-Import einer Klasse zieht alle neueren Sub-Object-TRs mit.
- Stichtag (Cutoff-Date): Nur Transporte die nach der letzten Systemkopie P10 → Y10 in T10 importiert wurden sind relevant. Wenn keine Y10-Files hochgeladen sind, kann ein Stichtag manuell übergeben werden; ohne Stichtag werden alle T10-Imports betrachtet.
- Plausi-Check: Nach Build der Queue wird simuliert, was beim Import passieren würde. Pro VRSD-Objekt wird der letzte berührende TR ermittelt — hat dieser nicht den neuesten Stand & existiert ein neuerer TR mit echtem E071-Eintrag, ist es ein Plausi-Downgrade. Pro Last-Touch-TR wird die Anzahl + Liste der betroffenen Objekte im CSV ausgegeben.
-
Blacklist:
TRs in
uploads/blacklist.jsonwerden niemals importiert. Vor den Resolvern werden Histories und E071 gefiltert; pro Objekt mit blacklistetem newest-TR wird der nächst-neueste Non-Blacklist-TR als Ersatz eingesetzt — abhängigkeiten werden so sauber transitiv aufgelöst. Schema unterstützt Audit-Felder (addedBy,addedAt,reason,ticketRef). -
Audit & Reproduzierbarkeit:
Pro Lauf wird ein
runId+ SHA-256-Manifest aller Eingabe-Dateien erzeugt (incl. 3.7 GB E071, streaming-gehasht). Audit-Loguploads/_audit.jsonlals append-only Protokoll von analyze_start/finish/error. Atomic-Write für_last_results.jsonverhindert korrupte Dateien bei Crash.
6 API-Endpunkte
Schnellreferenz aller verfügbaren REST-Endpunkte:
| Methode | Endpunkt | Beschreibung |
|---|---|---|
| POST | /api/upload | 6 einzelne CSV-Dateien hochladen (multipart/form-data) |
| POST | /api/upload/archive | 7z- oder ZIP-Archiv mit Auto-Mapping der enthaltenen Dateien |
| PUT | /api/upload/archive/chunk | Chunk eines Archivs hochladen (paralleler Upload großer Dateien) |
| POST | /api/upload/archive/finalize | Chunked Upload abschließen und Archiv verarbeiten |
| POST | /api/analyze | Analyse starten. Optional: {"cutoffDate": "YYYY-MM-DD"} im Body |
| GET | /api/results | Letzte Analyse-Ergebnisse abrufen (JSON) |
| GET | /api/export/csv | Ergebnisse als CSV-Datei herunterladen |
| GET | /api/export/text | Ergebnisse als Text-Datei herunterladen |