Pogadajmy o narzędziach komunikacji SOAP i REST dostępnych wprost w PS CLEMENTINE PRO 3.0

Tekst przeczytasz w: 6 minut.

Spis treści [Ukryj]

Wśród wielu funkcjonalności oferowanych użytkownikowi przez PS CLEMENTINE PRO znajdują się m.in. węzły, które  umożliwiające szybką i łatwą komunikację z usługami sieciowymi opartymi o REST i SOAP. Mają one szerokie zastosowanie zarówno przy tworzeniu procesów wewnętrznych, jak i przy integracji z serwisami zewnętrznymi. Co więcej, wyposażone są w graficzny interfejs, co umożliwia korzystanie z nich nawet bez znajomości języków programowania. W tym artykule dowiecie się jak komunikować się z usługami sieciowymi przy pomocy węzłów PS REST i PS SOAP, a także poznacie kilka ich przykładowych zastosowań w środowisku biznesowym. W kolejnych tekstach  opowiemy:

  • O budowaniu procesów scoringowych w dobie API - kiedy, jakiej i ile 'mobilności' jest nam potrzebne
  • Jak sprytnie prowadzić kampanię SMS z wykorzystaniem PS CLEMENTINE PRO 3.0
  • Jak sprytnie budować portal raportowy przy użyciu PS IMAGO PRO i PS CLEMENTINE PRO

Jak sprytnie integrować system scoringowy z wykorzystaniem PS Dispatcher APIDla obydwu technologii zaprojektowane zostały 3 rodzaje węzłów: źródłowy, przejściowy oraz exportu. Dzięki temu możłiwa jest kompletna komunikacja z web service’ami wyposażonymi w API oparte o style SOAP lub REST. Zaczniemy oczywiście od węzłów źródłowych.

mapka

Rysunek 1

 

Pobieranie danych z usług sieciowych - czyli jak wykorzystać węzły źródłowe PS REST i PS SOAP

REST i SOAP należą do najpopularniejszych protokołów, przy użyciu których pobierać można dane z usług sieciowych. Wybór odpowiedniego uzależniony jest oczywiście od tego, w jaki sposób zaprojektowana jest usługa sieciowa. W Internecie znaleźć można wiele płatnych, ale też darmowych serwisów, z których pobrać można dane na rozmaite tematy. Od danych finansowych, giełdowych, urzędowych, przez informacje o pogodzie, tłumaczenia językowe, dane o lotach, hotelach, kończąc na … losowych żartach o Chucku Norrisie.

Wśród dostępnych darmowych źródeł danych można znaleźć np. takie, umożliwiające pobranie aktualnych danych na temat epidemii COVID-19 w różnych krajach na świecie. Dla wielu firm i instytucji w okresie epidemii takie bieżące dane są bardzo ważne i mogą stanowić o podstawie funkcjonowania organizacji. Przykładowy węzeł umożliwiający pobranie historii rozwoju epidemii w Polsce ilustruje rys. 2. Dane są pobierane z serwisu https://covid19-api.org/, udostępniającego darmowe REST API. Jak widać po rys. 2, konfiguracja węzła PS REST może być bardzo łatwa i często wymaga jedynie bardzo podstawowej wiedzy o protokole REST. W przypadku konieczności wypełnienia pozostałych zakładek węzła, niezbędne dane są często zapewniane przez dokumentację usługi sieciowej, z której chcemy skorzystać.

 Rys. 3 pokazuje efekty tego działania - dane pobrane przy pomocy tak skonfigurowanego węzła.

 

Rysunek 2

Rysunek 2

 

Rysunek 2

Rysunek3

 

Nieco bardziej skomplikowana jest konfiguracja węzła, gdy chcemy pobrać dane przy pomocy komunikatu w protokole SOAP. Komunikaty (koperty) SOAP są tworzone przy pomocy języka znaczników XML – potrzebna jest więc nam pewna wiedza na ten temat. Niemniej wiele serwisów, związanych m.in. z administracją publiczną, oparta jest właśnie o ten protokół  , dlatego jest to wiedza warta zgłębienia. Specyfikacja jest dostępna m.in. na stronach W3C.

