SAP NetWeaver Portal 7.3 Migration – Lessons Learned: Die Applikationen

Bei der Planung einer SAP NetWeaver Portal Migration denkt man zunächst vor allem an den Upgrade des Applikationsservers. Geht es zum Beispiel von der weit verbreiteten NetWeaver Version 7.0 auf ein aktuelles Release 7.3 oder 7.4, dann gibt es dafür verschiedene Varianten.

Die verschiedenen Varianten werden hier schon einmal erläutert: SAP NetWeaver Portal 7.3 Migration – Lessons Learned Teil 1

SAP NetWeaver Portal 7.3

Aber Vorsicht – nicht die eigenen Applikationen vergessen! Die selbstgeschriebenen Web Dynpro Java Anwendungen, Visual Composer und Java EE Entwicklungen laufen nicht einfach so weiter und müssen in das Migrationsprojekt mit einbezogen werden.

Die Entwicklungsumgebung

Natürlich kommt für die Java Entwicklung das SAP NetWeaver Developer Studio (NWDS) zum Einsatz. Es empfiehlt sich, hier stets die Version einzusetzen, die zum Laufzeitumgebung passt. Also für den Application Server 7.3 SP09 Patch 11 auch das NWDS 7.3 SP09 Patch 11. Bei den Hotfixes innerhalb eines Patches kann man ohne Probleme abweichen.

Das NWDS 7.3 basiert auf Eclipse 3.5 und es wird in Java 6 entwickelt. Nicht mehr ganz der neueste Schrei – aber zur Version 7.0 immerhin ein Fortschritt.

Alle Versionen zum Download findet man hier auf der Update-Site (S-User erforderlich): SAP NWDS-Update-Site

Die Migration der SAP NetWeaver Development Infrastructure (NWDI) kann man getrost als eigenes Projekt angehen und getrennt von der Portalmigration durchführen. Für den Server zur Verwaltung der Entwicklungsprojekte und Sourcen gilt die Regel der Versionsgleichheit nämlich nicht: Eine NWDI 7.0 kann Entwicklungen für alle möglichen Laufzeitumgebungen aufnehmen.

Der Grundsatz: Laufzeitkompatibilität

Für die meisten der selbstentwickelten Applikationen gilt: Die Archive aus der Version 7.0 sind weiter lauffähig. Es kommt also auf einen Versuch an, sie auf den neuen Server zu deployen und zu testen. Für die Zukunft bringt dieser Ansatz einen aber nicht wirklich weiter. Für Fehlerbehebung und Wartung und vor allem natürlich für die Weiterentwicklung müssen Sourcecode und Entwicklungsprojekte migriert werden.

Web Dynpro Java

In der internen Architektur von Web Dynpro Java Anwendungen hat sich in den Nachfolgeversionen von NetWeaver 7.0 Verschiedenes geändert. APIs wurden umstrukturiert und benutzte Softwarekomponenten geändert. Besonders eine strukturelle Änderung fällt auf: Der Interface Controller der Komponenten macht seinem Namen jetzt endlich alle Ehre. Er ist fungiert als Interfacedefinition und trägt keinen eigenen Code mehr.

Um das Entwicklungsprojekt einer Web Dynpro Anwendung aus Version 7.0 nach 7.x zu migrieren, geht man wie folgt vor:

1. Das Projekt per Filesystem oder besser über die ganze Development Configuration über die NWDI in das neue Developer Studio importieren
2. Der Import erfolgt in jedem Fall als DC-Projekt, als im SAP Komponentenmodell
3. Es wird automatisch ein Migrationsassistent gestartet, der die zwingend erforderlichen Schritte durchführt
4. Im Anschluss können kleinere manuelle Nacharbeiten erforderlich sein, wie zum Beispiel das Schlüsselwort ENUM zu ersetzen (das erst seit Java 6 eben ein Schlüsselwort ist).
5. Es kann passieren, dass die Used-DC Definitionen des neuen Projektes noch auf neue SAP Bibliotheken angepasst werden müssen, bevor das neue Projekt zum ersten Mal erfolgreich kompiliert. Das Wichtigste ist geschafft!
6. Wer sauber sein will, kann sich daran machen alle Verwendungen von deprecated API zu ersetzen. Diese werden durch Warnungen gekennzeichnet.

Schließlich besteht auch die Möglichkeit, wie oben erwähnt den Aufbau der Interface Controller auf die neue Struktur zu migrieren. Das kann manuell an jeder einzelnen Komponente durchgeführt werden. Allerdings liegt es in der Natur der Sache, dass hier nur begrenzt automatische Assistenten helfen können. Der Inhalt der Interfacecontroller muss in den Komponentencontroller umgezogen werden und die Programmlogik entsprechend manuell angepasst werden. Diesen Aufwand wird man in der Regel nicht ohne Not betreiben.

Manuelle Anpassungen

Java EE

Ganz ähnlich sieht es für Java EE aus. Die Laufzeitumgebung unterstützt sowohl Anwendungen nach dem dem J2EE 1.4 Standard, als auch nach Java EE 5.

Beim Import der Projekte in das NWDS tritt ein Migrationsassistent in Aktion. Im Nachgang kann man entscheiden, ob man den zweiten Schritt gehen will und alle Applikationen auf Version Java EE 5 bringt. Dabei geht es dann in der Regel darum, ob neue Features zum Einsatz in der Weiterentwicklung kommen sollen. Ein Beispiel: Der in der Version 7.0 verbreitete “Deployable Web Service Proxy” ist in NetWeaver 7.3 nicht mehr verfügbar. Stattdessen lassen sich Web Service Proxies ganz einfach durch Annotations in Enterprise Java Beans (EJB 3.0) implementieren.

Visual Composer

Beim Visual Composer liegt die Sache anders. Die unter Version 7.0 kompilierten Modelle sind zwar unter 7.3 noch lauffähig, die Entwicklungsumgebung wurde allerdings komplett überabreitet.

Gerade bei komplexen Modellen ist erhebliche manuelle Nacharbeit erforderlich, um diese nach dem Import im Visual Composer weiterentwickeln zu können. Das Verzwickte daran: Um die alten Modelle weiter warten zu können, braucht man weiterhin einen kompletten Application Server 7.0. Es gibt SAP Kunden, die eine Entwicklungsinstanz nur deshalb weiter betreiben, weil Visual Composer Modelle nicht auf die Version 7.3 migriert werden können.

Sie sind noch am Ball und haben Interesse an einem Netweaver Upgrade? Wir übernehmen das für Sie im Rahmen unserer Lösung: SAP NetWeaver Portal Migration.

Fazit

Im Rahmen einer Migration das SAP NetWeaver Portals muss man die selbstentwickelten Anwendungen immer mit betrachten.

Man kann aber schrittweise vorgehen und parallel zum Serverupgrade die Anwendungen soweit aktualisieren, dass sie lauffähig und wartbar sind.

Die weiteren optionalen Schritte für die Weiterentwicklung lassen sich dann aber gut separat planen und durchführen, wenn das Migrationsprojekt abgeschlossen ist.

Welche Erfahrungen haben Sie bei der Migration von Anwendungen gemacht? Wo liegen aus Ihrer Sicht die Fallstricke? Ich freue mich über Kommentare.

Ingo Biermann

Als Management- und Technologieberater unterstütze ich seit mehr als 15 Jahren große und mittelständische Unternehmen in Fragen der IT-Strategie und bin unterwegs in unterschiedlichen SAP-Themen wie SAP S/4HANA, User Experience und SAP Entwicklung.

Sie haben Fragen? Kontaktieren Sie mich!