claude-wuerth-plato/memory/sap-config.md

name, description, metadata

name	description	metadata
sap-config	Echter SAP-Zugriff — Basic Auth (NICHT Kerberos), Endpoint/Key-Predicate-URL, Proxy-Pflicht, Env→Secret/Overlay-Mapping	node_type type originSessionId memory project fc0d1c3f-3797-4d5c-9282-bf72eb45dd51

Echte SAP-Anbindung (Mock-Ablösung). Auth ist Basic Auth, nicht Kerberos/SPNEGO — die alte Annahme war falsch (Korrektur 2026-06-17). Verifiziert mit erfolgreichem Call:

curl -sv -u 'sy08804394:<pw>' \
  "https://odatang9.wgn.wuerth.com/sap/opu/odata/WUE/sd_plato5_srv/CustomerSet(CustomerID='1205619',Salesorg='0001')" \
  -H "Accept: application/xml"

Endpoint / Parameter:

• Base: https://odatang9.wgn.wuerth.com/sap/opu/odata/WUE/sd_plato5_srv
• Entity: CustomerSet(CustomerID='<id>',Salesorg='<org>') — OData Key-Predicate-Syntax (Hochkommata, ggf. URL-encodet %27). NICHT ?CustomerId=…&Salesorg=… (das ist die alte Mock-Query).
• Salesorg im DEV-Test: 0001.
• Header: Accept: application/xml. Antwort = XML mit d:-Tags (Parser sapXmlToCustomer).
• Netz: nur über Proxy http://proxy.wgs.wuerth.com:3128. Aus dem Cluster ist odatang9:443 direkt = Timeout.

Technischer User: sy08804394 (+ Passwort). Beides gehört in ein Secret, nicht in Env-Literale.

Env → Secret/Overlay-Mapping (ops-Repo fahrzeugeinrichtung-plato-gitops):

• Deployment backend (ns 1401-plato-development) zieht Secrets per envFrom aus plato-customer-secrets (+ plato-postgres-secrets). Aktuelle Keys: nur OIDC_CLIENT_SECRET, SESSION_SECRET.
• Nicht-geheime Env stehen im Overlay-Patch overlays/environments/development/backend.yaml (Proxy, SAP_MOCK_ENABLED, OIDC_*). Dort sind SAP_URL/BE_URL bereits auskommentiert vorgesehen.
• Secrets sind SealedSecrets: plato-customer-secrets.sealed.yaml. Neuer Wert → Klartext-Secret nach Vorlage secret.example.template.yaml, dann kubeseal -o yaml -f <klartext>.yaml > <sealed>.yaml (im richtigen Cluster eingeloggt!), in kustomization.yaml als resource referenziert.

Aktivierung umgesetzt 2026-06-17 (committed, NICHT gepusht):

• Adapter apps/plato-customer-be/src/migration/util/sap-adapter.ts gepatcht (backend development, commit e33cc32): bei gesetztem SAP_URL → Key-Predicate-URL CustomerSet(CustomerID='…',Salesorg='0001') + Authorization: Basic aus SAP_USER/SAP_PASSWORD, raus über den globalen undici-ProxyAgent (kein eigener Dispatcher). Ohne SAP_URL unverändert Mock-Pfad (alte Query, directDispatcher, kein Auth). Mock-E2E grün.
• Eigenes Secret plato-sap-secrets (Keys SAP_USER/SAP_PASSWORD) als SealedSecret, ns 1401-plato-development. Template secret.sap.template.yaml hat NUR Platzhalter — echtes PW steht ausschließlich verschlüsselt in plato-sap-secrets.sealed.yaml (nie im Klartext in Git).
• gitops main, commit 4c0b8cd: Sealed Secret als resource in kustomization.yaml, backend.yaml-Overlay um envFrom plato-sap-secrets + SAP_URL=…/sd_plato5_srv erweitert, SAP_MOCK_ENABLED=false.

Push & Deploy gelaufen: backend development gepusht → CI baute backend:0.38.1, ArgoCD ausgerollt; DEV-Pod oben mit SAP_URL + mock=false, Secret plato-sap-secrets aktiv. Boot sauber (SAP wird erst beim Import gerufen).

SAP-Rechte fehlen (2026-06-17): Der technische User sy08804394 hat KEINE Rechte auf dem Endpoint → echter Import läuft nicht. Technisch fährt aber alles hoch.

Update 2026-06-23 — Rechte jetzt da, Call grün: Aus dem DEV-Pod (backend-..., ns 1401-plato-development) liefert derselbe User sy08804394 HTTP 200 mit gültigem OData-XML (CustomerID='1205619',Salesorg='0001'). Damit ist der Parser-Erwartungswert bestätigt: Antwort ist XML mit d:-Tags (d:Salesorg, d:CustomerID, d:SalesrepNumber …) → sapXmlToCustomer passt. Test-Rig im Pod: kein curl vorhanden → über node + undici request (NICHT globalen fetch — der kollidiert mit der node_modules-undici-Version: „invalid onRequestStart method") mit ProxyAgent(HTTPS_PROXY) und Basic-Auth-Header.

PROD ebenfalls grün (2026-06-23): Derselbe Test aus dem PROD-Pod (ns 1401-plato-production) liefert auch HTTP 200 + identisches XML. SAP-URL + Creds sind in DEV- und PROD-Overlay identisch → beide Umgebungen erreichen SAP gleichermaßen.

Mock vollständig aus Runtime/Prod entfernt (2026-06-17):

• backend development commit 30591b8: apps/sap-mock/ (standalone), sap-mock.controller.ts, sap-mock.module.ts und das app.module.ts-Wiring gelöscht. Build grün.
• Für Tests bewusst behalten: sap-mock.service.ts + sap-reverse-query.ts (nutzt der E2E via buildCustomerXml), sap-fixtures.e2e.spec.ts, data/fixtures/, scripts/build-*.mjs. Werden vom App-Code nicht mehr importiert → fliegen aus dem Prod-Bundle.
• gitops main commit f12f6d9: SAP_MOCK_ENABLED aus dev+prod-Overlay.
• DEV-Cluster direkt bereinigt (war manuell, nicht in Git): ConfigMap sap-mock-master, Volume/Mount, SAP_MOCK_DB-Env entfernt.
• Beide Commits noch NICHT gepusht.

Parser sapXmlToCustomer (erwartet d:-Tags) bleibt bis zum ersten echten Body unbestätigt — wegen fehlender Rechte noch nicht verifizierbar.

OFFEN (morgen, Marcus aktiv ansprechen): Der für Tests behaltene Mock-Rest (sap-mock.service.ts, sap-reverse-query.ts, Fixtures-Generatoren) soll RAUS — Mock im Repo war nur Notlösung, Behalten verstößt gegen die Etikette. Entscheidung treffen: A alles inkl. SAP-Migrations-E2E löschen (kein SAP-Test mehr); B Mock-Code raus, sapXmlToCustomer gegen ein paar statische, aufgezeichnete SAP-XML-Fixtures testen (schlanker Parser-Test bleibt). Marcus tendiert klar zu „raus".

Hinweis Live-State: Der DEV-Pod hat zusätzlich SAP_MOCK_DB + ConfigMap-Mount sap-mock-master — das wurde manuell gepatcht und steht NICHT im Overlay-backend.yaml. Siehe project-sap-mock-fixtures (Mock/Fixtures bleiben gültig).