Spryker-Release 202606: Was für bestehende B2B-Systeme zählt

Spryker hat mit dem Release 202606 (Stand Juli 2026) drei Schwerpunkte gesetzt: native B2B-Beschaffung, eine breitere KI-Basis im Back Office und Verbesserungen an der Plattform selbst, von der Warteschlangenverarbeitung bis zu Security und Betriebsnachweisen. Mehrere B2B-Funktionen, die Betreiber bisher oft selbst gebaut haben, sind jetzt Teil des Standards. Für neue Projekte ist das eine Vereinfachung. Für bestehende, teils ältere Systeme wirft es eine Frage auf, die sich lohnt, in Ruhe zu beantworten.

Worauf dieses Release zielt

Die drei sichtbarsten Neuerungen drehen sich um wiederkehrende Bestellungen, um Einkaufskontrolle mit Budgets und um die Anbindung an Beschaffungssysteme über PunchOut. Dazu kommen ein erweitertes Storefront-Designsystem und eine native Suchauswertung im Back Office. Der rote Faden: Aufgaben aus dem B2B-Einkauf wandern aus der Einzelentwicklung in die Plattform. Parallel dazu wächst die KI-Basis aus dem Release 202512 weiter, im Entwickler-Workflow und mit neuen KI-Bausteinen direkt im Back Office. Eine dritte Achse betrifft die Plattform selbst: Warteschlangenverarbeitung, Storage-Effizienz, Security und Betriebsnachweise, Themen, die selten in Produktankündigungen auftauchen, aber den laufenden Betrieb direkt betreffen.

Die Punkte, die für Betreiber zählen

Recurring Orders. Käufer können wiederkehrende Bestellungen mit festem Rhythmus anlegen, etwa wöchentlich oder monatlich, die dann automatisch ausgeführt werden. Das Ganze kommt mit Freigaben und mit Recovery-Flows, wenn sich Warenkorb, Preise oder Daten aus dem ERP zwischenzeitlich ändern. Die Funktion ist als Early Access markiert.

Budget & Cost Centers. Budgets und Kostenstellen lassen sich direkt in Spryker führen und in die Einkaufs-Workflows einbinden. In der Dokumentation heißt die Funktion Purchasing Control und liegt im Paket Cart and Checkout. Für Organisationen mit abteilungs- oder projektbezogenem Einkauf heißt das: Freigaben, Budgetgrenzen und Nachvollziehbarkeit ohne eigenes Zusatzsystem.

PunchOut im Back Office. Spryker führt das als Verbesserung, nicht als neue Funktion. Native cXML- und OCI-Unterstützung sowie die Verarbeitung von PunchOut-Nachrichten gab es schon vorher, neu ist der eigene Konfigurationsbereich im Back Office. Beschaffungskanäle werden damit wiederholbar konfigurierbar, statt jedes Mal ein eigenes Projekt zu erfordern. Für Händler, deren Kunden über eigene Beschaffungssysteme bestellen, bleibt das der praktisch relevanteste Punkt im Release.

Die KI-Seite des Release

Neben der B2B-Beschaffung baut Spryker mit diesem Release die KI-Basis aus, die mit Release 202512 begonnen hat. Das AI Dev SDK übernimmt jetzt größere Teile des Entwicklungs-Workflows selbst, von der Recherche bis zur Code-Generierung, mit eingebauter Selbstkorrektur und Kontrollpunkten für Entwickler. Es unterscheidet zwei Qualitätsstufen, Quick PoC zur schnellen Validierung einer Idee und MVP für Code nach Spryker-Patterns und Projektkonventionen, und automatisiert nach jeder Codeänderung zusätzlich die technische Nacharbeit: Datenbankmigrationen, Cache-Rebuilds, Frontend-Builds.

Im Back Office kommen drei weitere KI-Bausteine dazu. Wie das AI Dev SDK sind auch sie als Early Access markiert: ein Smart-CMS-Assistent, der Content-Entwürfe direkt im Redaktions-Flow erstellt, eine zentrale Konfigurationsoberfläche für KI-Anbieter, Modelle und Prompts, und ein Kosten-Schätzer. Dessen Kernidee: Nachvollziehbarkeit, was passiert ist, und Ökonomie, was es gekostet hat, in einer Ansicht, während die meisten Plattformen nur Ersteres liefern. Preise werden einmal je Anbieter und Modell konfiguriert, danach zeigt die Ansicht Kosten je Interaktion, die Gesamtsumme sowie eine Aufschlüsselung nach Anbieter und Modell, mehrwährungsfähig. Dazu wandert die Glue-REST-API technisch auf die API Platform, bei voller Rückwärtskompatibilität für bestehende Clients. Diese Migration selbst ist allgemein verfügbar, nicht Teil des Early-Access-Umfangs.

