Spring Integration: HTTP- und Datei-Pipeline für Bestellungen erstellen

Spring Boot REST-APIs sind bei Java-Entwicklern weit verbreitet – doch viele kennen die Stärken von Spring Integration noch nicht. Dieses Projekt zeigt, wie eine nachrichtenbasierte Verarbeitungspipeline in der Praxis funktioniert und welche Vorteile sie gegenüber klassischen REST-Ansätzen bietet.

Das Beispielprojekt verarbeitet Bestellungen aus zwei unabhängigen Quellen: einer HTTP-Schnittstelle und einem Dateipolling-Mechanismus. Beide Eingabepfade nutzen dieselbe Kernlogik für Validierung, Routing und Persistenz, demonstrieren aber gleichzeitig die Flexibilität von Spring Integration bei der Integration heterogener Datenquellen.

Warum eine Pipeline statt direkter API-Aufrufe?

Die klassische REST-API verarbeitet eingehende Anfragen synchron und blockiert Ressourcen, bis die Logik abgeschlossen ist. Spring Integration hingegen überführt die Anfragen in eine asynchrone Nachrichtenverarbeitung:

• Jede Bestellung durchläuft eine definierte Pipeline mit klaren Transformations- und Validierungsschritten.
• Routing-Regeln leiten die Bestellung automatisch an den passenden Service (z. B. Express- oder Review-Pfad).
• Die Architektur ermöglicht eine einfache Skalierung durch parallele Verarbeitung und Fehlerbehandlung.

Besonders nützlich ist dies bei Anwendungsfällen wie Bestellmanagement, wo sowohl Echtzeit-APIs als auch Batch-Dateien (z. B. CSV-Exporte) verarbeitet werden müssen.

Architektur der Bestellverarbeitung

Das Projekt nutzt eine modulare Struktur, die HTTP- und Dateipfade in einem gemeinsamen System vereint. Die Kernkomponenten sind:

1. HTTP-basierte Bestellaufnahme

Der HTTP-Endpunkt POST /api/orders empfängt JSON-Daten und leitet sie über eine Nachrichtengateway-Konfiguration in die Pipeline weiter.

@Bean
IntegrationFlow httpOrderFlow() {
    return IntegrationFlows
        .from(Http.inboundGateway("/api/orders")
            .requestMapping(m -> m.methods(HttpMethod.POST))
            .requestPayloadType(OrderRequest.class))
        .transform(new JsonToOrderTransformer())
        .handle(orderValidationService())
        .<Order, String>route(order -> order.getTotal() <= 100 ? "EXPRESS" : "REVIEW",
            m -> m.subFlowMapping("EXPRESS", expressFlow())
                .subFlowMapping("REVIEW", reviewFlow()))
        .get();
}

• JsonToOrderTransformer: Wandelt die JSON-Anfrage in ein Order-Objekt um.
• OrderValidationService: Validiert Felder wie id, customer und total (z. B. auf Duplikate oder negative Werte).
• Content-basiertes Routing: Bestellungen unter 100 € werden als Express, höhere Beträge als Review klassifiziert.

2. Dateipolling für CSV-Bestellungen

Der Dateipoller überwacht ein Verzeichnis (input/) und verarbeitet automatisch neue CSV-Dateien. Die Transformation erfolgt in drei Schritten:

@Bean
IntegrationFlow fileOrderFlow() {
    return IntegrationFlows
        .from(Files.inboundAdapter(new File("input"))
            .patternFilter("*.csv"),
            c -> c.poller(Pollers.fixedRate(5000)))
        .transform(new FileToStringTransformer())
        .transform(new CsvToOrderTransformer())
        .handle(orderValidationService())
        .<Order, String>route(...)
        .get();
}

• FileToStringTransformer: Liest die CSV-Datei als String.
• CsvToOrderTransformer: Parst die Daten in Order-Objekte.
• Fehlerbehandlung: Falsche Dateien werden in input/failed/ verschoben und protokolliert.

