RPG-zu-Java-Migration in ERP-Software

Im Jahr 2021 haben wir uns mit Aptean, einem der Technologieführer für Unternehmenssoftware für mittelständische Unternehmen in Industrie und Großhandel zusammengeschlossen. Das Unternehmen bietet maßgeschneiderte ERP-Software an und verfolgt dabei immer möglichst nah die Prozess- und Anwendungsanforderungen der Zielgruppen Maschinenbau, Handel, Medizin und Automotive. Die vom Kunden entwickelte ERP-Software ist mehrsprachig und damit in verschiedenen Ländern einsetzbar.

ERP-Systeme wurden vor einigen Jahren bei Endkunden eingeführt. Standardmäßig werden sie von den Herstellern für einen Zeitraum von zwei Jahren unterstützt und entwickelt. Im Laufe der Zeit werden die Unternehmen jedoch größer und die Prozesse entwickeln sich weiter, was sich auf die Notwendigkeit auswirkt, die Systeme speziell an das Unternehmen anzupassen. Eine Zeit lang stellten die Kunden ihre eigenen Entwickler ein, die die RPG (AS/400)-Syntax verstanden oder mit verschiedenen Anbietern zusammenarbeiteten. All dies geschah jedoch außerhalb der Dokumentation, so dass es nur auf einer Ad-hoc-Basis für geschäftliche Anforderungen funktionierte. Obwohl die ERP-Systeme weiterhin in Betrieb sind, ist RPG nun eine ältere Technologie, für die es schwierig ist, Entwickler für die weitere Entwicklung zu finden.

Die Unternehmen stehen daher vor der Wahl: Entweder sie entscheiden sich dafür, zum ERP-Systemanbieter zurückzukehren und das System neu aufzubauen, was extrem teuer ist, oder sie migrieren ihr maßgeschneidertes System auf eine neuere Technologie. Die meisten Unternehmen entscheiden sich für diesen Weg und arbeiten dabei mit den Teams des Kunden und VM.PL zusammen.

In der Anfangsphase arbeiteten drei Programmierer an den Projekten. Derzeit beschäftigt der Kunde zusätzlich ein 15-köpfiges VM.PL-Team, zu dem neben den Programmierern auch ein Projektmanager, ein Unternehmensberater und ein Customer Success Manager gehören.

Während des gesamten Prozesses arbeiten wir direkt mit dem Kunden zusammen und beraten die Endkunden direkt. Wir haben Migrationsprojekte von RPG zu Java 11 für Unternehmen aus den folgenden Bereichen durchgeführt::

Versorgung mit medizinischen und lebensmitteltechnischen Gasen

• Herstellung von Industriemaschinen
• Herstellung von Wärmepumpen und Heizungsanlagen
• Herstellung von Druckerzeugnissen
• Bereitstellung von Telekommunikationslösungen

Umstellung von RPG auf Java

Der Migrationsprozess beginnt mit dem Kennenlernen des alten ERP-Systems mit den Originalversionen der Bibliotheken des jeweiligen Kunden, die vollständig in RPG geschrieben sind. Jedes Unternehmen mit einem solchen ERP-System verfügt über Modifikationen und Funktionalitäten, die auf die Bedürfnisse seines Unternehmens zugeschnitten sind. Nach der Analyse des älteren Codes haben wir ein neues umfassendes Client-Framework mit seinen Besonderheiten auf der Grundlage von Java 11 entwickelt.

Unsere Aufgabe ist es, eine neue Version des ERP-Systems zu erstellen, in der alle notwendigen Änderungen am System neu implementiert sind. Wir haben im Team gelernt, wie man diesen Code interpretiert, Kundenänderungen umsetzt und die Abläufe des älteren Programms analysiert.

Zusätzlich zu den Backend-Aktivitäten verwenden wir das Java Emitter Template (JET) Tool, um die Felder, Werte, Beschreibungen und Diagramme zu generieren, die für den Betrieb des ERP-Systems erforderlich sind.

Unser Team hat keine Probleme, das RPG-System zu verstehen, was aufgrund der Komplexität von ERP-Systemen jedoch nicht einfach ist.

