Migracja z RPG do Java w oprogramowaniu ERP

W 2021 roku nawiązaliśmy współpracę z Aptean, jednym z liderów technologicznych w zakresie oprogramowania biznesowego dla średnich przedsiębiorstw w przemyśle i handlu hurtowym. Firma dostarcza niestandardowe oprogramowanie ERP, ponieważ jest ono jak najbardziej zbliżone do wymagań procesowych i aplikacyjnych grup docelowych w przemyśle maszynowym, handlowym, medycznym i motoryzacyjnym. Oprogramowanie ERP opracowane przez klienta jest dostępne w wielu językach, co oznacza, że może być używane w różnych krajach.

Systemy ERP zostały wdrożone kilkanaście lat temu u klientów końcowych. Standardowo są wspierane i rozwijane przez producentów przez okres dwóch lat. Jednak z czasem firmy się skalują, a procesy ewoluują, co wpływa na potrzebę specyficznego dostosowania systemów do działalności. Przez jakiś czas klienci zatrudniali własnych deweloperów, rozumiejących składnię RPG (AS/400) bądź też działali z różnymi dostawcami. Jednak wszystko to działo się poza dokumentacją, więc funkcjonowało tylko doraźnie na potrzeby firm.  Chociaż systemy ERP działy nadal, to jednak obecnie RPG jest już starszą technologią, co do której trudno jest znaleźć programistów w ramach dalszego rozwoju.

Firmy zatem stoją przed wyborem, albo zdecydują się na powrót do producenta systemu ERP i budowę systemu na nowo, co jest niezwykle drogie, lub też przeprowadzą migrację swojego dostosowanego systemu do nowszej technologii. Na to w większości decydują się firmy współpracując z zespołami Klienta i VM.PL

W początkowej fazie nad projektami pracowało trzech programistów. Obecnie Klient zatrudnia 15-osobowy zespół VM.PL, w skład którego oprócz programistów wchodzą również project manager, konsultant biznesowy oraz customer success manager.

W całym procesie bezpośrednio współpracujemy z Klientem, który zajmuje się bezpośrednim konsultingiem u klientów końcowych.  Projekty migracji z RPG na Java 11 wykonywaliśmy dla firm zajmujących się m.in:

• Dostarczaniem gazów medycznych i do przemysłu spożywczego
• Produkcją maszyn przemysłowych
• Produkcją pomp ciepła i systemów grzewczych
• Produkcją produktów drukarskich
• Dostarczaniem rozwiązań telekomunikacyjnych

Migracja z RPG do Java

Proces migracji zaczyna się od tego, że przede wszystkim poznajemy stary system ERP z oryginalnymi wersjami bibliotek każdego klienta, który w całości jest napisany w RPG. Każda firma posiadająca taki system ERP ma zbudowane modyfikacje i funkcjonalności pod potrzeby swojego biznesu. Po analizie starszego kodu, budujemy na nowo kompleksowy kliencki framework, posiadający swoje specyficzne swoje założenia i oparty na Java 11.

Naszym zadaniem jest zbudowanie świeżej wersji systemu ERP posiadającej wszystkie niezbędne modyfikacje systemu, które są na nowo wdrożone do systemu. W obrębie zespołu się nauczyliśmy, jak interpretować ten kod i wdrażać modyfikacje klientów, analizując też działania starszego programu.

Oprócz działań backendowych, wykorzystujemy narzędzie JET (Java Emitter Template) do generowania pól, wartości, opisów i wykresów niezbędnych do obsługi systemu ERP.

Nasz zespół nie ma problemu ze zrozumieniem systemu RPG, który mimo wszystko nie należy do łatwych z powodu poziomu złożoności systemów ERP.

“Bardzo wiele sporych systemów np. systemy bankowe czy inne platformy ERP są oparte na kodzie RPG, a coraz mniej programistów jest w stanie go obsłużyć, ponieważ mało kto się już tego uczy. Dzięki temu, że nasze zespoły rozumieją sposób działania kodu i jego zależności, posiadamy znaczącą przewagę technologiczną.”  Daniel Hodaniewicz, Backend-Engineer

