# PROCUREX — B2B Procurement Platform Fiktives Lernprojekt: eine Beschaffungsplattform (Procure-to-Pay), umgesetzt als modularer Spring-Boot-Monolith. Projektsteuerung lief über Jira (`PRX` auf `aydinsude.atlassian.net`) und Confluence (`PRX` auf `aydinsude.atlassian.net/wiki`). Dauerhafte Architektur- und Technologieentscheidungen stehen in `PROCUREX-PLANUNGSENTSCHEIDUNGEN.md`; der aktuelle Repository- und Teststatus wird in dieser README und in `project.yaml` gepflegt. ## Projektstatus - **Lebenszyklus:** stabiler, abgeschlossener Lernstand; produktionsnahe Erweiterungen bleiben bewusst optional - **Zuletzt verifiziert:** 10.09.2026 mit 46 Standard-, 5 PostgreSQL-Integrations- und 2 Frontend-Tests sowie Angular-Produktionsbuild - **Kanonischer Pfad:** `projects/procurex-platform` - **Filterbare Metadaten:** `project.yaml` enthält Status, Tags, Qualitätsstand, Testzahlen, Einstiegspunkte und Beziehungen - **Reproduzierbarer Gesamtcheck:** `pwsh -NoProfile -File scripts/test-all.ps1` ## Architektur Modularer Monolith (ein deploybares Artefakt `procurex-app`), Module nach Bounded Context getrennt, jedes mit eigenem PostgreSQL-Schema und öffentlichen Port-Interfaces für modulübergreifende Aufrufe (kein direkter Zugriff auf fremde Schemas). Details: Confluence Seite 09 „Zielarchitektur und Modulstruktur“. ``` procurex-platform (Parent-POM) ├── procurex-common Shared Kernel (Exceptions, Problem-Details, Correlation-ID, Money) ├── procurex-supplier Lieferantenverwaltung PRX-3 ├── procurex-catalog Produktkatalog PRX-4 ├── procurex-requisition Warenkorb absenden PRX-2 ├── procurex-ordering Bestellung (Kernaggregat) PRX-2, PRX-5, PRX-8, PRX-12 ├── procurex-approval Genehmigung PRX-5, PRX-8 ├── procurex-receiving Wareneingang PRX-10 ├── procurex-invoicing Rechnungsprüfung (3-Way-Match) PRX-11, PRX-9 └── procurex-app Spring-Boot-Bootstrap-Modul procurex-frontend Angular-22-SPA (Standalone Components) PRX-20 ``` Jedes Modul hat ein eigenes README.md mit Endpunkten und Geschäftsregeln. Benachrichtigungen sind im aktuellen Release bewusst abgegrenzt: Der Frontend- `NotificationService` erzeugt nur lokale UI-Meldungen. Ein fachliches E-Mail-/Webhook-/Kafka- Benachrichtigungsmodul ist noch nicht implementiert; die Entscheidung und der spätere Umsetzungsschnitt stehen in `docs/notification-scope.md`. ## Tech-Stack (bestätigt, siehe Confluence Seite 08) Java 17 LTS · Spring Boot 3.3.4 · Maven Multi-Module · PostgreSQL 16 · Flyway · Angular ^22 · Keycloak 26.7.0 · Kafka (Confluent 7.7.1) — Anbindung an die geteilte lokale Plattform `enterprise-infrastructure` (Netzwerk `proxy`, Hostname-Präfix `procurex`). ## Build & Test ``` mvn test ``` Der Maven-Reactor läuft standardmäßig parallel (`.mvn/maven.config`, `-T 1C`). Das ist bei diesem 11-Modul-Projekt wichtig, weil die unabhängigen Module und ihre Surefire-Testläufe sonst seriell gestartet werden. Eine Messung auf dem lokalen Windows-Rechner mit warmem Maven-Cache ergab: | Lauf | Ergebnis | Zeit | |---|---|---:| | serielles `mvn test` | grün, Unit- und Contract-Tests | 156,7 s | | paralleles `mvn test` mit `-T 1C` | grün, Unit- und Contract-Tests | 106,2 s | Die Verbesserung beträgt in dieser Umgebung rund 32 %. Die Zeit ist hardware- und cacheabhängig. Der Hauptgrund für den ursprünglichen langsamen Eindruck war nicht die Contract-Generierung, sondern der serielle Reactor mit mehreren modulweisen Surefire-Teststarts. Die Contract-Tests werden nur im Modul `procurex-app` generiert und waren im Messlauf bereits aktuell. Der Standardlauf benötigt keine laufende Datenbank oder Docker, weil die drei Testcontainers-Integrationstests standardmäßig ausgeschlossen sind. Sie werden separat gegen eine Docker-kompatible Engine ausgeführt. Lokal funktioniert das mit einer gestarteten Podman- Machine: ```powershell podman machine start podman-machine-default $env:TESTCONTAINERS_RYUK_DISABLED = 'true' mvn -pl procurex-app -am test "-Dprocurex.integration=true" "-Ddocker.host=npipe:////./pipe/docker_engine" ``` Damit ist klar getrennt zwischen schnellem Standard-Quality-Gate und den teureren Tests mit echter PostgreSQL-Instanz. Die Integrationstest-Ausnahme ist in `procurex-app/pom.xml` dokumentiert; der separate Lauf ist ein echter Datenbankintegrationsnachweis. ## Anwendung starten **Lokal (Maven/ng serve):** Backend siehe `procurex-app/README.md`, Frontend siehe `procurex-frontend/README.md`. **Docker (PRX-21):** `docker-compose.yml` im Repo-Root containerisiert Backend und Frontend und bindet sie über das externe `proxy`-Netzwerk an den zentralen Traefik aus `enterprise-infrastructure` an – erreichbar unter `http://procurex.localhost` (Frontend) und `http://procurex-api.localhost` (Backend). End-to-end getestet: Flyway-Migrationen laufen gegen die geteilte Postgres-Instanz (`procurex_db`), CORS-Preflight von `procurex.localhost` funktioniert. Details und Startreihenfolge: `procurex-app/README.md`, Abschnitt „Starten – Docker“. ## Sprintübersicht Die ursprüngliche Planung umfasste vier Sprints. Für die inzwischen vorhandenen Integrations-, Betriebs- und Quality-Artefakte wurden nachträglich zwei **provisorische Lernprojekt-Sprints** dokumentiert: | Sprint | Fokus | Tickets | |---|---|---| | 1 | Grundlagen und Governance | PRX-2, PRX-3, PRX-6, PRX-7, PRX-13–19, PRX-28–31 | | 2 | Stammdaten und Katalog | PRX-4 | | 3 | Bestell-Kernprozess | PRX-5, PRX-8, PRX-12 | | 4 | Wareneingang und Rechnung | PRX-9, PRX-10, PRX-11 | | 5 | Integration und Betriebsfähigkeit | PRX-17, PRX-19, PRX-21, PRX-22, PRX-26, PRX-34 | | 6 | Quality Gates und Delivery-Nachweise | PRX-24, PRX-32, PRX-33, PRX-35, PRX-36 | Die dauerhaften technischen Nachweise stehen bei den jeweiligen Quellen: in `Jenkinsfile`, `docs/quality-gates.md`, `loadtests/README.md`, `procurex-frontend/README.md` und den Spring-Cloud-Contract-Verträgen unter `procurex-app/src/test/resources/contracts/`. ## Umgesetzte Tickets (Sprint 1–6) | Ticket | Story/Bug | Modul | |---|---|---| | PRX-2 | Warenkorb als Bestellung absenden | procurex-requisition, procurex-ordering | | PRX-3 | Lieferanten prüfen und aktivieren | procurex-supplier | | PRX-4 | Produkte im Katalog finden | procurex-catalog | | PRX-5 | Bestellungen entscheiden (Genehmiger) | procurex-approval, procurex-ordering | | PRX-8 | Doppelte Genehmigungsentscheidung verhindern | procurex-approval, procurex-ordering | | PRX-9 | Rechnung mit Mengenabweichung als Klärfall markieren | procurex-invoicing | | PRX-10 | Liefermengen erfassen (Wareneingang) | procurex-receiving | | PRX-11 | Rechnungen gegen Bestellungen prüfen | procurex-invoicing | | PRX-12 | Bestellungen mit Lieferantenstatus verfolgen | procurex-ordering | | PRX-20 | Angular-Frontend-Struktur und Accessibility-Regeln | procurex-frontend | | PRX-21 | Docker-Compose-Anbindung an enterprise-infrastructure | Dockerfiles, `docker-compose.yml`, CORS-Config | | PRX-19 | Keycloak/OIDC-Login und Backend-Autorisierung | `keycloak/`, `SecurityConfig`, Frontend `AuthService` | | PRX-17 | Kafka-Event-Publishing (Transactional Outbox) | `procurex-common/outbox`, je Modul ein Relay | | PRX-22 | Kubernetes/Helm-Deploymentkonzept | `helm/procurex/` (lint/template validiert, nicht live deployt) | | PRX-24 | Teststrategie (Unit/Integration/E2E) festlegen | siehe PRX-8, PRX-33 sowie `procurex-app/README.md` | | PRX-34 | Kafka-Consumer (Audit-Log) | `procurex-audit` | | PRX-33 | E2E-Frontend-Tests mit Playwright | `procurex-frontend/e2e` | | PRX-32 | Jenkins CI-Pipeline | `Jenkinsfile`, `shared/enterprise-infrastructure/jenkins/casc.yaml` | | PRX-35 | Contract-Tests mit Spring Cloud Contract | `procurex-app/src/test/resources/contracts`, `com.procurex.app.contracts` | | PRX-36 | Lasttests mit k6 | `loadtests/` | Der aktuelle E2E-Nachweis umfasst 4/4 Playwright-Tests. Der aktuelle k6-Lauf gegen Podman/ `enterprise-infrastructure` lief für alle drei Szenarien mit 0 % Fehlern und erfüllten Latenz-Thresholds; Details stehen in `loadtests/README.md`. Nicht Teil dieser Runde (siehe `PROCUREX-PLANUNGSENTSCHEIDUNGEN.md`): produktives Kubernetes- Deployment (kein Cluster in dieser Lernumgebung verfügbar).