19.05.2020

Migracja SAP XI/PI do SAP PI/PO

Migracja interfejsów z SAP XI/PI do SAP PI/PO niewątpliwie niesie za sobą dużo wymiernych korzyści biznesowych. Pamiętać jednak należy, że duże oczekiwania względem projektu migracji mogą przyćmić potencjalne ryzyka związane z podniesieniem platformy do wyższej wersji. Ryzyko wystąpienia komplikacji i niepowodzenia maleje, kiedy cały proces migracji zostanie uprzednio dokładnie zaplanowany, a potem przeprowadzony we właściwy sposób. Każdy etap powinien być poprzedzony dokładną analizą po to, aby móc odpowiedzieć na pytania dotyczące poprawności działania migrowanych interfejsów. Odpowiedź na to, jakie to pytania znajduje się w tym artykule.

Na powyższym diagramie ukazano jak na przestrzeni czasu zmieniała się architektura platformy.

W 2002 r. wydano pierwszą wersję aplikacji – SAP eXchange Infrastracture (XI), która oparta jest na środowisku ABAP i Javy.

Następną wprowadzoną wersją był SAP Process Integration (PI), przy czym pamiętać należy że opcja single-stack wprowadzona została w 2010 r.

Najnowsza wersja SAP Process Orchestration (PO) została wydana w 2011 r. i swoje działanie opiera tylko na środowisku Java.

W celu lepszego zobrazowania czym różnią się poszczególne wersje, poniżej przedstawiono ich główne części składowe.

Architektura SAP eXchange Infrastructure (XI)

Serwer integracyjny jest kluczowym komponentem SAP XI, na który składają się trzy silniki: silnik adaptera (Adapter Engine), silnik integracyjny (Integration Engine) oraz silnik procesów biznesowych (Business Process Engine) – zostały one zainstalowany w środowisku ABAP i Javy.

Adapter Engine (AE) – jak sama nazwa wskazuje, główną rolą tego komponentu jest zapewnienie możliwości połączenia różnych protokołów komunikacyjnych i adapterów.

Integration Engine (IE)  – głównym zadaniem tego komponentu jest zapewnienie środowiska uruchamiania dla komunikatów; odpowiada za routing i mapowania

Business Process Engine (BPE) – komponent ten odpowiada za przetwarzanie komunikatów przepływających przez procesy ccBPM (Cross Component Business Process Management); wymaga instalacji środowiska ABAP i Javy

Architektura SAP Process Integration (PI)

Advance Adapter Engine (AAE) – konfigurując scenariusze przy użyciu ICO (Integrated Configuration), możliwe jest zdefiniowanie lokalnego przetwarzania komunikatów po stronie zaawansowanego silnika adaptera (Advanced Adapter Engine). Dzięki AAE możliwe jest lokalne uruchamianie routingu i mapowań, a procesowanie komunikatów odbywa się tylko przy użyciu AAE poprzez przekazanie wiadomości z jednego adaptera do drugiego bez konieczności uruchamiania silnika integracyjnego (Integration Engine). Podczas takiej konfiguracji, kiedy możliwe jest niezależne działanie ICO, wyeliminowane zostaje środowisko ABAP, co przyczynia się do znacznej poprawy wydajności. W tym miejscu warto jednak wspomnieć o tym, że starsze wersje AAE nie zawierają takich typów adapterów jak iDoc i HTTP, a kwestie związane z czynnościami administracyjnymi lub programistycznymi w dalszym ciągu wymagają komponentu Integration Engine. Biorąc pod uwagę powyższe, na tym etapie nie ma jeszcze możliwości całkowitego odłączenia silnika integracji.

Architektura SAP Process Integration (PI) zawierająca AEX

Advanced Adapter Engine Extended (AEX) – w wersji 7.3, SAP Process Integration wyklucza potrzebę używania silnika integracyjnego IE, w tej wersji wdrożono Advanced Adapter Engine Extended (AEX), który jest pojedynczym silnikiem zawierającym Enterprise Service Bus (ESB), Integration Directory (ID) i możliwości AAE. Od tej pory platforma Process Integration jest platformą, której działanie możliwe jest w oparciu o jedyne środowisko Java. Należy zaznaczyć, że od tej wersji istnieje możliwość konfigurowania scenariuszy przy użyciu adapterów iDoc AAE i HTTP AAE. Wdrożenie AEX uważane jest za bardzo istotną zmianę jeśli chodzi o wersje architektury SAP PI, ponieważ to właśnie od tego momentu następuje całkowite rozłączenie części ABAP i Javy.

Architektura SAP Process Orchestration (PO)

NetWeaver Business Process Management (NW BPM) – istnieje kilka różnic między NW BPM a ccBPM.

SAP Netweaver Business Process Management to komponent uruchamiany na środowisku Java, do opisu procesów używana jest notacja BPMN – Business Process Model Notation. ccBPM działa na dual-stack i używa jęzka BPEL – Busines Process Execution Language.

