SAP S/4HANA to kompleksowe, modułowe oprogramowanie ERP nowej generacji, całkowicie oddzielone od klasycznych rozwiązań SAP Business Suite (SAP ECC). Dlatego też często używa się określenia „konwersja systemu”, a nie „upgrade” do określenia migracji z SAP ERP, działającego na dowolnej bazie danych, do systemu S/4HANA. Te określenia nie są bezpodstawne. W tym przypadku migracja odbywa się z jednego produktu SAP (Business Suite, ECC) do zupełnie nowego produktu (S/4HANA), zbudowanego z wykorzystaniem nowej architektury i modelu danych, zawierającego zmodernizowane aplikacje oraz nową technologię interfejsu użytkownika (SAP Fiori).
Rozszerzenia ABAP a S/4
Podczas implementacji własnego kodu ABAP w klasycznym SAP ECC programista może zajrzeć do kodu SAP, zmodyfikować go lub ulepszyć zgodnie ze specyficznymi wymaganiami biznesowymi, może korzystać z dowolnego modułu funkcyjnego SAP praktycznie bez żadnych ograniczeń. Z jednej strony jest to niezwykle elastyczne podejście, pozwalające na pracę z kodem ABAP w sposób open source. Z drugiej jednak strony stwarza to wiele zależności między niestandardowym kodem klienta a oryginalnym kodem SAP.
Do tej pory nie stanowiło to dużego problemu podczas upgrade’ów ze względu na kompatybilność wszystkich nowych wersji SAP Business Suite i EHP z poprzednimi wersjami. Jednak w SAP S/4HANA sytuacja uległa zmianie. Duża część standardowego kodu SAP w systemie SAP S/4HANA została uproszczona, a w niektórych przypadkach zmieniona w sposób niekompatybilny (np. usunięcie niektórych pól z tabel bazy danych lub nawet usunięcie całych tabel bazy danych). Nie oznacza to oczywiście, że system SAP S/4HANA został zmieniony całkowicie. Nadal duża część niestandardowego kodu może działać bez zmian lub tylko z kilkoma korektami. Dodatkowo w ramach dokonanych uproszczeń SAP dostarczył alternatywne obiekty (np. widoki zgodności CDS przy zmianie modelu danych), dzięki którym niestandardowy kod może zostać dostosowany w sposób transparentny dla użytkownika.
Trzeba jednak mieć świadomość, że w SAP S/4HANA niektóre z niestandardowych obiektów ABAP nie będą już działać prawidłowo lub zgodnie z oczekiwaniami albo będą powodować błędy składni, zrzuty ekranu (short dumps) itp. Najprawdopodobniej część niestandardowego kodu ABAP będzie musiała zostać dostosowana.
Adaptacja niestandardowego kodu ABAP jest bardzo ważnym krokiem na drodze transformacji do systemu SAP S/4HANA. Można go podzielić na dwie główne fazy:
- Przed konwersją systemu SAP S/4HANA (before conversion) – w fazie przygotowania – zaleca się pozbycie starego, nieużywanego kodu niestandardowego, a następnie przeanalizowanie niestandardowego kodu ABAP za pomocą platformy ABAP Test Cockpit (ATC) i sprawdzenie, które obiekty należy dostosować, aby uzyskać kod poprawny z punktu widzenia SAP HANA i SAP S/4HANA (kontrole SAP S/4HANA);
- Po konwersji systemu SAP S/4HANA (after conversion) – w fazie realizacji – należy dostosować swój niestandardowy kod ABAP do nowego oprogramowania SAP S4/HANA (adaptacja funkcjonalna), a następnie można zoptymalizować wydajność aplikacji z wykorzystaniem możliwości bazy danych SAP HANA (tuning wydajności).
Etapy adaptacji niestandardowego kodu ABAP w procesie migracji do systemu SAP S/4HANA
Część prac można przygotować i wykonać już wcześniej, w istniejącym pejzażu systemów SAP Business Suite. Za pomocą standardowych narzędzi (transakcja SCMON oraz UPL) można zbierać dane dotyczące produktywnie wykorzystywanego, niestandardowego kodu ABAP w celu wykrycia i oczyszczenia systemu z nieużywanego niestandardowego kodu przed właściwą konwersją do SAP S/4HANA.
Dodatkowo, aby zminimalizować zakres dostosowań w projekcie konwersji S/4, już wcześniej warto wprowadzać nowe rozwiązania „S/4HANA ready”, i obligować deweloperów, aby powstający kod był w miarę możliwości zgodny z wymaganiami bazy danych SAP HANA.
Prezentujemy zalecenia, które warto wcielić w życie już teraz, w środowisku SAP ECC Business Suite, aby przygotować niestandardowy kod ABAP na bezpieczną podróż do SAP S/4HANA.
- Należy zebrać dane o produktywnie wykorzystywanych niestandardowych rozwiązaniach i zapytaniach SQL, wykorzystując SCMON (ABAP Call Monitor) lub UPL (Usage Procedure Logging in SAP Solution Manager), włączyć SQL Monitor (transakcja SQLM).
- Tworząc nowy kod S/4HANA ready, warto wykorzystać ATC lub SCI (SAP Code Inspector) z wariantami FUNCTIONAL_DB / FUNCTIONAL_DB_ADDITION (dla SCI nota 1935918).
Sprawdzenie SAP HANA i SAP S/4HANA
Sprawdzenie SAP HANA i SAP S/4HANA to dwa najważniejsze kroki w przygotowaniu niestandardowego kodu ABAP podczas konwersji do S/4. W tej fazie kod ABAP jest sprawdzany pod względem zmian związanych z migracją do bazy danych SAP HANA oraz zmian związanych z nowym systemem.
SAP S/4HANA jest bezpośrednio powiązany z bazą danych SAP HANA. Kod ABAP działa na bazie danych SAP HANA tak samo jak na każdej innej wspieranej bazie danych. A zatem co i dlaczego należy dostosować do bazy SAP HANA? Jeden z powodów to możliwość wykorzystania natywnych elementów języka SQL związanego z poprzednią bazą danych. Takie specyficzne odwołania i zależności muszą zostać wyeliminowane w związku z migracją do nowego środowiska bazy danych.
Innym powodem, być może najczęstszym, jest wykorzystanie w niestandardowym kodzie ABAP składni SELECT z pominięciem elementu ORDER BY. Takie wywołanie zapytań może prowadzić do nieoczekiwanych rezultatów, gdy baza danych zostanie zmieniona. Dzieje się tak, ponieważ w przypadku pominięcia ORDER BY wyniki mogą być zwracane w innej kolejności. Do tej pory programiści byli przyzwyczajeni, że wyniki zapytań zwracane są w domyślniej kolejności zgodnej z kluczem podstawowym w tabeli bazy danych. W przypadku SAP HANA, jej architektury i mechanizmu optymalizacji zapytań, kolejność wyników zapytania jest inna. Dlatego też należy sprawdzić, czy instrukcje SQL SELECT bez elementu ORDER BY są nadal poprawne.
Kolejny powód dostosowań to fakt, że tabele typu Pool/Cluster zostały usunięte w SAP HANA. Dlatego operacje bazy danych na tych tabelach również należy usunąć z niestandardowego kodu ABAP.
Aby przygotować niestandardowy kod ABAP do właściwej konwersji do SAP S/4HANA, należy porównać swój kod z tzw. bazą danych uproszczeń (Simplifications Database).
Najważniejsze sprawdzenia SAP S/4HANA:
- Field Extension – sprawdza konflikt długości dla pól z numerem materiału;
- Search DB operations – wyszukuje operacje zapisu na określonych tabelach bazy danych;
- Search for usages of simplified objects – znajduje wykorzystania obiektów z Simplification Database;
- Search for ABAP Dictionary enhancements – sprawdza rozszerzenia w słowniku danych (np. Appendy);
- Search for base table of ABAP Dictionary views – szuka wykorzystania tabel bazy danych we wglądach;
- Search for S/4HANA related Syntax errors – próbuje znaleźć błędy składni w odniesieniu do obiektów z listy uproszczeń (simplifications).
Preferowanym narzędziem do przeprowadzenia kontroli kodu pod względem zgodności z SAP S/4HANA i SAP HANA jest ATC – ABAP Test Cockpit, z opcją zdalnej analizy kodu. Wystarczy skonfigurować jeden centralny system ATC dla wszystkich statycznych kontroli niestandardowego kodu ABAP w całym pejzażu systemów. Kontrola kodu pod względem zgodności z SAP S/4HANA i SAP HANA odbywa się poprzez wykonanie sprawdzenia kodu z wykorzystaniem wariantu S4HANA_READINESS. W ATC całkowity możliwy zakres kontroli obejmuje niestandardowy kod w rozszerzeniach, modyfikacjach, exitach, formularzach SmartForms i Adobe Forms, z pominięciem includów SAP i wygenerowanego kodu.
W wyniku działania ATC z podanym wariantem otrzymujemy listę niezgodności poszczególnych niestandardowych obiektów ABAP z dokładnością do linii kodu. W przypadku niezgodności związanych z uproszczeniami SAP S/4HANA (simplifications) w wyniku widoczna jest referencja do odpowiedniej noty SAP opisującej, w jaki sposób dany element jest niezgodny z SAP S/4HANA, z czym dana zmiana jest związana. Często również w nocie można znaleźć informację, w jaki sposób SAP podszedł w danym przypadku do dostosowania kodu standardowego, a tym samym jakie opcje ma programista, aby dostosować swój kod. Wiele not zawiera również bezpośrednie sugestie rozwiązania problemów niezgodności aktualnego kodu ABAP z docelowym systemem SAP S/4HANA.
Wynikiem działania ATC jest lista koniecznych dostosowań. SAP przyporządkowuje obiekty do priorytetów 1, 2, 3, które oznaczają:
- Prio 1 – krótki zrzut, błąd składni, błąd podczas migracji;
- Prio 2 – problem nie dający się ściśle powiązać z kategorią błędu;
- Prio 3 – problemy z wydajnością.
Przykładowa lista koniecznych dostosowań kodu ABAP wygenerowana w wyniku sprawdzenia ATC
ATC może być uruchomiony ze standardowym interfejsem SAP GUI – wtedy wymagania systemu, na którym jest uruchamiany (central check system),czyli SAP_Basis 7.52.
Wraz z platformą ABAP 1809 (SAP S/4HANA >=1809) dostępna jest również aplikacja SAP Fiori Custom Code Migration. Można ją również uruchomić w środowisku SAP BTP ABAP (w chmurze).
ATC z SAP GUI oferuje te same opcje co aplikacja SAP Fiori Custom Code Migration. Różnica polega na tym, że aplikacja pozwala na filtrowanie wyników według dostępności Quick Fixes, zdefiniowanie zakresu sprawdzenia kodu według użycia i usunięcia nieużywanego kodu podczas migracji.
Quick Fixes
Często wynikiem działania ATC jest lista elementów niezgodnych z SAP HANA i SAP S/4HANA mająca kilka tysięcy pozycji. Przejrzenie i dostosowanie każdej wskazanej linii kodu wymaga znacznej pracochłonności. Większość ustaleń ATC to znane problemy związane ze standardem SAP S/4HANA, które można szybko naprawić w zautomatyzowany sposób. Dlatego też, aby zminimalizować wysiłek związany z adaptacją kodu, SAP oferuje automatyczną adaptację kodu za pomocą funkcji Quick Fixes jako jedno z narzędzi ABAP Development Tools w Eclipse (ADT).
Quick Fixes zawiera poprawki dla najważniejszych przypadków wykorzystania SAP S/4HANA simplifications (uproszczeń), takich jak zwiększenie liczby znaków dostępnych dla pola MATNR, dostęp do tabel bazy danych VBFA, VBUK, VBUP, KONV, BSEG, wykorzystanie elementu danych VBTYP w kodzie źródłowym. Quick Fixes nie jest narzędziem idealnym, ale często podpowiada programiście sposób, w jaki można dostosować dany fragment kodu.
Stare rozwiązania w nowym systemie
Decyzja o migracji do S/4 nie musi oznaczać rezygnacji z rozwiązań niestandardowych, które firma przez lata wypracowała w celu optymalizacji swoich procesów biznesowych i realizacji specyficznych potrzeb. Przeciwnie. Konwersję warto wykorzystać jako dobry moment na przejrzenie i uporządkowanie niestandardowego kodu ABAP.
