Migration von Java 8 auf Java 25

Themenübersicht

Bei einer Migration auf die Java-25-Version sind derzeit insbesondere folgende Themen zu beachten:

• Java 25, Tomcat 10 und Keycloak-Integration
• Spring-Profil beim Notification-Service
• Aktualisierung externer Bibliotheken (z. B. JDBC-Treiber oder SAP JCo)
• Persistierung von Action- und Service-Properties
• Aktualisierung von Contents
• Adobe AIR Client und Flex-Adapter
• Searchlayer-Konfiguration
• Contributions und kundeneigene Erweiterungen

Weitere Themen werden mit zukünftigen Produktversionen und neuen Erkenntnissen ergänzt.

Java 25, Tomcat 10 und Keycloak-Integration

Hintergrund

Die Java-25-Version der AEP.B2B setzt eine aktualisierte Laufzeitumgebung auf Basis von Java 25 und Tomcat 10 voraus.

Im Zuge dieser Umstellung wird auch die bisherige Keycloak-Integration über den Tomcat-Keycloak-Adapter abgelöst. Die Authentifizierung erfolgt künftig über Spring Security. Der bisher verwendete Keycloak-Adapter für Tomcat 9 wird unter Tomcat 10 nicht mehr unterstützt.

Die Java-25-Version der AEP.B2B wird als Docker-Image auf Basis von Tomcat 10 ausgeliefert.

Auswirkungen

Mit der Migration auf die Java-25-Version ändern sich die technischen Voraussetzungen für den Betrieb der AEP.B2B.

• Die AEP.B2B setzt künftig Java 25 als Laufzeitumgebung voraus.
• Die Anwendung wird auf Tomcat 10 betrieben. Bestehende Installationen auf Tomcat 8.5 oder Tomcat 9 müssen entsprechend aktualisiert werden.
• Die bisherige Keycloak-Integration über den Tomcat-Keycloak-Adapter wird nicht mehr unterstützt. Die Authentifizierung erfolgt künftig über Spring Security.

Für Kunden, die die von Arvato Systems bereitgestellten Docker-Container verwenden, sind diese Änderungen bereits berücksichtigt. Die Container enthalten die erforderliche Java- und Tomcat-Version.

Kunden mit einer eigenen Tomcat-Installation müssen ihre Laufzeitumgebung entsprechend anpassen. Hierzu gehören insbesondere:

• Installation einer Java-25-Laufzeitumgebung
• Aktualisierung der Tomcat-Installation auf Tomcat 10
• Überprüfung und Anpassung bestehender Tomcat-Konfigurationen (z. B. b2bbp-engine.xml)

Bei einer Nicht-Docker-Installation muss für den B2B-Knoten, der mit Keycloak betrieben wird, das separate Keycloak-WAR-File verwendet werden. Das Standard-WAR-File ist für diesen Knoten nicht vorgesehen.

Anpassung der Tomcat-Konfiguration

In Tomcat 9 wurde die Keycloak-Integration über ein Valve und einen Parameter in der Kontext-Datei konfiguriert. Diese Einträge werden in Tomcat 10 nicht mehr unterstützt und führen dazu, dass der Server nicht startet.

Die Keycloak-bezogenen Valve- und Parameter-Einträge müssen entfernt oder auskommentiert werden.

Beispiel: Aktualisierte b2bbp-engine.xml

Nachfolgend ein Beispiel der aktualisierten Kontext-Konfiguration, in der die nicht mehr unterstützten Keycloak-Einträge auskommentiert wurden:

<?xml version="1.0" encoding="UTF-8"?>
<Context path="/b2bbp-engine"
         reloadable="true"
         crossContext="true">
   <Resource name="jdbc/b2bbp"
             type="javax.sql.DataSource"
             factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
             ...  
             />

<!--
    <Valve className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/>

    <Parameter name="keycloak.config.file"
               value="/usr/local/tomcat/conf/keycloak.json"
               override="false"/>
-->

</Context>