3. Persistenz und Nebenläufigkeit

Alle Bestellungen werden über Spring Data JPA in einer PostgreSQL-Datenbank gespeichert. Für Tests kommt H2 zum Einsatz. Zusätzlich werden folgende Nebenprozesse ausgelöst:

• Archivierung: Erfolgreich verarbeitete Bestellungen werden in eine separate Datei geschrieben.
• Zusammenfassung: Eine aggregierte Übersicht aller Bestellungen wird regelmäßig aktualisiert.
• Antwortgenerierung: Der HTTP-Client erhält eine Bestätigungsnachricht mit Statuscode 201 Created.

Fehlerbehandlung und Resilienz

Spring Integration bietet integrierte Mechanismen für den Umgang mit Fehlern:

• HTTP-Fehler: Fehlerhafte JSON-Daten führen zu einer strukturierten Antwort mit Statuscode 400 Bad Request.
• Dateiprozessierung: Bei Fehlern werden die Originaldateien in input/failed/ verschoben und die Fehler in output/failed/ protokolliert.
• Wiederholungsstrategien: Für den Dateipolling-Pfad können Wiederholungsversuche (z. B. bei Netzwerkproblemen) konfiguriert werden.

Praktische Beispiele für die Nutzung

Das Projekt enthält vorkonfigurierte cURL-Beispiele, um die HTTP-Endpunkte zu testen:

# Express-Bestellung (Gesamtwert ≤ 100 €)
curl -X POST  \
  -H "Content-Type: application/json" \
  -d '{"id":"ORD-001","customer":"Alice","description":"Buch","total":25.00}'

# Review-Bestellung (Gesamtwert > 100 €)
curl -X POST  \
  -H "Content-Type: application/json" \
  -d '{"id":"ORD-002","customer":"Bob","description":"Laptop","total":1500.00}'

# Einzelne Bestellung abfragen
curl 

# Alle Bestellungen auflisten
curl 

Lokale Einrichtung und Tests

Das Projekt lässt sich mit wenigen Schritten starten:

git clone 
cd spring-integration-sample

docker compose up -d
mvn clean package
mvn spring-boot:run

Nach dem Start können Bestellungen entweder über die API gesendet oder CSV-Dateien in das input/-Verzeichnis verschoben werden. Die Anwendung verarbeitet beide Eingabemethoden automatisch.

Testabdeckung und Lernmöglichkeiten

Das Projekt umfasst 38 Tests (Unit- und Integrationstests), die folgende Szenarien abdecken:

• Transformation und Validierung von Bestelldaten.
• HTTP-Pfade (erfolgreiche und fehlerhafte Anfragen).
• Behandlung von Duplikaten (HTTP-Status 409 Conflict).
• Dateipoller-Verarbeitung mit Wiederholungslogik.
• Aggregation der Bestellzusammenfassung.
• Visualisierung der Integration über /api/integration/graph.

Für Entwickler, die Spring Integration erlernen möchten, ist dies ein idealer Einstieg – besonders für komplexere Szenarien wie verteilte Systeme mit Kafka oder RabbitMQ.

Fazit: Ein modularer Ansatz für Bestellverarbeitung

Dieses Projekt demonstriert, wie Spring Integration die Entwicklung modularer, wartbarer und erweiterbarer Bestellverarbeitungspipelines ermöglicht. Durch die Kombination von HTTP-APIs und Dateipolling zeigt es, wie sich heterogene Datenquellen in einem einheitlichen System verarbeiten lassen.

Die vorgestellte Architektur eignet sich besonders für Anwendungsfälle, bei denen sowohl Echtzeit- als auch Batch-Verarbeitung erforderlich sind. Wer ähnliche Lösungen plant, kann dieses Projekt als Grundlage nutzen und um weitere Komponenten wie Benachrichtigungen oder externe Zahlungsgateways erweitern.