Custom software a systemy SAP

Dlaczego rozwiązania szyte na miarę?

Ponad 400 tys. firm na całym świecie wykorzystuje systemy SAP jako podstawowe narzędzie prowadzenia biznesu. Jednym z fundamentów tego sukcesu jest doskonała integracja systemu ERP ze środowiskiem programistycznym. Pozwala to klientom na tworzenie specyficznych funkcji wynikających z potrzeb danej organizacji – tzw. custom software.

ABAP – język programowania stworzony przez SAP i dedykowany dla aplikacji biznesowych, posłużył do zbudowania systemu ERP oraz został udostępniony w postaci zintegrowanego środowiska programistycznego (tzw. ABAP development workbench). Kilka trafnych założeń leżących u podstaw filozofii custom developmentu SAP pozwoliło partnerom i klientom na praktycznie nieograniczone możliwości dostosowania i rozszerzania systemu. Były to m.in.:

• udostępnienie całego kodu źródłowego systemu i modelu danych do wglądu dla deweloperów,
• zaplanowanie wielu miejsc w programach SAP, w których można rozszerzać standardową logikę działania systemu, dodając własny kod ABAP (tzw. user exit – fragmenty kodu, które nie zostaną nadpisane przez kolejne wersje systemu),
• możliwość dowolnego rozszerzania modelu danych systemu poprzez dodatkowe pola (w standardowych tabelach SAP) lub tworzenie własnych tabel.

Nie zabrakło oczywiście również bardziej typowych narzędzi spotykanych w systemach dla przedsiębiorstw, jak edytory do projektowania formularzy, raportów, procesów workflow.

W ostatnich dziesięcioleciach trwa ciągły rozwój narzędzi i praktyk tworzenia oprogramowania. W 2023 r. nie przekonamy deweloperów do korzystania w codziennej pracy z narzędzi wprowadzonych po raz pierwszy 30 lat temu z wersją SAP R/3. Z drugiej strony klienci SAP (a wśród nich wiele to największe przedsiębiorstwa na świecie) bardzo cenią stabilność i przewidywalność działania platformy IT.

Kolejne generacje systemów (od SAP R/3, poprzez SAP ERP wprowadzony w 2004 r. i S/4 zainicjowany w 2015) mają zapewniony bardzo długi okres wsparcia producenta oraz pozwalają na płynny upgrade do kolejnych generacji, wraz z zachowaniem historii danych oraz funkcjonalności dedykowanej dla danej firmy.

Dlatego podejście do custom developmentu w SAP zmienia się w sposób ewolucyjny. Pozwala klientom na równoległe korzystanie z kilku różnych metod pracy i stopniowe przechodzenie na bardziej nowoczesne rozwiązania. Z punktu widzenia managerów IT czy programistów jest to zaleta, ponieważ dewelopment stworzony np. 10-15 lat wcześniej nie musi być pilnie przepisany na nowo. Jednocześnie stanowi to pewne wyzwanie, żeby dobrze zrozumieć znaczenie i zależności pomiędzy współistniejącymi „starymi” i „nowymi” narzędziami i metodami pracy. W artykule porządkujemy i przedstawiamy główne kierunki tej ewolucji i motywację SAP, jaka leży u jej podstaw.

Wyzwania związane z upgrade’em

Jak pogodzić szerokie możliwości custom developmentu dostępne w systemach SAP z wydawaniem kolejnych wersji aplikacji? Tę sytuację zilustrowano na schemacie poniżej, który przedstawia dotychczasowe podejście do rozbudowy systemu.

Upgrade SAP według classic ABAP programming model