Jakie wyzwania pokonujemy? 

• Konflikty modyfikacji systemu ERP 

Kiedy wdrażana jest nowsza wersja oprogramowania, wtedy dla każdego klienta tak naprawdę osobno się wdrażamy update wersji. Wynika to z faktu, że niekiedy modyfikacje mogą powodować pewne problemy, kiedy były tworzone pod specyficzne potrzeby klienta, dlatego przy każdej aktualizacji na bieżąco rozwiązujemy konflikty funkcjonalności.

• Kwestie wydajnościowe  

Czasami pojawiają się problemy z wydajnością i wtedy szukamy nowych rozwiązań, optymalizujących wydajność z poziomu Java. W trakcie analizy kodu znajdujemy również kwestie do poprawy przy następnej globalnej aktualizacji systemu.

• Monolityczna architektura systemu 

Systemy ERP nie posiadają architektury poszczególnych mikroserwisów, tylko stanowią jeden duży monolit, co powoduje, że np. niekiedy wywołanie jednej funkcji wywołuje nagle 10 różnych metod z 10 różnych obszarów. Wymaga to analizy oraz zasięgnięcia wiedzy ekspertów, którzy budowali dany rodzaj zależności w systemie ERP.

Proces migracji można podzielić na etapy:

1. Spotkanie konsultanta ERP z klientem (analiza i planowanie)
2. Development – migracja z RPG na Java
3. Wdrożenie i testy
4. Utrzymanie systemu minimum przez rok.

Podnoszenie wersji systemu ERP

Niektórzy klienci mają już nowszy system, wtedy my posiadając bazowy system, dostosowujemy go do potrzeb klienta. Dlatego oprócz migracji kodu zajmujemy się też zmianą wersji, jeśli wersja kliencka systemu ERP to np. 4.1, podnosimy ją na wersję 7.2. Jest to korzystne rozwiązanie zwiększające wydajność i poprawiające bezpieczeństwo systemu. W trakcie podnoszenia wersji systemu sprawdzamy, jakie modyfikacje zostały wdrożone w systemie klienta, tak by je implementować już w nowej wersji.

Budowa aplikacji webowej i mobilnej dostosowanej do potrzeb klienta

Dla firmy zajmującej się przeładunkiem i transportem towarów płynnych wraz z zespołem Klienta budujemy nowy system kart paliwowych. Firma klienta końcowego operuje na wewnętrznym systemie ERP, zajmującym się m.in obsługą pojazdów, stacji benzynowych, myjni itd.  Celem projektu jest unifikacja obecnie rozproszonych czterech systemów i utworzenie jednej platformy umożliwiającej wdrożenie kart dla kierowców, którymi mogliby się posługiwać przy tankowaniu paliw.

Zespół złożony z analityka ERP, programistów i product managera regularnie przeprowadza warsztaty produktowe u klienta końcowego, aby zdobyć szczegółowe informacje na temat wymagań projektowych potrzebnych do budowania nowych funkcjonalności.

Proces rozwoju następuje w sposób zwinny (Agile) i stopniowo budujemy prototypy, dodając funkcjonalności, które klient testuje, a następnie rozwijamy je bardziej szczegółowo.

Systematycznie wprowadzamy usprawnienia w systemach Klienta, które wymagają transferu do nowszych technologii. Umacniamy współpracę projektową nie tylko poprzez spotkania zdalne, lecz również osobiste, tak by na bieżąco budować relacje, wzmacniać wzajemne zaufanie i dogłębnie omawiać procesy.

Dzięki wysokiej znajomości języka niemieckiego zespół VM.PL płynnie kontaktuje się z klientami końcowymi, co znacząco poprawia jakość i tempo pracy, wzajemne zrozumienie i atmosferę.