Was unter der Oberfläche passiert

Neben den sichtbaren Funktionen deckt das Release 202606 eine dritte Ebene ab: die Plattform selbst. Bei der Warteschlangenverarbeitung wurden hängende oder langlaufende Worker-Prozesse besser abgefangen, fehlgeschlagene Nachrichten gehen nicht mehr verloren, wenn keine Retry-Queue existiert, und queue:worker:start --stop-when-empty verhält sich zuverlässiger. Im Dynamic Store Mode reduziert eine neue Key-Value-Storage-Deduplizierung doppelt gehaltene Product-Abstract- und URL-Daten über Store- und Locale-Kombinationen, senkt den Speicherbedarf in Valkey oder Redis und ist opt-in sowie rückwärtskompatibel, relevant vor allem für Multi-Store- und Multi-Locale-Setups.

Dazu kommen mehrere Security-Patches: ein gepatchtes shell-quote gegen eine kritische Shell-Injection-Schwachstelle, ein aktualisiertes symfony/runtime gegen unsichere Request-Argument-Behandlung und ein aktualisiertes symfony/monolog-bridge gegen einen unauthentifizierten Log-Listener, ergänzt um engere IAM-Richtlinien in Kunden-PaaS-Accounts, Nginx 1.30 und Kompatibilität mit den neuen Secure-Transport-Defaults von MariaDB 11.8. Die RDS Auditability Extensions zeichnen Datenbankoperationen in Produktivumgebungen auf und bewahren die Logs zwei Jahre rollierend auf, manuelle Jenkins-Konfigurationen überstehen jetzt Plattform-Updates und Neustarts, und Propel wird mit Version 2.0 LTS Richtung stabiles Release geführt.

Nicht jeder dieser Punkte macht in einem gewachsenen System denselben Unterschied. Queue-Fixes und die Storage-Deduplizierung wirken sofort und ohne eigene Feature-Entscheidung, sobald der Release-Stand gezogen ist. Die Security-Patches sind der Teil, der eine Update-Diskussion nicht braucht, sondern beendet. RDS-Auditierbarkeit und persistente Jenkins-Konfiguration betreffen Betrieb und Compliance, nicht das Produkt, aber genau dort werden Prüfungen und Audits konkret.

Was das für ein bestehendes System bedeutet

Interessant ist an diesem Release weniger die einzelne Funktion als die Richtung. Genau die Dinge, die in vielen B2B-Projekten über Jahre individuell entwickelt wurden, gibt es jetzt im Standard. Wer eine eigene Lösung für wiederkehrende Bestellungen, für Budgetfreigaben oder für PunchOut betreibt, steht damit vor einer nüchternen Abwägung.

Diese Abwägung ist selten eindeutig. Eine gewachsene Eigenentwicklung bildet oft Sonderfälle ab, die der Standard nicht kennt. Zugleich bindet sie dauerhaft Wartungsaufwand und macht künftige Updates aufwändiger, weil sie neben dem Kern gepflegt werden muss. Ob sich eine Ablösung lohnt, hängt an konkreten Fragen: Wie tief sitzt die alte Lösung im System? Deckt der Standard die eigenen Anforderungen wirklich ab oder nur zu achtzig Prozent? Was kostet eine Migration real, und was spart sie danach?

Diese Fragen lassen sich nicht am Release-Text beantworten, sondern nur am konkreten System. Der Wert liegt nicht darin, jede Neuerung sofort einzubauen, sondern darin, zu beurteilen, welche für das eigene System einen Unterschied macht und welche man bewusst liegen lässt.

Der KI-Teil verlangt keine sofortige Entscheidung, ist aber ein Signal. Spryker baut die KI-Basis konsequent in Richtung Back Office aus. Wie schon beim Release 202512 gilt auch hier, zu beurteilen, wo eine KI-Funktion im eigenen Betrieb einen Unterschied macht, statt sie nur zu aktivieren, weil sie da ist.

Die Plattformebene aus dem vorigen Abschnitt braucht dabei eine andere Betrachtung als die Feature-Ebene: Sie erzwingt keine Entscheidung (Standard übernehmen oder eigene Lösung behalten), sondern kommt mit dem Release-Stand automatisch mit, sobald man aktualisiert. Das ist ein Argument dafür, den eigenen Stand nicht zu lange liegen zu lassen.

Einordnung statt Eile

Ein Release ist ein guter Anlass, den eigenen Stand einmal ehrlich anzuschauen, statt zu warten, bis Aufwand oder Risiko von außen den Takt vorgeben. Wenn Sie ein Spryker-System betreiben und vor der Frage Eigenbau gegen Standard stehen, ordne ich das gern mit Ihnen ein.