Budowanie mikroserwisów w SAP Cloud Foundry

Dynamicznie zmieniający się rynek, a także maksymalizacja redukcji kosztów, wymusiło przed laty na twórcach oprogramowania stworzenie mikroserwisów, czyli usług będących częścią składową jakiegoś większego systemu. Takie podejście ułatwia budowanie złożonych aplikacji oraz ich późniejsze utrzymywanie.

Świat SAP przez lata wydawał się bardzo hermetyczny i jakby zamknięty na innowacje zachodzące w IT. Zmiana modelu biznesowego wielu klientów oraz nowe potrzeby w stosunku do oprogramowania spowodowały, iż SAP zdecydował się na dynamiczny rozwój swoich produktów na wielu frontach. W przypadku mikroserwisów mieliśmy możliwość korzystania z nich, już w środowisku SAP HANA XS Advanced.

Ubiegłoroczna konferencja SAP TechEd wskazała jasny kierunek w którym SAP chciałby podążać w kolejnych latach. Wiele z produktów przenoszonych jest do Clouda. Również środowisko HANA XS Advanced ma tam swój odpowiednik tj. SAP Cloud Foundry. Jest to otwarta platforma, która jest  standardem w przypadku rozwiązań Platforms as a Service (PaaS), do opracowywania i wdrażania aplikacji chmurowych. Jest ona przeznaczona do działania jako usługa na różnych infrastrukturach (IaaS), takich jak Amazon Web Services, OpenStack, Google Cloud Platform i Microsoft Azure. Umożliwia programistom korzystanie z różnych języków programowania, środowisk wykonawczych, usług czy też backendów dla aplikacji. Więcej informacji  o Cloud Foundry znajdziesz w rozdziałach 6.3 i 6.5 https://sii.pl/blog/maly-glosariusz-sap-czesc-ii/.

Zanim zaczniesz

Ideą tego artykułu jest pokazanie w jaki sposób budować mikroserwis w środowisku SAP Cloud Foundry, a następnie udostępnić go poprzez API Management. Mikroserwisem w naszym przypadku będzie prosta aplikacja, która z bazy danych HANA poprzez serwis Node.js wystawi dane pracownika jako interfejs (patrz Rysunek 1).

Architektura takiego rozwiązania, podyktowana jest chęcią pokazania, że złożoną logikę backendu można zatomizować, co często jest problemem programistów, którzy nie mogą równolegle rozwijać swoich aplikacji. W tym celu wykorzystywany jest SCP API Management, aby zapewnić dostęp do APIs z jednego wspólnego miejsca, dla zewnętrznych źródeł. Bez potrzeby uzewnętrzniania logiki biznesowej.

Jak zacząć?

SAP, dla osób chcących odkrywać możliwości ich produktów, oferuje swoje środowisko i usługi w darmowej wersji trial. Wystarczy jedynie zarejestrować się w SAP Cloud Platform trial. W SCP będziemy korzystać z następujących usług SAP:

• Neo Trial
  • API Management
    • API Portal
    • Developer Portal (opcjonalnie)
  • Cloud Foundry
    • WebIDE
      • Rozszerzenia:
        • SAP HANA Database Development Tools
        • SAP HANA Database Explorer

Konfigurowanie środowiska

Z perspektywy SAP Cloud Platform korzystać będziemy z dwóch środowisk: Cloud Foundry oraz Neo. Cloud Foundry posłuży nam do zbudowania aplikacji eksponowanej jako mikrousługa, natomiast Neo pozwoli nam wystawić API do mikroserwisu dla zewnętrznych aplikacji/systemów.

Po uruchomieniu Neo, z menu aplikacji należy wybrać Services. Na wyświetlonej liście należy odszukać API Management i zadbać o to, aby serwis był dostępny (zgodnie z Rysunek 2).