Im Inneren der B2B Docker-Container wird die Keycloak-Konfiguration nun über Spring Security bereitgestellt. Die Keycloak-Adapter-Konfiguration in der b2bbp-engine.xml ist daher nicht mehr erforderlich.

Spring-Profil beim Notification-Service

Für den Notification-Service gab es bisher einen Standardwert für das aktive Spring-Profil. Mit der Java-25-Version entfällt dieser Default. Das zu verwendende Spring-Profil (z. B. keycloak-enriched, wenn Keycloak genutzt wird) muss daher manuell über die Umgebungsvariable SPRING_PROFILES_ACTIVE gesetzt werden.

Beispiel:

environment:
  SPRING_PROFILES_ACTIVE: keycloak-enriched

Aktualisierung externer Bibliotheken

Hintergrund

Einige Bibliotheken werden aus lizenzrechtlichen oder produktspezifischen Gründen nicht zusammen mit der AEP.B2B ausgeliefert, sondern kundenseitig bereitgestellt und in die Laufzeitumgebung eingebunden.

Im Rahmen der Migration auf Java 25 sollte geprüft werden, ob diese Bibliotheken mit der neuen Java-Version kompatibel sind. Ältere Bibliotheksversionen unterstützen Java 25 unter Umständen nicht oder nur eingeschränkt.

Auswirkungen

Insbesondere Installationen mit zusätzlich eingebundenen Bibliotheken oder herstellerspezifischen Konnektoren können betroffen sein.

Dies betrifft beispielsweise:

• JDBC-Treiber (z. B. PostgreSQL, Oracle oder Microsoft SQL Server)
• SAP Java Connector (SAP JCo)
• Bibliotheken zur Anbindung von Archivsystemen (z. B. nscale)
• weitere kundenseitig eingebundene Bibliotheken oder Konnektoren

Erforderliche Anpassungen

Prüfen Sie alle kundenseitig bereitgestellten Bibliotheken auf ihre Kompatibilität mit Java 25.

Hierzu empfiehlt sich folgendes Vorgehen:

1. Ermitteln Sie alle zusätzlich eingebundenen Bibliotheken.
2. Prüfen Sie beim jeweiligen Hersteller, ob eine Java-25-kompatible Version verfügbar ist.
3. Aktualisieren Sie die Bibliotheken gegebenenfalls auf eine unterstützte Version.
4. Testen Sie anschließend die betroffenen Funktionen (z. B. Datenbankzugriffe oder SAP-Kommunikation).

Überprüfung

Nach der Aktualisierung sollten insbesondere die von den externen Bibliotheken bereitgestellten Funktionen überprüft werden.

Dies betrifft beispielsweise:

• Aufbau der Datenbankverbindung
• Kommunikation mit SAP-Systemen
• Anbindung von Archivsystemen
• Funktion weiterer kundenspezifischer Integrationen
• Anwendungsprotokolle auf Warnungen oder Fehlermeldungen prüfen

Persistierung von Action- und Service-Properties

Hintergrund

Mit der Java-25-Version wurde die Persistierung von Action- und Service-Properties angepasst. Der bisherige Verbose-Modus steuert die Persistierung von Action Properties nicht mehr. Stattdessen wird für jede Action Property über die Typ-Konfiguration festgelegt, ob sie als sichtbares Attribut in den Technischen Details, in den Fachlichen Belegen oder in beiden Bereichen gespeichert und angezeigt wird.

Auswirkungen

Action Properties, die ausschließlich wegen der früheren Persistierungslogik als dynamische Funktion konfiguriert wurden, müssen nicht mehr entsprechend angepasst werden. Die dynamische Auswertung einer Property bleibt davon unberührt, wenn sie für den fachlichen Ablauf erforderlich ist.

Für die OutboxAction werden die für die weitere Verarbeitung erforderlichen Action Properties nun standardmäßig persistiert. Diese Properties müssen daher nicht mehr mit dynamischen Funktionen wie ${template(...)} konfiguriert werden, um eine spätere Outbox-Verarbeitung zu ermöglichen.

