Usługi w chmurze - bujanie w obłokach
Czasy mamy jak widać internetowe, nawet w amatorskiej elektronice. Gdzie by nie spojrzeć - wszędzie dookoła same chmury, streamingi, webcasty i inne usługi sieciowe, którymi warto się chyba zainteresować, bo a nuż przydatnymi będą dla naszych projektów.
Jeszcze do niedawna, znakomita większość usług sieciowych zwracających użyteczne dla plebsu dane (kursy walut, pogodę, rozkłady jazdy, natężenie ruchu drogowego, etc/itd) operowała głównie protokołem SOAP/HTTP(s) czyli w uproszczeniu komunikatami XML wysyłanymi jako żądanie do serwera, takoż XML zwracany był przez zdalny system jako wynik realizacji usługi. Wszechobecność urządzeń mobilnych wymusiła pewną optymalizację wykorzystania ruchu sieciowego (za który się płaci), a jak łatwo zgadnąć - komunikaty przesyłane via XML charakteryzują się sporym narzutem natury składniowej - ilość danych vs objętość znakowa tagów XML jest częstokroć niekorzystna (spory narzut tagów XML). Format zapisu/przesyłania danych JSON (JavaScript Object Notation) jest tu o niebo korzystniejszy, choć nie zapewnia takich mechanizmów weryfikacji struktury wiadomości (walidacji) jak SOAP. Nie chcę tu powielać ogólnie dostępnych w sieci informacji, może wskaże tylko kilka punktów zaczepienia, kto ciekaw - poklika dalej:
Podstawowe informacje o JSON
https://pl.wikipedia.org/wiki/JSON https://www.w3schools.com/js/js_json_intro.aspPorównanie SOAP i REST/JSON
http://spf13.com/post/soap-vs-rest/ https://blog.smartbear.com/apis/underst ... st-basics/ https://stackify.com/soap-vs-rest/Co ma do tego LabVIEW?
Ano właśnie, zdarza się czasem (a to mi właśnie wyjęło z życia ostatni tydzień), że nasza aplikacja w LabVIEW działająca na obiekcie musi skomunikować się przez sieć z zewnętrznym systemem i na przykład pobrać (dociągnąć) brakujące ad-hoc dane lub na koniec własnego przetwarzania poinformować otoczenie o jego wynikach. W dużych i smutnych systemach biznesowych króluje ciągle XML ubrany w SOAP, ale bardziej nowoczesne aplikacje wykorzystują coraz chętniej REST/JSON, ponieważ potencjalni usługobiorcy to urządzenia mobilne lub końcówki sterujące, dla których parsowanie wiadomości XML jest zbytnim wysiłkiem. Ja akurat musiałam przy pomocy LV wydobywać z systemu magazynowego informacje o wielgachnych pakach z żelastwem, no ale to za nudne jak na forum, zatem inaczej...
Pogodynka z Ameryki
Przykładzik poniżej to aplikacja LV pozyskująca dane pogodowe z portalu AccuWeather, który to portal udostępnia całkiem fajne API sieciowe właśnie w postaci usług REST/JSON
Detaliczny opis, co jest udostępniane i na jakich zasadach znajdziemy tu:
https://developer.accuweather.com/Napierwej należy odszukać swoje ulubione miasteczko przy pomocy Locations API
http://apidev.accuweather.com/developers/samples dla Ostrowca Świętokrzyskiego wywołanie wygląda następująco:
http://apidev.accuweather.com/locations ... rfRosT1215
ważny z tego niezmiernie jest zwracany key=266206, ponieważ to w rozumieniu AccuWeather unikalny identyfikator lokalizacji, dla której gromadzone są dane pogodowe.
Mając taki ID możemy spokojnie wywoływać usługę, która pokazuje nam to, co aktualnie mamy za oknem:
http://apidev.accuweather.com/currentco ... rfRosT1215
I tu dwie sprawy:
* to `apikey=hoArfRosT1215` w URL-u to demonstracyjny, do przykładów jeno, klucz użytkownika, podobne apikey dostaje się po założeniu konta na A.W itp; wartość z przykładów na ich stronkach jest tylko do celów poznawczych a nie do trwałego wykorzystania i może się nieoczekiwanie zmienić
* system zwraca dane w formacie JSON, super! i nawet przeglądarka FireFox potrafi je w prosty sposób sformatować i pokazać, niemniej jednak ja zachęcam do korzystania z utyliszczy on-line ułatwiających prezentację wiadomości JSON, o na przykład takich:
http://www.json.org/ http://jsonviewer.stack.hu https://www.freeformatter.com/json-formatter.htmlGdy nie mamy dokumentacji systemu lub jest ona szczątkowa, dobre formatowanie wyników jest bezcenne, ponieważ drastycznie skraca czas analizy (namóżdzania się) co tam jest do czego, które to jest obiekt a które to array itp. Bo na widok wiadomości JSON w notatniku to tylko idzie się zapłakać.
JSON-owe klocki do LabVIEW
Jak łatwo zgadnąć, wparcie dla JSON należy sobie doinstalować własnym sumptem z dostępnych dla LV repozytoriów. Detaliczny opis instalacji nowych klocków przy pomocy JKI VPM przedstawiłam w październikowej Elektronice dla Wszystkich, zatem tu tylko najpotrzebniejsze informacje. W szukajce JKI VMP wpisujemy `JSON` i wybieramy do instalacji paczkę 'i3 JSON', bo akurat ta mi najbardziej podpasowała.
Po instalacji nowe klocki dostępnę są w paletce Addons / LVH / i3 JSON
I od razu jedna uwaga moja, aby się nie zniechęcać w przypadku narowistości nowych komponentów, to darmowe oprogramowanie i robione przez entuzjastów, niepozbawione błędów i czasem zachowujące się przedziwnie - ot, złe wywołanie parsera struktury komunikatu JSON skutkuje błędem o niedostępności urządzenia na szynie GPIB...
Ale szyderę schowajmy sobie do kieszeni, bo jak się owe klocuszki wywołuje zgodnie z intencjami autorów - działają całkiem zwinnie, po prostu trzeba uważać co się robi, a sama lepszych nie umiałabym zrobić, więc tym bardziej.
Wróćmy teraz na chwile do informacji o pogodzie zwracanych przez AccuW w postaci tekstowej JSON i pokazywanych w przeglądarce jsonviewer.stack.hu, z połamanymi wierszami mamy co następuje:
interpretacja tablicowo-obiektowa jest następująca:
Taki podgląd jak powyżej jest o tyle istotny, ze klocki i3-JSON są dość wrażliwe na niepoprawne dane wejściowe, gdy nie zauważymy, że input jest u nas jednoelementową tablica obiektów, a podamy sam obiekt - dalej będą się działy cuda na widelcu.
Na czas dziergania aplikacji w LV dobrze skopiować sobie tekst JSON z przeglądarki i podstawiać go jako stałą do parsera, przecież jak zadziała dla tego jednego, to zadziała dla każdych kolejnych, aby tylko ich struktura nam pasowała:
Dla wprawy spróbujmy wydobyć z przychodzącego komunikatu wartość `LocalObserwationDateTime`. Z obrazka ze strukturą widać jasno, że jest to pole obiektu, będącego zerowym elementem wejściowej tabeli, zatem sekwencja klocków pozyskujących ową daną jest jak na rysunku poniżej:
Jak widać sekwencja klocuszków zadziałała znakomicie i mamy okienko dialogowe z datą i czasem tak jak nam odesłało AccuW.
Aby zmajstrować pogodynkę musimy dostać się do wartości temperatury zwracanej dla naszej lokalizacji, przyda się czas i data pomiaru, na późniejszym etapie - także numer ikonki symbolizującej aktualne warunki, np. słońce, średnie zachmurzenie, deszcze, etc, o tym będzie dalej. A póki co popatrzmy na w miarę kompletną testową aplikację, która z odpowiedzi JSON zwracanej przez AccuW. wydobywa oczekiwane przez nas wartości:
pogoda-1.vi pisze:
I na modłę Krokodyla z EdW 10/2017 - detaliczny opis znaczenia kolejnych klocków:
[2] - `Parse JSON` - komponent transformuje podany na wejście (tu: [1] - String Constant) napis na hierarchiczną strukturę obiektów JSON do dalszego wykorzystania, klocek typowo na wlocie całości, podawane napisy mogą pochodzić skądkolwiek - z RS232, z HTTP, z bazy danych, etc...
[3] - `Get Array Value at Index` - z podanej na wejście hierarchicznej struktury, traktując ją jako tablice - pobiera n-ty element i zwraca go dalej jako obiekt, tu - element o numerze 0, dlatego też wspominałam jak ważna jest choćby zgrubna wiedza o danych, z którymi mamy do czynienia...
[4] - `Get Object Parameter` - z podanego na wejście obiektu wydobywa wartość pola (member/właściwość/cechę) o wskazanej nazwie i zwraca jako daną wybranego typu (string, boolean, integer, double,...); tu klocek wydłubuje napis z data i czasem wskazany nazwą `LocalObservationDateTime`
[5] - `Get Object Parameter` - kolejny tego samego typu co powyżej, ale zwracający obiekt o nazwie `Temperature`
[6] - zgodnie z obrazkiem - w `Temperature` siedzą obiekty `Metric` oraz `Imperial`, poprosimy o ten pierwszy obiekt
[7] - z obiektu opisującego T 'po naszemu', poprosimy wartość `Value`, zwracana dana jest numeryczna tym razem
[8] - `Number To Fractional String` - konwersja wartości numerycznych na napis, ponieważ dalej lecą do MessageBox-a
[9] - `Concatenate Strings` - dodawanie napisów, dwa stringi z enter we środku, coby połamać linię
[10] - `One Button Dialog` - taki Message Box, używać należy rozsądnie, ponieważ blokuje wątek główny interfejsu użytkownika i póki kto nie wciśnie guzika - aplikacja sobie wisi i czeka...
Zostawmy teraz na chwilę JSON-y i inne dziwadła i spróbujmy pozyskać jakiekolwiek dane przy pomocy protokołu HTTP. Jest to w sumie banalnie proste ponieważ LV zawiera dedykowany ku temu komponent, który w znakomitej większości przypadków zupełnie wystarcza, oto proszę:
http-get-1.vi pisze:
[1] - `HTTP / GET` - kostka na wejście dostaje URL (adres sieciowy) zdalnego zasobu do pozyskania (stronka, obrazek, xml, tekst, etc) - po wykonaniu transakcji HTTP na wyjściu zwraca nagłówki protokołu (header) oraz treść odpowiedzi (body), a te wartości można pobrać do dalszego przetwarzania
[2] - znane już dodawanie napisów z enterkiem pośrodku
[3] - dialog, na którym tym razem widać nagłówki HTTP zwrócone przez AccuW oraz surową treść wiadomości JSON
Mając takie wiadomości możemy śmiało spokładać wszystko w całość: w nieskończonej pętli wywołujemy HTTP GET, odebrawszy odpowiedź z AccuW przetwarzamy ją na wskazania termometru
pogoda-2.vi pisze:
Cóż dalej?
Można oczywiście aplikacje dowolnie rozwinąć o pokazywanie ikony pogody, można dodać rysowanie wykresu temperatury w dziedzinie czasu, można dobudować interface zwracający lokalne dane w formacie AccuW, można wiele...
Więc dla chętnych i ciekawych - pliki do LabVIEW w załączniku.