W szczegółach serwisu (patrz Rysunek 3) należy uruchomić API Portal i tam zarejestrować swojego użytkownika w usługach SAP. Pozwoli to nam w późniejszych krokach na założenie API do naszego mikroserwisu.

Przedostatnim krokiem jest konfiguracja SAP Cloud Foundry. Jeśli w zakładce Subaccounts, nie mamy jeszcze podpiętego żadnego systemu to należy go dodać np. w sposób jak na Rysunku 4.

Ponadto należy dodać Space, czyli przestrzeń roboczą dla developmentu. Główną ideą Space jest to, że tworzy ona rodzaj strefy zaufania, co w zasadzie oznacza, że wszystkie aplikacje wdrożone w tej samej przestrzeni mogą mieć wspólne zasoby, takie jak przechowywanie danych, autoryzacje użytkowników i hasła. Przestrzeń jest przeznaczona do współdzielenia przez kilku programistów, ale programiści mogą również mieć swoją prywatną przestrzeń. Aby dodać przestrzeń należy otworzyć szczegóły naszego systemu, który założyliśmy w poprzednim kroku i dodać Space tak jak na Rysunku 5.

Ostatnim krokiem przed rozpoczęciem developmentu jest konfiguracja WebIDE. Link do naszego środowiska developerskiego znajduje się w SAP Cloud Platform Cockpit. W tym kroku należy zgodnie z Rysunkiem 6 otworzyć ustawienia i w zakładce Cloud Foundry zdefiniować nasz Space, API Endpoint i podać Organizacje (jest nim nasz S-User z suffixem trial). Jeśli się zgubiliście, to API Endpoint został wygenerowany w trakcie zakładania systemu w Cloud Foundry i jest widoczny w jego szczegółach.

W celu ułatwienia sobie pracy, należy jeszcze włączyć dwa rozszerzenia w Web IDE, które pozwolą nam na pracę z bazą danych SAP HANA. Z zakładki ustawienia, należy wybrać opcję „Extensions”, a następnie skonfigurować aplikację tak, jak na Rysunku 7.

Budowanie aplikacji

Nareszcie możemy przejść do etapu na który czekaliśmy, czyli development. W tym kroku założymy aplikację, która będzie składała się z Core Data Services (CDS) i serwisu Node.js. CDS umożliwiają modelowanie danych i definicji usług na poziomie koncepcyjnym. Na ich podstawie tworzone są natywne artefakty (np. SQL database schema). Rola CDS nie ogranicza się jedynie do strukturyzowania danych. Przy wykorzystaniu odpowiednich annotacji i składowych języka, możliwe jest definiowanie relacji danych, co może finalnie pomóc w definiowaniu poziomu UI.

Na początku zaczniemy jednak od czegoś prostszego, a mianowicie założymy nową aplikację ?. Do tego posłuży nam środowisko Web IDE. Z górnego menu wybierzmy „Create project from Template”, a następnie wybierzmy „SAP Cloud Platform Business Application”. Opcja ta umożliwia nam budowanie full-stackowych aplikacji, gdyż SAP zapewnia środowisko end-to-end. W kolejnym kroku podajemy nazwę projektu i nawigujemy dalej, aż dojdziemy do momentu, w którym będziemy musieli podać szczegóły projektu, takie jak: język serwisów (u nas Node.js), wersja protokołu oData, czy też informację o tym, czy ma zostać automatycznie podpięta baza danych HANA. Nasza konfiguracja powinna być zgodna z Rysunkiem 8.

Po naciśnięciu „Finish” aplikacja zostanie założona w Workspace. Po rozwinięciu drzewka aplikacji widzimy szereg folderów i gotowego kodu. Ich znaczenie jest następujące:

• <Nazwa projektu>
  • db (moduł bazy danych, przechowuje wszystkie obiekty i artefakty)
    • csv (automatycznie wygenerowany folder przechowywujący przykładowe dane w plikach csv, do wgrania do przykładowych tabel)
    • src (folder przechowujący wygenerowane artefakty w trakcie budowania modułu db)
    • data-model.cds (Przykładowy model CDS. Modele przechwytywane są w notacji Core Schema Notation)
    • json (Plik zawiera skrypt do uruchomienia deploymentu naszych artefaktów bazy danych do kontenera HDI)
  • srv (moduł serwisu Node.js)
    • cat-service.cds (Plik zawiera definicje serwisu)
    • json (Plik, który defacto znaczy to samo co „CDS run”)
  • yaml (development descriptor)
  • json (konfiguracja projektu)

Naszą pracę zaczniemy od modelowania danych. W tym celu otwórzmy plik data-model.cds. W przypadku testowym zbudowałem encje, która będzie przechowywała pracowników z przypisanymi do nich miejscowościami i państwem. Wykorzystałem tutaj typ danych który zdefiniowany jest w sap/cds/common. Jeśli chodzi o namespace, to jest on dowolny (w przypadkach nieprodukcyjnych). Zbudowany CDS wygląda jak w Listing kodu 1.

Warto zauważyć, że w momencie gdy kliknęliśmy „build” na module bazy danych, utworzone zostały automatycznie nowe artefakty. W tym wypadku widoki CDS i tabele odpowiedzialne za przechowywanie danych pracownika i państw (tabelka tekstowa). Całość wygląda tak jak na Rysunku 9.

W tym momencie możemy wypełnić nasze tabelki danymi. Aby przejść do widoku bazy danych, kliknij na module „db” prawym przyciskiem myszy i wybierz „Open HDI Container”. Jeśli w nowo otwartym oknie nie pojawiła Ci się żadna bazy danych, możesz ją łatwo podpiąć klikając znak „+”. Wybierz  domyślną bazę danych, jaka została stworzona, dla założonego przez Ciebie Space. W dodanej bazie nawiguj na zakładkę „Tables”. W oknie poniżej powinny Ci się wyświetlić tabele. W moim przypadku ich nazwy to:

• MY_SIIBLOG_SIIWORKER (prefix pochodzi z namespace modelowanego CDS)
• SAP_COMMON_COUNTRIES (Tabela wartości dla pola Country z powyższego CDS)
• SAP_COMMON_COUNTRIES_TEXTS (Tabela tekstowa dla tabeli z państwami)

W tym momencie mamy dwie możliwości, aby dodać zawartość tabeli:

• Korzystając z konsoli SQL (lewy górny róg), możemy napisać polecenie INSERT
• Użycie edytora graficznego

Zakładam, iż podstawy SQL zna każdy, więc szybko opiszę w jaki sposób korzystać z edytora graficznego. Po wklikaniu się w nazwę tabeli, wyświetli nam się okno zawierające szczegóły techniczne tabeli. W prawym górnym rogu znajduje się przycisk „Open Data”, którego naciśnięcie otwiera bardzo intuicyjne narzędzie, w którym możemy manualnie dodać dane, do wybranej tabeli.

Gdy tabele wypełnione są danymi, możemy się skupić na budowie serwisu, który będzie propagował dane. W tym celu należy zmienić perspektywę na „Development” i z folderu „srv” należy otworzyć plik cat-service.cds.

Serwis, który stworzyłem jest bardzo prosty. W linii pierwszej podaję namespace zasobów, z których będę korzystał. Następnie definiuje serwis, a w nim encję, która będzie „wystawiona na zewnątrz”. Dodatkowo należy powiadomić encję z jakiego źródła danych będzie ona korzystać (<namespace>.<nazwa_cds>). Kod w tym momencie jest gotowy, teraz pozostaje nam zbudować serwis i zweryfikować czy wszystko działa. Klikamy prawym przyciskiem myszy na katalog „srv” i każemy go zbudować. Gdy to jest gotowe, wtedy klikamy prawym przyciskiem na cat-service.cds i dajemy „Run as -> Node.js Application”.

System będzie potrzebował chwili na zbudowanie całego mikroserwisu. Jednak w konsoli na bieżąco możemy monitorować jaki jest progres budowania serwisu (Rysunek 10). Gdy zostanie on zbudowany, wyświetlony zostanie link. Wejdźmy w niego i zweryfikujmy, czy nasz serwis eksponuje dane.

Po otwarciu strony widzimy, że mamy możliwość podejrzenia metadanych oraz dostępnych encji naszego serwisu. U mnie są to:

• Countries
• Workers

Po wejściu w jedną z encji, powinny zostać wyświetlone nam dane z bazy danych. Jeśli do tego momentu wszystko Ci działa to super, bo oznacza to, że zbudowałeś mikroserwis ?. Teraz pozostaje jedynie zarejestrować go w API Management, aby mógł być konsumowany przez zewnętrznych partnerów.

Rejestrowanie API

API Management to proces publikowania, promowania i nadzorowania interfejsów API w bezpieczny i skalowalny sposób. SAP API Management zapewnia bezpieczne zarządzanie interfejsami API w oparciu o otwarte standardy, takie jak SOAP, REST czy też oData. Upraszcza to sposób, w jaki programiści integrują się z aplikacjami SAP (i innymi niż SAP), obniżając koszty i wspierając innowacje.

Aby, uruchomić API Management należy cofnąć się do SAP Cloud Platform Cockpit (Neo). Tam z zakładki „Services” należy wybrać odpowiednią usługę. Następni klikamy „Access API Portal”. Po chwili uruchomiona zostanie nowa aplikacja, w której możemy budować i zarządzać naszymi API.

Naszym pierwszym zadaniem będzie stworzenie API. W menu z lewej strony należy wybrać opcję „Develop”. W nowo otwartym oknie należy wypełnić dane w sposób zgodny z Rysunkiem 12.

Select: URL

URL: link naszego serwisu + /catalog. Link można podejrzeć w konsoli Web IDE po uruchomieniu serwisu

Name: dowolny

Title: dowolny

Host Alias: Podpowiada się automatycznie, jeśli systemy zostały skonfigurowane zgodnie z tutorialem.

API Base Path: /<namespace_cds>/<nazwa_aplikacji> W tym przypadku /siiblog/siitest

Gdy API zostało stworzone, wtedy należy zrobić deployment. W tym celu należy skorzystać z opcji „Deploy” w prawym górnym rogu. Następnie należy kliknąć „edit” przejść do zakładki „Resources” i dodać nawigacje do naszej encji (Patrz Rysunek 13). W moim przypadku dodaje „/Workers”, gdyż tak nazywała się moja encja. Jeśli zdecydowałeś się na inną nazwę, to należy sprawdzić jej nazwę najlepiej w modelowanym CDS.

Ostatnim etapem jest przetestowanie naszego API. Gdy już dodaliśmy „Resource”, możemy skorzystać z opcji „Try out”. Nasze API nie pobiera żadnych parametrów, więc możemy uruchomić test naciskając przycisk „Execute”. Jako rezultat powinniśmy otrzymać kod 200 i dane pracownika, które zapisane zostały w bazie.

Gratulacje! Teraz już wiesz w jaki sposób można budować proste mikroserwisy oraz jak je zgłaszać w API Management. Należy pamiętać, że to jest jedynie początek drogi. Przykłady produkcyjne z reguły mają znacznie bardziej skomplikowany backend, natomiast API Management zawiera szereg dodatkowej konfiguracji, jak chociażby poziom autoryzacji, by dane mogły odczytywać jedynie uprawnione osoby. Tutorial ten daje Ci jednak bazę do rozpoczęcia przygody z Cloud Foundry jak i z mikroserwisami. Powodzenia!

Źródła

1. Designing and Developing Harmonized REST-Based Microservices INT615, Divya Mary / SAP SE
2. Dokumentacja CDS https://cap.cloud.sap/docs/cds/