Erforderliche Anpassungen

Prüfen Sie bei der Migration insbesondere kundenspezifische Actions und die Konfiguration der OutboxAction:

1. Prüfen Sie Action Properties, deren Wert bisher nur deshalb als dynamischer Ausdruck konfiguriert wurde, damit die Property persistiert wird.
2. Entfernen Sie bei diesen Properties den nicht mehr erforderlichen dynamischen Ausdruck. Einen dynamischen Ausdruck müssen Sie beibehalten, wenn er zur Berechnung oder dynamischen Auswertung des Werts benötigt wird.
3. Legen Sie über die Optionen der jeweiligen Action Property fest, ob das Attribut als technisches und/oder fachliches Attribut gespeichert und im Nachrichtenmonitor angezeigt werden soll.
4. Prüfen Sie bei OutboxAction-Properties, ob die Anzeige im Nachrichtenmonitor fachlich erforderlich ist. Für die technische Persistierung der benötigten Outbox-Properties ist keine dynamische Funktion mehr erforderlich.

Beispiel für eine Property, deren dynamischer Ausdruck bisher nur zur Persistierung verwendet wurde:

- B2B_OUTBOX_PRIORITY=${template(5)}
+ B2B_OUTBOX_PRIORITY=5

Die konkrete Kennzeichnung als technisch und/oder fachlich erfolgt in der Action-Konfiguration. Die Anzeige im Nachrichtenmonitor richtet sich nach der gewählten Kennzeichnung.

AS4-Anbindung über den B2B-Message-Service mit dem RestClientService

Die AS4-Anbindung erfolgt in beiden Varianten über den B2B-Message-Service. Die Anbindung über die OutboxAction ist im vorherigen Abschnitt beschrieben. Dieser Abschnitt behandelt die zweite Variante, bei der der B2B-Message-Service direkt über den RestClientService aufgerufen wird.

Bei der in der AS4-Customizing-Dokumentation beschriebenen Übergabe muss zusätzlich geprüft werden, ob der Payload tatsächlich als Attribut gespeichert wird. Der RestClientService verwendet in der URL die attributeId=PAYLOAD und liest die Nachricht anschließend unter diesem Namen aus der Datenbank.

Prüfen Sie daher in der Action Speichern einer AS4-ID und des Payloads insbesondere die Action Property PAYLOAD:

• Der Property-Name muss PAYLOAD lauten und mit der attributeId in der URL des RestClientService übereinstimmen.
• Die Property muss in der Typ-Konfiguration als technisches und/oder fachliches Attribut gekennzeichnet sein, damit sie entsprechend gespeichert wird.
• Wird der Payload nicht unter PAYLOAD gespeichert, müssen die Action Property und die attributeId des RestClientService konsistent auf denselben Namen angepasst werden.

Ohne diese Kennzeichnung kann der B2B-Message-Service den Payload trotz vorhandener SetPropertyAction nicht zuverlässig aus der Datenbank lesen. Prüfen Sie die Übergabe nach der Migration daher mit einer ausgehenden AS4-Nachricht.

B3P_VERBOSE_MODE prüfen

B3P_VERBOSE_MODE ist für die Persistierung von Action Properties nicht mehr maßgeblich. Prüfen Sie bestehende Konfigurationen dennoch auf ihre Verwendung für Service- und ChannelDistribution-Properties. Diese Bereiche können weiterhin von der Property betroffen sein. Entfernen oder ändern Sie B3P_VERBOSE_MODE daher nur, wenn die gewünschte Persistierung dieser Properties geprüft wurde.

Überprüfung

Nach der Anpassung sollten insbesondere folgende Punkte überprüft werden:

• Die erforderlichen Action Properties werden nach der Verarbeitung im Nachrichtenmonitor angezeigt.
• Properties sind entsprechend ihrer Konfiguration als technische und/oder fachliche Attribute sichtbar.
• Outbox-Einträge können nach der Verarbeitung weiterhin durch das Outbox-Relay verarbeitet werden.
• Kundenspezifische Actions und Services funktionieren ohne unerwartete Änderungen bei der Property-Auswertung.