SAP zapewnia szereg narzędzi, które wspierają przeprowadzenie upgrade’u systemu, również w zakresie dostosowania custom software. Programy i inne obiekty systemowe, tworzone lub modyfikowane przez klientów, są automatycznie wersjonowane. Ewentualne konflikty (pomiędzy różnymi wersjami obiektów), które wystąpiły w trakcie instalowania nowego wydania systemu, są klarownie prezentowane. Pozwala to zarządzać procesem upgrade’u w sposób uporządkowany i przewidywalny. Jednak ze względu na dużą liczbę obiektów do analizy przy każdym upgradzie projekty instalacji nowej wersji systemu SAP były dotąd poważnymi przedsięwzięciami, trwającymi wiele miesięcy. Klienci musieli za każdym razem rozważyć, czy warto już sięgnąć po nowe funkcje (dostępne w bieżącym wydaniu systemu) w zamian za nakład pracy związany z projektem.

W epoce powszechnego korzystania z systemów IT w modelu SaaS jesteśmy przyzwyczajeni, że codziennie używane aplikacje (np. Microsoft 365 czy JIRA) aktualizują się przyrostowo i regularnie. Nowe funkcje są wprowadzane do nich co kilka miesięcy, bez konieczności wielodniowych reinstalacji i przestoju systemów. Również SAP stara się zbliżyć do ideału „częstych i prostych aktualizacji systemu”. Aby to osiągnąć, konieczne jest wprowadzenie bardziej uporządkowanego podejścia, które rozdziela custom development od standardowego kodu systemu SAP.

Standardowy model danych i interfejsy zostały podzielone na obiekty „udostępnione do użycia na zewnątrz” i obiekty wewnętrzne. Definicje obiektów udostępnionych pozostaną stabilne w przyszłości i dzięki temu oparty na nich custom development będzie kompatybilny z przyszłymi wersjami systemów SAP. Ten podział jest odzwierciedlony w modelu danych (tzw. wglądy CDS, z których w S/4 korzystamy zamiast bezpośrednich odczytów/zapisów do bazy danych SAP) oraz w interfejsach programistycznych API opublikowanych na stronie SAP Business Accelerator Hub (api.sap.com).

Ustalenie zbioru „udostępnionych” obiektów interfejsów API nie jest oczywiście odkrywcze i wydaje się… zupełnie oczywiste na pierwszy rzut oka. Jednak jest to istotna zmiana z uwagi na dotychczasową możliwość bardziej otwartego dostępu do kodu systemu, ogromną bazę istniejącego custom developmentu SAP (dla niektórych klientów: nawet 30-letnią), który stopniowo trzeba do tego podejścia dostosować, oraz przyzwyczajenia dziesiątek tysięcy deweloperów ABAP.

Swoje nowe podejście SAP określa jako clean core, tzn. możliwość łatwiejszej podmiany „podstawowej platformy” systemu na nową wersję dzięki odseparowaniu sfery dewelopmentu klienta od zakresu odpowiedzialności producenta systemu (zobacz schemat poniżej). W efekcie zdecydowanie zmniejsza to ryzyko konfliktów i niespodzianek podczas przyszłych aktualizacji, pozwala na stopniowe zbliżanie systemu ERP do ideału „transparentnych” upgrade’ów, jaki znamy w modelu SaaS.

Podejście clean SAP core

Ewolucja środowiska programistycznego ABAP

Wraz z ogólną ewolucją podejścia opisaną w poprzedniej sekcji, w ciągu kilku ostatnich lat SAP wprowadził szereg innych innowacji. Pozwalają one w pełni wykorzystać możliwości wszystkich wersji systemu S/4HANA (on-premise, private cloud i public cloud). Biorą również pod uwagę platformę SaaS SuccessFactors, która jest następcą SAP HCM.

• Następcą „classic ABAP” są trzy nowe tryby custom development: in-app extensibility, developer extensibility i side-by-side extensibility; każdy z tych trybów oferuje inny zakres możliwości i korzyści; można je stosować równolegle, w ramach jednej instalacji systemu;
• Model programowania Restful ABAP Programming (w skrócie RAP), zapewniający separację danych i logiki biznesowej (back-end) od logiki prezentacji (front-end) i komunikację z serwerem poprzez REST API/protokół OData;
• Dotychczasowe środowisko programistyczne ABAP Workbench (transakcja SE80 w SAPGui) jest zastąpione przez ABAP Development Tools (ADT), oparte na edytorze Eclipse.