„Eine große Anzahl großer Systeme, z. B. Bankensysteme oder andere ERP-Plattformen, basieren auf RPG-Code, und immer weniger Programmierer können damit umgehen, weil nur noch wenige Menschen diese Sprache lernen. Wir haben einen erheblichen technologischen Vorsprung, weil unsere Teams verstehen, wie der Code funktioniert und welche Abhängigkeiten bestehen.“  Daniel Hodaniewicz, Backend-Ingenieur

Welche Herausforderungen bewältigen wir? 

• Konflikte bei der Änderung des ERP-Systems 

Wenn eine neuere Version der Software eingeführt wird, führen wir das Versionsupdate für jeden Kunden einzeln durch. Der Grund dafür ist, dass Änderungen manchmal Probleme verursachen können, wenn sie für die spezifischen Bedürfnisse des Kunden erstellt werden, so dass wir bei jedem Update laufend Funktionskonflikte lösen.

• Leistungsprobleme  

Manchmal treten Leistungsprobleme auf, und dann suchen wir nach neuen Lösungen, um die Leistung innerhalb von Java zu optimieren. Bei der Analyse des Codes finden wir auch Probleme, die wir bei der nächsten globalen Systemaktualisierung verbessern können.

• Monolithische Systemarchitektur 

ERP-Systeme haben keine Architektur aus einzelnen Microservices, sondern sind ein großer Monolith, was bedeutet, dass zum Beispiel der Aufruf einer Funktion manchmal plötzlich zehn verschiedene Methoden aus zehn verschiedenen Bereichen aufruft. Dies erfordert eine Analyse und Untersuchung durch Experten, die die Art der Abhängigkeiten im ERP-System aufgebaut haben.
Der Migrationsprozess kann in verschiedene Phasen unterteilt werden:

1. ERP-Beratergespräch mit dem Kunden (Analyse und Planung)
2. Entwicklung – Migration von RPG zu Java
3. Durchführung und Prüfung
4. Mindestens ein Jahr lange Wartung des Systems.

Aktualisierung der Version des ERP-Systems

Einige Kunden haben bereits ein neueres System, und da wir ein Basissystem haben, passen wir es an. Daher befassen wir uns neben der Migration des Codes auch mit Versionswechseln. Wenn die Version des ERP-Systems des Kunden zum Beispiel 4.1 ist, aktualisieren wir es auf die Version 7.2. Diese vorteilhafte Lösung erhöht die Effizienz und verbessert die Sicherheit des Systems. Bei der Aktualisierung der Systemversion prüfen wir, welche Änderungen im System des Kunden vorgenommen wurden, damit sie in der neuen Version bereits implementiert sind.

Erstellung einer maßgeschneiderten Web- und Mobilanwendung

Wir bauen zusammen mit dem Team des Kunden ein neues Tankkartensystem für ein Unternehmen, das Flüssiggüter umschlägt und transportiert. Das Unternehmen des Endkunden arbeitet mit einem internen ERP-System, das unter anderem Fahrzeuge, Tankstellen, Waschanlagen usw. verwaltet. Das Projekt zielt darauf ab, die vier derzeit verstreuten Systeme zu vereinheitlichen und eine einzige Plattform für die Einführung von Karten zu schaffen, die die Fahrer beim Tanken verwenden können.

Ein Team, bestehend aus einem ERP-Analysten, Entwicklern und einem Produktmanager, führt regelmäßig Produktworkshops beim Endkunden durch, um detaillierte Informationen über die Designanforderungen zu erhalten, die für die Entwicklung neuer Funktionen erforderlich sind.

Der Entwicklungsprozess folgt einem agilen Ansatz, bei dem wir schrittweise Prototypen erstellen und Funktionen hinzufügen, die der Kunde testet und dann detaillierter entwickelt.

Wir nehmen systematisch Verbesserungen an Kundensystemen vor, die den Übergang zu neueren Technologien erfordern. Wir verstärken die Projektzusammenarbeit durch Fernsitzungen und persönliche Treffen, um Beziehungen auf einer kontinuierlichen Basis aufzubauen, das gegenseitige Vertrauen zu stärken und Prozesse eingehend zu diskutieren.

Da das VM.PL Team die deutsche Sprache beherrscht, verlief die Kommunikation mit den Endkunden stets fließend, was die Qualität und das Tempo der Arbeit, das gegenseitige Verständnis und die Atmosphäre erheblich verbessert.