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.
| Obszar | ccBPM | NW BPM |
| Instalacja | Dual stack | Single stack (as java only) |
| Czas instalacji | Kilka dni | Kilka godzin |
| Wydajność | Gorsza | Lepsza |
| Obiekt dew. | Wymagany interfejs abstrakcyjny na wejściu do BPM | Możliwość użycia standardowego obiektu Service Interface |
| Adaptery | Protokół XI służy do komunikacji między IE a ccBPM | Adapter 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 debugowania | Zapewnia obsługę debugowania procesu |
| Repozytorium | Enterprise 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 wymagana | Konieczna jest osobna kompilacja procesu NW BPM |
| Transport | Plikowy lub CTS | NWDI z CTS+, CMS lub manualnie |
| Wdrożenie | Proces ccBPM jest dostępny po aktywacji procesu | Proces musi zostać dodatkowo wdrożony po aktywacji |
| Środowisko uruchomieniowe | Web AS ABAP | Web AS Java |
| Proces a usługa sieciowa | ccBPM nie jest dostępny jako usługa sieciowa | Proces 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 API | Brak API | API umożliwiające zdalną obsługę procesów |
| Start procesu | Proces może być uruchomiony tylko za pomocą wiadomości | Proces można uruchomić manualnie w repozytorium procesów lub za pomocą komunikatu |
| Narzędzia monitorowania | SXMB_MONI_BPE, PIMON | Process Manager, Task Manager |
| QoS | BE, EO and EOIO | BE, EO |
| Potwierdzenia | ccBPM obsługuje potwierdzenia | NW BPM nie obsługuje potwierdzeń |
| Załączniki | ccBPM 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:
- HTTP -> HTTP_AAE
- IDoc -> IDocAAE
- XI -> SOAP (XI 3.0)
- WS -> WS_AAE
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.