Każda z wymienionych innowacji to szerokie zagadnienie zasługujące na oddzielny artykuł. Tutaj prezentuję je tylko przeglądowo – jako listę spraw, którymi warto się zainteresować, jeśli chcemy być na bieżąco z aktualnymi możliwościami custom development w SAP.

Dobry pogląd na to, na czym polega ewolucyjne podejście SAP do custom developmentu w różnych wersjach i generacjach systemu, prezentuje tabela poniżej.

Ewolucja custom developmentu w SAP

Jakie wnioski można wyciągnąć z tego zestawienia?

• jeśli nasz system to nadal SAP ERP (ECC 6.0), nie mamy wielkiego wyboru, ale warto przynajmniej zapoznać się z ADT jako następcą dotychczasowego ABAP Workbench (SE80);
• w wersji on-premise lub private cloud systemu S/4 mamy najbardziej komfortową sytuację, dostępne są zarówno „stare”, jak i „nowe” opcje; to może dawać złudne poczucie, że… nic nie trzeba zmieniać, bo Classic ABAP development nadal nam dobrze służy; jednak wysiłek włożony w poznanie nowych trybów extensibility zwróci się w krótkim czasie w postaci wyższej produktywności deweloperów i tylko w ten sposób wykorzystamy wszystkie możliwości, jakie daje wersja S/4;
• kiedy wdrażamy S/4 public cloud, nie mamy dylematów: jeśli jeszcze nie zapoznaliśmy się z nowym podejściem do custom developmentu, trzeba się za to pilnie zabrać, tradycyjny ABAP Workbench (SE80) nie jest w ogóle dostępny w tej wersji.

Java, Node.js i inne języki programowania

ABAP pozwala programistom osiągać dobrą wydajność pracy, ale w skali całego świata IT jest rozwiązaniem dość „niszowym”. Zdecydowanie więcej deweloperów korzysta z Javy, JavaScript/Node.js czy Pythona. SAP od długiego czasu wspiera integrację systemów z oprogramowaniem tworzonym w innych językach programowania (np. poprzez biblioteki SAP Java Connector, .NET Connector). W ostatnich latach SAP poświęca tej sferze znacznie więcej uwagi przy okazji rozwoju i promocji SAP BTP (Business Technology Platform).

Z punktu widzenia deweloperów, BTP to odpowiednik kompleksowych rozwiązań cloud takich jak Microsoft Azure, Amazon Web Services czy Google Cloud Platform. Oferuje obecnie już ponad 200 różnych usług, obejmujących typowe zadania związane z tworzeniem aplikacji klasy enterprise:

• środowisko uruchamiania aplikacji (runtime) dla wielu języków programowania,
• przechowywanie i analizowanie różnych rodzajów danych (bazy relacyjne, dokumenty, dane geograficzne, itp.),
• wsparcie aplikacji mobilnych,
• integracja aplikacji,
• zarządzanie dostępem użytkowników,
• pozostałe, takie jak monitorowanie aplikacji, planowanie zadań w tle, itd.

Kilka scenariuszy, w których warto rozważyć custom development dla SAP w innych językach programowania niż ABAP:

• posiadamy aplikacje, których nie chcemy „przepisywać” od początku w ABAP-ie, tylko kontynuować ich rozwój, ale jednocześnie ściśle integrować z systemem SAP,
• organizacja posiada zespół programistów z kompetencjami w innych językach programowania i chce wykorzystać ten potencjał,
• inne języki są popularniejsze i lepiej wspierane w danej dziedzinie (np. dostępność specjalistycznych bibliotek programistycznych) – przykładem może być wykorzystanie języka Python w zastosowaniach AI.

SAP BTP jest podstawą podejścia side-by-side extensibility i filozofii clean core, wspomnianych w poprzedniej sekcji (zobacz schemat poniżej).