Aktualisierung von Contents

Hintergrund

Über die Contents werden zusätzliche Erweiterungen und Komponenten in die AEP.B2B eingebunden.

Im Rahmen der Migration auf Java 25 sollten die eingesetzten Contents überprüft und gegebenenfalls auf eine kompatible Version aktualisiert werden.

Dies betrifft insbesondere:

• ValidationContent (siehe VC Release Notes 2026.10)
• CXF-WebServices (z. B. der WebService zur Befüllung des Systemweichen-Indexes)

Auswirkungen

Werden veraltete Contents nach der Migration weiterverwendet, kann dies zu Einschränkungen bei der Validierung oder der Bereitstellung von WebServices führen.

Ob eine Aktualisierung erforderlich ist, hängt von den in Ihrer Installation eingesetzten Contents ab.

Erforderliche Anpassungen

Prüfen Sie, welche Contents in Ihrer Installation eingesetzt werden.

Für betroffene Contents sollten die zur eingesetzten AEP.B2B-Version passenden Versionen installiert werden.

Dies betrifft insbesondere:

• ValidationContent (siehe VC Release Notes 2026.10)
• CXF-WebServices

Die aktuellen Versionen stehen im Download-Portal zur Verfügung und können anschließend wie gewohnt über die Administration der AEP.B2B importiert werden.

Überprüfung

Nach der Aktualisierung sollten insbesondere folgende Punkte überprüft werden:

• Validationen werden erfolgreich ausgeführt.
• Bereitgestellte CXF-WebServices stehen weiterhin zur Verfügung.
• Die Kommunikation über die eingesetzten WebServices funktioniert fehlerfrei.

Adobe AIR Client und Flex-Adapter

Hintergrund

Die bisherige Flex-basierte Benutzeroberfläche (Adobe AIR Client) ist nicht mehr Bestandteil der Java-25-Version der AEP.B2B.

Die zugrunde liegenden Technologien Adobe Flash und Adobe AIR werden nicht mehr unterstützt und entsprechen nicht mehr den aktuellen Sicherheits- und Technologieanforderungen. Aus diesem Grund wird der Adobe AIR Client nicht mehr als Teil der AEP.B2B ausgeliefert.

Auswirkungen

Die folgenden Hinweise sind nur relevant, wenn Ihre Installation den Adobe AIR Client verwendet.

Dies betrifft beispielsweise Kunden, die den Adobe AIR Client für das CCM-Monitoring oder andere Flex-basierte Funktionen einsetzen.

Ohne zusätzliche Maßnahmen steht der Adobe AIR Client nach der Migration auf die Java-25-Version nicht mehr zur Verfügung.

Erforderliche Anpassungen

Für den Weiterbetrieb des Adobe AIR Clients stellt Arvato Systems den AEP B2B Flex UI Adapter als separaten Microservice bereit.

Dieser Microservice wird zusätzlich zur AEP.B2B installiert und übernimmt die Kommunikation zwischen dem bestehenden Adobe AIR Client und der Java-25-Version der AEP.B2B.

Dadurch kann der Adobe AIR Client mit seinem bisherigen Funktionsumfang weiterhin verwendet werden.

Überprüfung

Nach der Installation des Flex-Adapter-Microservice sollten insbesondere folgende Punkte überprüft werden:

• Verbindung des Adobe AIR Clients zur AEP.B2B
• Anmeldung am Adobe AIR Client
• Funktion der verwendeten Monitoring- und Administrationsfunktionen (z. B. CCM)
• Prüfung der Anwendungsprotokolle auf Kommunikationsfehler

Searchlayer-Konfiguration

Hintergrund

Die folgenden Hinweise sind nur für Installationen relevant, die Solr als Searchlayer verwenden.