Najważniejsze różnice pomiędzy ccBPM i NW BPM ukazano w tabeli poniżej.

ObszarccBPMNW BPM
InstalacjaDual stackSingle stack (as java only)
Czas instalacjiKilka dniKilka godzin
WydajnośćGorszaLepsza
Obiekt dew.Wymagany interfejs abstrakcyjny na wejściu do BPMMożliwość użycia standardowego obiektu Service Interface
AdapteryProtokół XI służy do komunikacji między IE a ccBPMAdapter SOAP z protokołem XI służy do komunikacji między IE (AEX) a NW BPM
Środowisko dew.Enterprise Service Builder (ESR)NetWeaver developer studio (NWDS)
Środowisko dew.Nie obsługuje debugowaniaZapewnia obsługę debugowania procesu
RepozytoriumEnterprise Service Builder (ESR)Dzięki NWDI proces może być przechowywany w DTR. Bez NWDI należy użyć osobnej lokalizacji na serwerze
Kompilacja BPM  Kompilacja ccBPM nie jest wymaganaKonieczna jest osobna kompilacja procesu NW BPM
TransportPlikowy lub CTSNWDI z CTS+, CMS lub manualnie
WdrożenieProces ccBPM jest dostępny po aktywacji procesuProces musi zostać dodatkowo wdrożony po aktywacji
Środowisko uruchomienioweWeb AS ABAPWeb AS Java
Proces a usługa sieciowaccBPM nie jest dostępny jako usługa sieciowaProces NW BPM może być usługą sieciową, każdy klient zdolny do wywołania usługi może wywołać proces bezpośrednio
Proces APIBrak APIAPI umożliwiające zdalną obsługę procesów
Start procesuProces może być uruchomiony tylko za pomocą wiadomościProces można uruchomić manualnie w repozytorium procesów lub za pomocą komunikatu
Narzędzia monitorowaniaSXMB_MONI_BPE, PIMONProcess Manager, Task Manager
QoSBE, EO and EOIOBE, EO
PotwierdzeniaccBPM obsługuje potwierdzeniaNW BPM nie obsługuje potwierdzeń
ZałącznikiccBPM obsługuje załączniki wiadomości  NW BPM nie obsługuje załączników wiadomości

Business Rule Management (BRM) – zawiera funkcje modelowania, z których mogą korzystać analitycy biznesowi.

Migracja SAP PI/PO – ryzyko czy szansa?

Obecnie, różnorodność środowiska informatycznego to codzienność wielu przedsiębiorstw. Warunkiem ich niezakłóconego działania i wymiany danych pomiędzy nimi jest wdrożenie rozwiązania integracyjnego, które pozwala na swobodny przepływ danych i obieg dokumentów między systemami.

Niewątpliwym jest, że platforma SAP Process Integration jest najczęściej spotykaną szyną integracyjną w projektach integracyjnych SAP i odgrywa kluczową rolę w wymianie danych między systemami. 

Jak każdy produkt, platforma ta ma swój określony cykl życia, który rozpoczął się kiedy została ona wydana, a zakończy się w momencie zaprzestania wsparcia technicznego, czyli już pod koniec 2020 roku.  Znajomość tej daty powinna skłonić wszystkich użytkowników SAP PI do podjęcia przemyślanych działań w zakresie migracji istniejących interfejsów.

Podejmując się projektu mającego na celu przeniesienie interfejsów z PI dual-stack do PI single-stack lub PO należy mieć świadomość, że działania wchodzące w zakres takiego projektu nie sprowadzają się tylko do skopiowania i przeniesienia istniejących obiektów z jednego środowiska do drugiego.

Mając na uwadze ukazane wcześniej różnice w architekturze różnych wersji SAP PI and PO, każde przedsięwzięcie migracji będzie się od siebie różniło w zależności od istniejących rozwiązań wchodzących w skład różnych scenariuszy konfiguracyjnych. Z uwagi na powyższe, wachlarz możliwych zmian ma bardzo obszerny zakres, począwszy od tych relatywnie prostych i łatwych do przeprowadzenia, po te bardziej skomplikowane, które przeprowadzone w niewłaściwy sposób mogą zaburzyć porządek działania systemów i aplikacji. Dlatego też, bardzo ważne jest, aby każda migracja została przeprowadzona w sposób, który pozwoli przedsiębiorstwom zachować ciągłość pracy i zapewni realizację dotychczas działających procesów biznesowych.

Poniżej przedstawiono główne aspekty ryzyka, w kontekście których istnieje możliwość odniesienia porażki. Pamiętać przy tym należy, że termin porażka nie oznacza tutaj poniesienie całkowitej i nieodwracalnej klęski w zakresie działania interfejsów i wszystkich scenariuszy, a raczej skutki realizowania założeń w sposób niewłaściwy i nieuwzględniający konieczności konfiguracji, która powinna być zgodna z odpowiadającą architekturą.

Połączenia