SAP Business Technology Platform (BTP) a custom development

Pozwala to jednoznacznie odseparować rozwój dedykowanych aplikacji od instalacji systemu ERP. Jeśli umieścimy nasz custom development na serwerze aplikacyjnym w BTP i będziemy łączyć się z instancją SAP poprzez API, uzyskamy następujące korzyści:

• z punktu widzenia użytkowników – aplikacja jest płynnie zintegrowana z resztą systemu, prezentuje się jako kolejny kafelek w Fiori Launchpad, nie wymaga oddzielnego logowania,
• z perspektywy IT – systemy są odseparowane w warstwie technicznej, co ułatwia monitorowanie, aktualizację wersji, podział odpowiedzialności za czynności administracyjne,
• na BTP możemy rozwijać aplikacje w innych językach programowania, zależnie od preferencji organizacji.

Warto zwrócić uwagę, że możliwy jest scenariusz połączenia pojedynczej aplikacji działającej na BTP z wieloma systemami SAP S/4 czy Success Factors. W ramach jednej grupy firm może być to przydatne, jeśli mamy złożony pejzaż systemów SAP, ale chcemy rozpocząć centralizację niektórych aplikacji. Natomiast dostawcy usług i aplikacji rozszerzających funkcjonalność SAP mogą swoje produkty instalować na BTP i połączyć z systemami SAP wielu klientów (tzw. rozwiązanie multi-tenant).

Od czego zacząć?

Custom development – tworzenie funkcjonalności specyficznych dla danej firmy – ma miejsce praktycznie przy każdym wdrożeniu lub upgradzie systemu SAP. Oczywiście w miarę możliwości powinniśmy wdrażać procesy SAP zdefiniowane w bibliotece SAP Best Practices, ponieważ jest to najszybsze i najbardziej efektywne wykorzystanie standardowego systemu. Jednak co najmniej dostosowanie formularzy wydruków/e-maili, stworzenie kilku dodatkowych walidacji danych czy interfejsów do innych systemów w pejzażu IT – na pewno będziemy mieli z tym do czynienia w kontekście systemów SAP.

SAP wyciąga wnioski z wykonanych przez dziesięciolecia wcześniejszych wdrożeń i upgrade’ów systemów w kilkudziesięciu tysiącach firm. Równolegle bierze też pod uwagę rozwój praktyk tworzenia oprogramowania, które stale ewoluują. Uwzględnia te wnioski w podejściu do custom developmentu dla S/4HANA. Efektem są opisane w tym artykule nowe możliwości i kierunki rozwoju – języka ABAP i platformy SAP BTP.

Liczba tych zmian i nowych możliwości – wprowadzonych w relatywnie krótkim czasie kilku ostatnich lat – na pierwszy rzut oka może być nieco przytłaczająca. Jednocześnie warto zwrócić uwagę, że środowisko programistyczne staje się coraz bardziej otwarte, a SAP bardzo stara się ułatwić rozwój kompetencji deweloperów wybierających tę platformę.

Bezpłatna wersja SAP BTP (free tier), w połączeniu z ogólnie dostępnymi tutorialami i dokumentacją na stronach developers.sap.com i api.sap.com – to zupełnie nowe możliwości. Niespotykane jeszcze dekadę wcześniej, kiedy programowanie w SAP oznaczało dużą inwestycję i barierę wejścia dla nowych deweloperów.

Jeśli jeszcze nie zaczęliśmy poznawać tych nowych obszarów, warto zainteresować się nimi jak najszybciej, żeby nie zostać w tyle. Z punktu widzenia pojedynczego dewelopera – regularne aktualizowanie swoich kompetencji jest warunkiem utrzymania konkurencyjności na rynku pracy. Z punktu widzenia firmy/klienta SAP – tylko w ten sposób wykorzystamy pełnię możliwości, jakie oferuje aktualna wersja S/4HANA, która w ciągu najbliższych kilku lat już definitywnie zastąpi poprzednią generację systemów SAP ERP (ECC 6).