Metody oraz najlepsze praktyki integracji SAP z systemami zewnętrznymi

Na co dzień zdarza się, że potrzebujemy łączyć rozwiązania SAPowe z odrębnymi systemami informatycznymi. W większości przypadków polega to albo na eksportowaniu, albo importowaniu jakiś danych. W obydwóch przypadkach potrzebujemy pewnych mechanizmów i technologii, które umożliwią nam takie działanie. Wynika to także z faktu, że takie systemy są z założenia hermetyczne i nie zapewniają bezpośredniego dostępu do sieci internetowej, aby w ten sposób dodatkowo chronić dane klientów oraz firmy. W poniższym artykule postaram się Wam przybliżyć najbardziej popularne rozwiązania, służące właśnie do integrowania się z zewnętrznymi systemami z poziomu SAPa.

Do najpopularniejszych rozwiązań należy na pewno zaliczyć:

• Mechanizm wysyłania plików przez moduł RFC
• Mechanizm BAPI
• Mechanizm modułów PI/PO
• Mechanizm REST API
• Mechanizm SOAP Webservice

Każde z nich zostanie w krótkiej formie opisane w dalszej części postu, aby ogólnie przybliżyć Tobie, drogi czytelniku, jakie warianty są możliwe do zastosowania podczas prac integracyjnych.

Na samym początku musimy, także pamiętać na jakiej wersji SAP będziemy dokonywali takiego połączenia. Czy będzie to SAP Business One, SAP B1 on HANA, SAP ECC, ECC on HANA, S/4 HANA itd.

Każde z rozwiązań przewiduje swoje podejście do poruszanego tematu. Niektóre mogą być wykorzystywane zamiennie na różnych wersjach jak np. moduły RFC albo oDATA na systemie S/4 HANA, jednak należy pamiętać aby dane rozwiązania dobierać zgodnie z zastosowaniem.

1. Mechanizm wysyłania plików przez moduły RFC

Jest to pierwsza i jedna z prostszych oraz bardzo podstawowych metod przesyłania danych na zewnętrzne dyski, skąd integrowane systemy pobierają dane w postaci plików w formatach np. CSV, XML, itd. Do tego celu są nam potrzebne takie mechanizmy jak np. moduł RFC uruchamiający polecenie systemowe zapisane w transakcji SM69.

• Jak RFC wygląda w SAP?

Przykładowy moduł RFC:

Przykładowe użycie modułu RFC:

Grafika prezentująca, które polecenie z transakcji SM69 zostało wywołane przez moduł RFC:

Polecenie musi być zrozumiałe przez system operacyjny, na jakim jest zainstalowana instancja SAP. Dodatkowo potrzebujemy adres IP serwera na który będziemy wysyłali pliki oraz, jeżeli jest to wymagane, nazwę użytkownika oraz hasło lub czasami jeszcze klucz identyfikacyjny dla uwierzytelnienia swojego dostępu do danego dysku sieciowego.

Dzięki takiemu mechanizmowi możemy bez większych problemów wysyłać pliki na zewnętrzne nośniki danych. W przypadku systemu operacyjnego Linux, możemy tego dokonać np. za pomocą takich poleceń systemowych jak:

• FTP
• SFTP
• CURL

Ogólne zasady działania modułów RFC

Co to jest RFC?

RFC (ang. Remote Function Call) to protokół SAP do obsługi komunikacji między systemami w celu uproszczenia powiązanego programowania. Jest to proces wywoływania modułu funkcyjnego, który znajduje się na innej maszynie niż program wywołujący. RFC mogą być używane do wywoływania innego programu na tej samej maszynie, ale zwykle jest używane, gdy „ wywołujące ” i „ wywoływane” moduły/programy funkcyjne, działają na osobnych maszynach.

Graficzna prezentacja przepływu danych:

W systemach SAP, interfejsy RFC służą do zestawiania połączeń RFC między różnymi systemami SAP, a także między systemem SAP a systemem zewnętrznym (innym niż SAP).

RFC składa się z dwóch interfejsów:

• Interfejs wywołujący dla programów ABAP
• Interfejs wywołujący dla programów innych niż SAP.

Każdy program napisany w języku ABAP może korzystać z modułów RFC, po przez używanie komendy CALL FUNCTION…DESTINATION.