Kanały komunikacji – wymagane jest, aby wszystkie dotychczas używane adptery ABAP zostały zastąpione adapterami  AAE, które zapewniają możliwość przesyłania dotychczas używanych komunikatów:

Mapowania

W przypadku istniejących mapowań ABAP, konieczne będzie przekształcenie ich do poprawnej wersji mapowań Java, XSLT lub mapowań graficznych. Co ważne, nie ma jednego właściwego sposobu dla tego typu przekształceń. Każde mapowanie wymaga odpowiedniej analizy i należytej uwagi, po to aby zaimplementowana wcześniej logika pozostała nienaruszona.

Konfiguracja / Routing

Dotychczasowa integracja przy użyciu obiektów Receiver Determination musi zostać zastąpiona konfiguracją przy pomocy Integrated Configuration (ICO). Co za tym idzie, zastąpić należy wszystkie obiekty wskazujące na system wysyłający i odbierający, pamiętając przy tym o właściwym użyciu nowo skonfigurowanych kanałów komunikacji – odpowiadającym nowej architekturze.

BPM

Nieodłączną częścią migracji jest również przeniesienie wszystkich istniejących procesów ccBPM do NW BPM. W tym celu konieczne jest zainstalowanie NWDS – NetWeaver Developer Studio i połączenie go z repozytorium ESR. Podstawowe różnice między ccBPM a BPM zostały omówione wyżej.

Monitorowanie

Decydując się na korzystanie z PI/PO odpowiadającemu architekturze single-stack, monitorowanie działania skonfigurowanych scenariuszy odbywa się w inny sposób – z pominięciem transakcji działających tylko w przypadku dual-stack (brak transakcji SXMB_MONI).

System backend

Konieczne jest utworzenie nowego portu iDoc w celu umożliwiania połączenia się z adapterem iDoc_AAE przy użyciu RFC (Destination type T). W przypadku scenariuszy proxy nie ma potrzeby wskazywania silnika integracji. Zamiast tego musimy wskazać miejsce docelowe RFC Adapter Engine.

Dlaczego warto?

Mimo, że migracja PI dual-stack do PI single-stack/PO jest na pewno bardzo wymagającym przedsięwzięciem, nie można nie wspomnieć o kluczowych przyczynach migracji. Poniżej przedstawiono kilka aspektów i powodów, dla których warto dokonać aktualizacji.

Wsparcie z HANA

Możliwe jest uruchamianie PO na HANIE (PI dual-stack tego nie zapewnia, a wersja 7.5 PI wymaga rozdzielenia środowiska ABAP i Java)

Możliwość korzystania z NetWeaver Developer Studio i iFlows

iFlows używane w systemie PO wykorzystują artefakty, które można również wykorzystać w produkcie HANA Cloud Integration

Dostępność NW BPM

Ułatwia przepływ danych przy użyciu SAP Fiori – zapewnia to możliwość korzystania z różnych urządzeń

B2B Add-on

Nie jest wymagane dodatkowe oprogramowanie do obsługi konwersji formatu EDI.

B2B Add-on obsługuje wiele formatów EDI i ich wersji. Dzięki temu możliwe jest uniknięcie kosztów związanych z licencjami oraz z korzystaniem z działania firm świadczących usługi w zakresie obsługi wybranego oprogramowania EDI.

Należy zaznaczyć, że B2B Add-on zawarty jest w licencji dla PO. Konieczne jest jej zakupienie w przypadku chęci korzystania z tego dodatku we wcześniejszych wersjach PI.

Elastyczność i optymalizacja wydajności

Przejście na architekturę opartą wyłącznie na single-stack oznacza ogromny wzrost wydajności podczas realizowania różnych scenariuszy

Scenatralizowane narzędzia monitorowania działania interfejsów

Nie ma potrzeby korzystania z transakcji dostępnych w środowisku ABAP, np. SXI_MONITOR, SM58, SMQ2

Brak wsparcia SAP dla PI dual-stack  

Biorąc po uwagę powyższe, nie da się zanegować faktu, iż obecnie niezawodność działania przepływu danych pomiędzy poszczególnymi aplikacjami odgrywa bardzo dużą rolę w funkcjonowaniu wielu przedsiębiorstw. Decyzja o wdrożeniu SAP PO to z pewnością właściwy krok do uzyskania lepszych wyników w obszarze wydajności, bezpieczeństwa oraz niezawodności działania przepływów danych.

Właściwe przeprowadzenie migracji z SAP XI/PI do nowszej wersji SAP PI/PO w sposób znaczący wpływa na poprawę funkcjonowania przedsiębiorstw. Mimo, że jest ona często skomplikowanym i odpowiedzialnym zadaniem, przeprowadzona przez odpowiedni zespół, daje gwarancję efektywnego wdrożenia, który w żaden sposób nie przyczyni się do zaburzenia dotychczas działających procesów, a przyniesie wymierne korzyści.

Share
Contact Person

Blog writer

Wiktoria Kałka

Integration Consultant