Kunden, die weiterhin den Lucene-basierten Searchlayer einsetzen, sind von den nachfolgenden Änderungen nicht betroffen.

Mit der Java-25-Version wurde die Solr-Anbindung auf SolrCloud umgestellt. Dadurch kommuniziert die AEP.B2B nicht mehr direkt mit einem Solr-Knoten, sondern mit dem zugehörigen ZooKeeper-Cluster.

Auswirkungen

Installationen mit Solr als Searchlayer müssen ihre Searchlayer-Konfiguration anpassen.

Die bisherige Konfiguration verwies direkt auf einen Solr-Server. Mit SolrCloud muss stattdessen die Verbindung zum ZooKeeper-Cluster konfiguriert werden.

Erforderliche Anpassungen

Passen Sie die Extension SEARCH_LAYER_CONFIGURATION entsprechend an.

Die Eigenschaft

SOLR_URLS

muss künftig auf den ZooKeeper-Cluster statt auf den Solr-Server zeigen.

Beispiel

 SEARCH_SYSTEM_VENDOR=SOLR
 SEARCH_TYPES=FULLTEXT,SYSTEMSPLIT_METERINGPOINT,SYSTEMSPLIT_RESPONSE,ARCHIVE

-SOLR_URLS=http://solr1:8983/solr
+SOLR_URLS=zoo1:2181

 FULLTEXT_SOLR_COLLECTION=fulltext
 SYSTEMSPLIT_METERINGPOINT_SOLR_COLLECTION=systemsplit_meteringpoint
 SYSTEMSPLIT_RESPONSE_SOLR_COLLECTION=systemsplit_response
 ARCHIVE_SOLR_COLLECTION=archive

2181 ist der Standard-Port von ZooKeeper. Der tatsächlich verwendete Hostname und Port richten sich nach Ihrer Infrastruktur.

Bei bisherigen Migrationen wurde b2b-zookeeper:2181/solr verwendet. Hier war das anfügen von /solr wichtig!

Überprüfung

Prüfen Sie nach der Anpassung insbesondere:

• Der Searchlayer startet fehlerfrei.
• Suchanfragen liefern weiterhin Ergebnisse.
• Im Anwendungsprotokoll werden keine Verbindungsfehler zum ZooKeeper-Cluster protokolliert.

Contributions und kundeneigene Erweiterungen

Hintergrund

Im Rahmen der Java 25 / Jakarta EE Migration wurden Klassen mit Dritt-Copyright (d.h. Copyright, das nicht bei Arvato Systems oder Next Level Integration liegt) aus der B2B Shell (aep-b2b-monolith-shell) und dem B2B Core (aep-b2b) entfernt. Diese Klassen wurden in ein separates Open-Source-Repository ausgelagert: aep-b2b-contributions.

Die fertig gebauten Contribution-JAR-Dateien stehen im Download Portal zum Download bereit unter Private/aep/b2b/aep-b2b-contributions/.

Wenn Ihre B2B-Installation eine der ausgelagerten Contribution-Klassen verwendet (z.B. org.gdf.z1compliancecheck.services.MailService, org.e4u.zugferd., org.b2bbp.runtime.secunet.), müssen Sie die Contribution-JARs wie unten beschrieben zu Ihrem B2B-Container hinzufügen.

Auswirkungen

Die folgenden Hinweise sind nur relevant, wenn Ihre Installation Contribution-Klassen verwendet.

Ob Sie betroffen sind, können Sie anhand Ihrer kundenspezifischen Konfiguration prüfen. Kontrollieren Sie insbesondere eigene

• Actions
• Services
• ChannelDistributions

Werden dort Klassen verwendet, deren Paketname nicht zu den Standardpaketen der AEP.B2B gehört (org.b2bbp.*, com.nextlevel.*, com.b2bbp.*), sollten diese im Rahmen der Migration überprüft werden.

Sind entsprechende Contribution-Klassen im Einsatz, muss die zugehörigen Contribution-JARs zusätzlich zur AEP.B2B in die Installation integriert werden.