• Istotne wiadomości na temat modułów RFC:
  • SAP używa protokołu CPIC (Common Programming Interface for Communication) do przesyłania danych między systemami. Jest to protokół specyficzny dla SAP. Zdalne wywołanie funkcji (RFC) to interfejs komunikacyjny oparty na CPI-C, ale z większą liczbą funkcji i łatwiejszy w użyciu dla programistów aplikacji.
  • Funkcje biblioteki RFC obsługują język programowania C i Visual Basic (na platformach Windows).
  • Połączenia RFC mogą być zawsze używane w całym systemie, co oznacza, że połączenie RFC zdefiniowane w kliencie 000 może być również używane z klienta 100 (bez żadnej różnicy).
  • Jedyną różnicą między zdalnym wywołaniem modułu funkcji na inny serwer a wywołaniem lokalnym jest specjalny parametr (miejsce docelowe), który określa serwer docelowy, na którym ma być wykonywany program.
• Zalety modułów RFC:
  • Są w stanie przekonwertować dane na format zrozumiały dla systemu zdalnego (docelowego).
  • Potrafią wywoływać określone procedury, które są niezbędne do rozpoczęcia komunikacji ze zdalnym systemem.
  • Obsługują błędy, które mogą wystąpić w procesie komunikacji.
  • Pomagają, także w zmniejszeniu wysiłku na opracowywanie modułów oraz metod w zdalnych systemach.

Wyróżniamy parę rodzajów modułów RFC:

Powyższe moduły zostaną opisane w kolejnej części, poświęconej modułom RFC. ^_^

2. Mechanizm BAPI

BAPI – Interfejs Programistyczny Aplikacji Biznesowych (ang. Business Application Programming Interface). Podstawową koncepcją interfejsów BAPI jest orientacja obiektowa. Interfejsy BAPI umożliwiają dostęp do obiektów biznesowych w systemie SAP przez systemy zewnętrzne. Obiekty biznesowe reprezentują rzeczywiste obiekty, takie jak zamówienia, klienci lub artykuły. Dostęp do instancji jest możliwy wyłącznie przy użyciu metod udostępnianych przez obiekt biznesowy. Technicznie metoda jest wywoływana na podstawie interfejsów RFC. Instancja, do której nawiązywane są połączenia, jest określana przez pola kluczowe (numer klienta itd.).

Graficzna prezentacja przepływu danych:

3. Mechanizmy modułów PI/PO

Na samym początku należy przypomnieć sobie czym są te dwa produkty, dostarczane przez firmę SAP:

• SAP Process Integration – jest to „pośrednik” integracji, który tradycyjnie korzysta z obu stosów ABAP i Java, aby umożliwić integrację opartą na wiadomościach między systemami informatycznymi przy użyciu wielu adapterów do pobierania komunikatów do, i z tych systemów. Jest także możliwe wdrożenie PI w taki sposób, aby po prostu działało na stosie Java, ale jeśli to robisz, możesz równie dobrze aktywować dodatkowe komponenty PO.
• SAP Process Orchestration – jest to połączenie SAP Process Integration (jak wyżej), SAP Business Process Management (używane do tworzenia przepływów pracy między ludźmi i systemami), SAP Business Rules Management (używane do włączania definiowanej przez użytkownika logiki biznesowej wymaganej w dowolnym procesie biznesowym,
  wyłączania/włączania limitów). Zawiera również wiele pomocnych komponentów technicznych, takich jak Composite Application Framework (do tworzenia trwałości danych), Enterprise Content Management (używany do zarządzania dokumentami) i lekką wersję funkcji SAP Portal (używanej do dostępu do treści w oparciu o role). Wszystkie z wymienionych elementów działają na stosie SAP Java.

Mówiąc najprościej, SAP Process Orchestration obejmuje wszystkie narzędzia potrzebne do tworzenia logiki biznesowej, aplikacji i integracji wymaganych do wypełnienia wszelkich luk między systemami IT <-> lokalną platformę rozszerzeń. Daje on też pełną możliwość do integracji z bazą HANA oraz z rozwiązaniami chmurowymi oferowanymi już od paru lat przez firmę SAP.

Należy także pamiętać o tym, że moduł PI nie jest już wspierany w formie nowych rozszerzeń, jego rolę przejął moduł PO i to on jest polecany przez firmę SAP.

Przykładowa grafika, prezentująca sposób działania modułu PO w procesie integracji z zewnętrznym systemem, który ma inną formę komunikacji niż dane rozwiązanie w systemie SAP.