Przykładowy węzeł źródłowy PS SOAP pobierający dane na temat średniego kursu dolara w marcu 2014 r. z serwisu Banku Litwy pokazany jest na Rys. 4.

 

rysunek 4

Rysunek 4

 

Wykorzystanie dynamicznie tworzonych zapytań w procesach

Omówione powyżej węzły źródłowe umożliwiają pobieranie danych przy użyciu konkretnie ustalonych parametrów takich jak adres serwisu czy treść koperty SOAP. Co jednak w przypadku, gdy chcielibyśmy, aby wartość parametrów była uzależniona od danych, które otrzymamy w procesie?

Możliwość dynamicznego modyfikowania zapytań wysyłanych do serwisów sieciowych umożliwiają nam węzły przejściowe PS REST i PS SOAP. Dzięki nim możemy pobrać np. dane dla dzisiejszej daty albo dla krajów wyselekcjonowanych we wcześniejszym procesie przetwarzania danych. Możemy w ten sposób modyfikować adresy serwisów i wiele innych parametrów węzłów wymagających określenia.

Moglibyśmy więc w ramach procesu utworzyć wartości ustawień, które poprzednio „na sztywno” wpisaliśmy do węzłów źródłowych – i w taki sposób odtworzyć otrzymane wcześniej wyniki. Węzły te mają jednak dodatkowy tryb, w ramach którego umożliwiają wysłanie osobnego żądania dla każdego otrzymanego rekordu. Oznacza to, że w każdym rekordzie możemy dostarczyć do węzła zestaw parametrów, za pomocą których skonfigurujemy wysyłane żądanie SOAP lub REST. Dla każdego z tych żądań otrzymamy wartości zwrotne, które również zostaną zwrócone w poszczególnych rekordach. Jedno żądanie – jedna odpowiedź. Daje to znacznie większą elastyczność w podejściu do tworzonych procedur wymiany danych z web service’ami.

Przykładowo, wracając do serwisu podającego dane nt. COVID-19 opartego o REST, możemy przy użyciu jednego węzła pobrać dane dla Polski, Niemiec i Czech dla 3 wybranych dni. Wystarczy dostarczyć te dane i wykorzystać je do utworzenia odpowiednich adresów URL, z których zostaną pobrane zasoby (Rys. 5). W przypadku wykorzystania tego węzła należy pamiętać o określeniu wyjściowego modelu danych na odpowiedniej zakładce.

 

rysunek 5

Rysunek 5

 

Efekt działań widoczny jest na Rys. 6 – liczba zaraportowanych zachorowań, zgonów i wyzdrowień dla Polski, Niemiec i Czech pomiędzy 1 a 3 listopada 2020 r. Tak otrzymane dane są gotowe do dalszego przetwarzania w ramach procesu.

 

mapka

Rysunek 6

 

Na rys. 5 oprócz omówionych zmiennych, pojawiła się kolumna „Method”, zawierająca w każdym rekordzie „GET”. Odpowiada ona za wybór typu żądania (metody), które wysyłamy do określonego serwisu. Poza „GET” możemy skorzystać również z „POST” (przesyłanie nowych danych do usługi), „PUT” (zwykle w celu zmiany/aktualizacji już obecnych danych) oraz „DELETE” (usuwanie danych znajdujących się w usłudze). Jak widać, przy użyciu węzła przejściowego PS REST można nie tylko pobierać dane z zewnętrznych serwisów, ale także samemu udostępniać, zmieniać lub usuwać dane na serwisach, które sami tworzymy. Pozwala to więc na kompletną współpracę z usługami sieciowymi.

W podobny sposób wykorzystać można węzeł przejściowy PS SOAP jeżeli usługa, z którą chcemy współpracować zaprojektowana jest w takim stylu. Wymaga to oczywiście dostosowania się do danego serwisu i odpowiedniego skonfigurowania koperty SOAP.

Wyjściowe węzły PS REST/PS SOAP - zastosowanie

Węzły PS REST i PS SOAP, które określamy jako „wyjściowe” lub „exportu” w pewnym stopniu działają podobnie do węzłów przejściowych:

  1. Umożliwiają działanie w dwóch dostępnych trybach – wysyłania pojedynczego żądania albo osobnych żądań dla każdego dostarczonego rekordu.
  2. Zawartość wysyłanych komunikatów może być uzależniona od otrzymanych danych (zmienne odpowiadają za ustawienia poszczególnych własności węzłów), ale nie musi – komunikat może być ustalony statycznie i być wysyłany w takiej samej formie, niezależnie od otrzymanych z poprzedniego węzła danych.

Główna różnica w porównaniu do węzłów przejściowych wynika z tego, że mówimy o węzłach końcowych. Oznacza to, że służą one jedynie do wysyłania danych/komunikatów, a nie do ich odbioru. Niemożliwe jest pobieranie danych. Nie otrzymamy więc w odpowiedzi żadnych informacji, które moglibyśmy dalej przetwarzać. Z tego względu węzły te wykorzystujemy zazwyczaj do:

  • wysyłania różnego rodzaju poleceń do systemów wewnętrznych/zewnętrznych (np. do uruchamiania określonych procesów w takich systemach),
  • przesyłania danych do ww. systemów,
  • modyfikacji zasobów udostępnianych przez nas w usłudze sieciowej (dodanie nowych zasobów, edycja lub skasowanie obecnych).

Zastosowania tych działań są bardzo szerokie i będziemy jeszcze do nich wracać w kolejnych artykułach na naszych blogu. Tym, które przedstawimy dziś jest przesyłanie żądania uruchomienia zadania utworzonego w PS CLEMENTINE Managerze. Jednocześnie jest to przykład, który można odnieść do uruchamiania innych zewnętrznych procesów, opartych o REST lub SOAP API.

Załóżmy, że mamy utworzone zadanie, które pobiera z wspomnianego wcześniej serwisu dane na temat epidemii COVID-19 dla wybranego kraju i zakresu dat, a następnie wprowadza te dane do bazy danych. Kraj i zakres dat do pobrania danych są określane poprzez parametry uruchomienia zadania. Możemy takie zadanie uruchomić i skonfigurować ręcznie, ale możemy je też uruchomić przy pomocy komunikatu SOAP lub REST. Dzięki temu, możemy takie zadanie wykorzystać w dłuższym procesie - jesteśmy bowiem w stanie utworzyć strumień, który najpierw decyduje o parametrach uruchomienia zadania, a potem faktycznie je uruchamia.

Przykładowo: strumień poprzedzający zadanie może służyć do weryfikacji poprawności danych – codziennie sprawdzać, czy dane na temat poziomów dziennych zachorowań w bazie danych nie wyglądają „podejrzanie”. Jeśli spełniają reguły, które sugerują, że wybrane rekordy mogą być niepoprawne (np. obserwujemy ujemne przyrosty dziennych zachorowań lub kilkukrotnie obserwujemy jednakowe przyrosty), to selekcjonuje takie rekordy, określa na ich podstawie datę i kraj, a następnie uruchamia wspomniane wcześniej zadanie, którego celem jest  ponowne pobranie aktualnie dostępnych danych i wprowadzenie ich do bazy. Zadanie zostaje uruchomione dla określonych we wcześniejszym procesie parametrów daty oraz kraju. Takie działanie można wykonać m.in. przy użyciu wyjściowego węzła PS SOAP, który umożliwia skonfigurowanie treści koperty, uwzględniając dane otrzymane z poprzedniego węzła (rys. 7). W kolejnych wpisach poruszymy głębiej kwestie związane z wywoływaniem zadań w PS CLEMENTINE PRO 3.0 przy użyciu usług sieciowych.

mapka

Rysunek 

 


Oceń artykuł:


Udostępnij artykuł w social mediach

Zostańmy w kontakcie!

Chcesz dostawać wiadomości o nowych wpisach na blogu
i webinarach z zakresu analizy danych?
Zapisz się na powiadomienia e-mail.