4. Mechanizmy REST API

REST API (ang. Representational state transfer), transfer stanu reprezentującego, to zbiór zasad tworzenia architektury oprogramowania dla systemów rozproszonych. Opisywany standard definiuje sześć podstawowych reguł:

1. Architektura Klient-Server
2. Bezstanowość
3. Zdolność zapamiętywania/buforowania zasobów
4. System warstwowy
5. Kod na żądanie
6. Jednolity interfejs

W rozwiązaniach systemu SAP mamy do czynienia z takim terminem jak OData. Czym właściwie jest wspomniana fraza? W ogólnym rozumieniu, OData służy do definiowania najlepszych rozwiązań, które są wymagane do tworzenia i używania interfejsów API RESTful. Pomaga w wyszukiwaniu zmian, definiowaniu funkcji dla procedur wielokrotnego użytku i wysyłaniu paczek żądań itp.

OData to protokół do przesyłania zaprojektowany przez Microsoft już w roku 2007 i od tego czasu stale rozwijany. Najnowsza wersja oData 4.0 została wydana w roku 2014.

Cykl życia usługi OData:

Od kilku lat SAP Gateway ma funkcjonalność dostarczania funkcji ABAP i interfejsów RFC w postaci REST API. REST ma pewne zalety w stosunku do SOAP, ale ma podobną technologię, ponieważ jest również wywołaniem funkcji za pośrednictwem protokołu HTTP. W porównaniu z SOAP, REST jest łatwy do wywołania z różnych platform, przesyła czyste dane czytelne dla człowieka w formacie JSON lub XML, jest szybszy i oszczędza zasoby. W podstawowej idei REST dostęp do obiektu uzyskuje się za pośrednictwem REST, a nie jego metod. Stan obiektu można zmienić za pomocą dostępu REST. Zmiana jest spowodowana przekazanymi parametrami. Częstym zastosowaniem jest połączenie SAP PI przez interfejs REST.

Cztery podstawowe metody HTTP wykorzystywane w rozwiązaniach REST API:

GET – służy do pobierania danych. Tutaj wystarczy podać odpowiedni endpoint, ewentualnie zmodyfikować nagłówki(headers) zapytania.

POST – służy tworzeniu i przesłaniu nowych danych. W tym przypadku konieczne jest już stworzenie ciała(body), w którym przekażemy dane do naszego REST API.

PUT – również służy przesyłaniu danych, lecz najczęściej w celu aktualizacji tych danych. Tutaj również wymagane jest przesłanie danych w ciele.

DELETE – metoda służąca do usuwania danych. W tym momencie chcę wspomnieć o technice tak zwanego soft-delete. Mówiąc skrótem polega to na tym, że kasując dane za pomocą API tak naprawdę tylko dodajemy do encji informację o tym, że została ona usunięta. W rezultacie dane pozostają nadal w bazie, lecz nie są one dostępne z poziomu API. Mechanizm ten należy już zaimplementować w samym API i nie ma on nic wspólnego z HTTP.

Graficzna prezentacja przepływu danych:

Przykładowe zapytanie GET dla REST API:

Przykładowa odpowiedź dla powyższego zapytania:

5. Mechanizmy SOAP Webservice

SOAP (ang. Simple Object Access Protocol), jest to protokół komunikacyjny, który korzysta z formatu XML do kodowania żądań oraz zazwyczaj protokół HTTP do ich transportowania w sieci.

Struktura SOAP składa się z podstawowego znacznika <envelope>, który zawiera obowiązkowy znacznik <body> oraz opcjonalny znacznik <header>. Wszystkie główne dane wiadomości są zawarte w części <body>, natomiast część nagłówka może opcjonalnie zawierać informacje, potrzebne w specyficznych przypadkach.

Aby korzystać w SAP z protokołu SOAP, należy posiadać plik WSDL (ang. Web Services Description Language), oparty o język XML. Służy do opisu punktów dostępu do usług sieciowych z jakich chcemy skorzystać wykorzystujące dane połączenia z zewnętrznymi systemami. Taki plik musimy zaczytać do SAP, aby na jego podstawie została zbudowana struktura zapytania SOAP.

Graficzna prezentacja budowy SOAP:

 Przykładowy dokument WSDL:

Przykładowa odpowiedź SOAP:

Graficzna prezentacja przepływu danych: