Opis zagadnienia
Dostępne są już cztery nieprogramowalne usługi sieciowe, które do zdalnych wywołań wykorzystują protokół SOAP. Są to eksport danych, import danych i zdalne wyszukiwanie jako wyspecjalizowane usługi sieciowe. Ponadto każda aplikacja działająca w tle może zostać wywołana jako bezstanowa usługa sieciowa poprzez CallApplication. Ten interfejs usług sieciowych wykorzystuje ogólnie dostępną bibliotekę usług sieciowych Apache Axis.
Dodatkowo dostępny jest jeszcze interfejs do programowalnych usług sieciowych. Umożliwia on implementację własnych usług sieciowych jako usługi SOAP lub REST, w zależności od potrzeb. Ten interfejs usług sieciowych wykorzystuje ogólnie dostępną bibliotekę usług sieciowych Apache CXF. Więcej informacji na temat biblioteki CXF znajdują się na stronie: http://cxf.apache.org/ (źródło z 31/01/2011).
Paczka instalacyjna zawiera przykładowe usługi SOAP i REST, a także przykładowego klienta SOAP zaimplementowanego w języku Java.
Niniejsza dokumentacja opisuje kroki wymagane do stworzenia indywidualnie zaprogramowanych usług sieciowych, a także przykładowych usług sieciowych i klientów. Pokrótce wyjaśnia również narzędzie Soap UI do testowania usług SOAP i REST.
Grupa docelowa
- Deweloperzy aplikacji
- Konsultanci techniczni
Definicje pojęć
Hipermedia – tekstowe połączenie hipertekstu i danych multimedialnych. Hipermedia opiera się na koncepcji linków (hiperłączy), które są przede wszystkim znane z HTML i umożliwiają użytkownikowi poruszanie się po sieci lub dostęp do osadzonych da-nych, takich jak dokumenty PDF.
JAXB – skrót od Jakarta XML Binding. Interfejs Java, który opisuje, w jaki sposób dane z instancji schematu XML są automatycznie mapowane do klas Java i w jaki sposób te klasy Java są generowane ze schematu XML.
JAX-RS – skrót od Jakarta RESTful Web Services. Specyfikacja interfejsu Java, która umożliwia i standaryzuje wykorzystanie w aplikacji stylu architektury REST w kontekście usług sieciowych.
JAX-WS – skrót of Jakarta XML Web Services. Specyfikacja interfejsu Java do tworzenia usług sieciowych.
Reprezentacja to dowolna użyteczna informację o stanie zasobu. Przedstawia ona zasób w określonym formacie. Reprezentacja zasobu może odnosić się do innych zasobów. Mogą być używane następujące reprezentacje: XML, HTML, CSV, formaty binarne, tekst bez zdefiniowanej struktury (text/plain).
Żądanie – dane wejściowe lub interakcje użytkownika są przesyłane do serwera przez komputer użytkownika, tzw. klient, za pośrednictwem sieci. Dane otrzymane przez serwer są określane jako żądanie. Po przetworzeniu danych serwer, w odpowiedzi do klienta, wysyła potwierdzenie lub nowe dane. Komunikacja mię-dzy klientem a serwerem zawsze składa się z żądania i odpowiedzi.
Odpowiedź – dane wejściowe lub interakcje użytkownika są przesyłane do serwera przez komputer użytkownika, tzw. klient, za pośrednictwem sieci. Serwer przetwarza dane i przesyła do klienta odpowiedź w postaci potwierdzenia lub nowych da-nych. Komunikacja między klientem a serwerem zawsze składa się z żądania i odpowiedzi.
REST – skrót od Representational State Transfer. Styl architektury do wymiany wiadomości w rozproszonych hipermedialnych systemach informacyjnych opartych na HTTP. Nie ma on charakteru protokołu i nie jest obecnie standaryzowany. W przeciwieństwie do SOAP, nie jest wymagana znajomość konwencji protokołów, aby klient i serwer mogli się komunikować. Szczególnie ważne są następujące podstawowe zasady:
- Adresowalność zasobów
- Wykorzystanie hipermediów opartych na HTML lub XML
- Zastosowanie standardowych operacji HTTP
- Bezstanowa komunikacja, która nie odwołuje się do stanu serwera! REST zakłada, że stan ten jest utrzymywany przez klienta lub konwertowany przez serwer na status zasobu. Niepożądany jest natomiast przechowywany po stronie serwera przejściowy, specyficzny dla klienta stan wykraczający poza okres trwania żądania.
Zgodny z REST protokół HTTP – zastosowanie operacji HTTP w następujący sposób:
- GET: Pobieranie danych z serwera
- POST: Zapisywanie nowych danych na serwerze
- PUT: Aktualizowanie istniejących danych
- DELETE: Usuwanie danych
- HEAD: Pobieranie metadanych zasobu
- OPTIONS: Sprawdzanie, które operacje są dostępne dla zasobu
Usługa REST – usługa sieciowa wykorzystująca styl architektury REST.
Zasób (sieciowy) – termin zasób sieciowy (zwany również zasobem) używany jest w odniesieniu do źródła w dowolnym miejscu w sieci, które można jednoznacznie zidentyfikować za pomocą identyfikatora URI (patrz również standard RFC 3986). Przykładowymi zasobami sieciowymi są: pliki, wykresy, usługi internetowe i serwlety, a także kolekcje innych zasobów, które mogą być adresowane za pomocą identyfikatorów URI. Zasób może posiadać kilka reprezentacji.
SOAP – skrót od Simple Object Access Protocol. Jest to oparty na XML protokół do wymiany wiadomości w systemach rozproszonych. Służy on do komunikacji między klientami usług sieciowych a serwerami.
Usługa SOAP – usługa sieciowa wykorzystująca protokół SOAP do zdalnych wywołań.
WADL – skrót od Web Application Description Language. Język opisu usług sieciowych zgodnych ze standardem REST.
WSDL – skrót od Web Services Description Language. Język opisu interfejsu usługi sieciowej.
Opis
Interfejs programowalnych usług sieciowych umożliwia stworzenie własnej usługi sieciowej jako usługi SOAP lub REST. Decyzja, czy użyć usługę SOAP czy REST, zależy od konkretnych wymagań.
Warunki wstępne
SAS, na którym wykonywana jest programowalna usługa sieciowa, musi zostać uruchomiony razem z serwerem sieciowym. Spowoduje to również uruchomienie serwera usług sieciowych. Jest to standardowy scenariusz w systemie. Serwer usług sieciowych nie może być uruchamiany oddzielnie od serwera sieciowego.
Rozwój programowalnej usługi sieciowej
Rozwój programowalnej usługi sieciowej składa się z kilku etapów: od utworzenia obiektu deweloperskiego Aplikacja do implementacji wewnętrznej klasy Java, w której realizowane są funkcje usługi sieciowej.
Projektowanie interfejsu usług sieciowych
Interfejs usługi sieciowej, która ma zostać zaprogramowana, musi być zaprojektowany zgodnie z wymaganiami technicznymi i biznesowymi. Należy zauważyć, że infrastruktura dostępna do realizacji usługi sieciowej w systemie nie nadaje się do przesyłania dużych ilości danych. Otrzymane lub wysłane dane muszą być całkowicie przetworzone w pamięci głównej serwera aplikacji. Może to stanowić duże obciążenie serwera i spowodować znaczne spadki wydajności.
http://cxf.apache.org/docs/debugging-and-logging.html
Jeśli komunikaty generowane są w kolejce komunikatów w czasie trwania żądania klienta w ramach implementacji usługi sieciowej, nie są one automatycznie zwracane do klienta. Implementacja usługi sieciowej ma za zadanie zwrócić te komunikaty do klienta w razie potrzeby.
Tworzenie obiektów deweloperskich typu Klasa Java i Aplikacja
Utwórz obiekt deweloperski typu Klasa Java i Aplikacja. Zalecane jest nazwanie klasy Java i aplikacji identycznie oraz użycie przyrostka service.
Przestrzeń nazw (namespace) powinna zaczynać się jak odpowiadające mu przestrzeń nazw .log i kończyć się na .soap lub .rest zamiast .log.
Klasa Java musi wywodzić się z klasy abstrakcyjnej CisWebServiceApplication. Ta nadrzędna klasa definiuje metodę init(). Dalsza implementacja zależy od tego, czy tworzona jest usługa SOAP czy REST.
Następnie należy utworzyć obiekt deweloperski Aplikacja. Usługę sieciową identyfikuje w pełni kwalifikowana nazwa aplikacji.
Aplikacja musi być typu Usługa RPC. Jako specjalne zastosowanie należy wybrać Usługa SOAP lub Usługa REST.
Identyfikator URI żądania
Identyfikator URI żądania usługi sieciowej
Aby wywołać usługi sieciowe, należy wywołać oddzielny identyfikator URI specyficzny dla danej usługi sieciowej. Identyfikator URI ma następującą strukturę:
- Dla usługi SOAP
https://<base url>/services/soap/<w pełni kwalifikowana nazwa aplikacji>?oltp=<nazwa bazy danych>
Element services/soap URI żądania sygnalizuje serwerowi usług sieciowych, że jest to usługa SOAP. - Dla usługi REST
https://<base url>/services/rest/<w pełni kwalifikowana nazwa aplikacji>/<zasób>/<możliwe parametry>/?oltp=<nazwa bazy danych>
Element services/rest identyfikatora URI żądania sygnalizuje serwerowi usług sieciowych, że jest to usługa REST. Element <zasób> uruchamia żądaną funkcjonalność, która wywoływana jest z wymaganymi parametrami.
Ogólne parametry zapytania identyfikatora URI żądania
Można użyć następujące ogólne parametry zapytania:
| Parametr zapytania | Opis |
| displayLanguage | Określa żądany język wyświetlania. |
| contentLanguage | Określa żądany język zawartości. |
| oltp | Nazwa baza danych OLTP. |
| context | Kod wymaganej organizacji. |
| wsdl | Sygnalizuje serwerowi usług sieciowych, aby dostarczył plik WSDL dla usługi SOAP. Wsdl musi być określony jako pierwszy parametr zapytania. |
| _wadl | Sygnalizuje serwerowi usług sieciowych, aby dostarczył plik WADL dla usługi REST. |
W przypadku użycia kilku parametrów zapytania należy je oddzielić znakiem & lub średnikiem (;).
Rozwój usługi SOAP
Stworzona klasa Java musi zawierać klasę wewnętrzną oznaczoną za pomocą JAX-WS:
@WebService
Oznaczenie to nie wymaga żadnej wartości. Klasa wewnętrzna służy do definiowania i implementacji usługi SOAP. Nazwa klasy wewnętrznej definiuje nazwę usługi w pliku WSDL. Zalecane jest, aby klasa wewnętrzna nie kończyła się na service.
Wszystkie metody publiczne zaimplementowane w tej klasie wewnętrznej są dostępne dla klienta SOAP jako funkcjonalne komponenty usługi SOAP.
Więcej informacji na temat JAX-WS, w szczególności na temat korzystania z oznaczenia znajduje się na stronie http://cxf.apache.org/docs/developing-a-service.html.
Przykład usługi SOAP
Paczka instalacyjna zawiera następującą aplikację oraz klasę Java o takiej samej nazwie:
com.cisag.app.system.webservices.service.soap.SOAPExampleService
Metoda init() zawiera inicjalizację wewnętrznego obiektu i menedżera transakcji. Klasa wewnętrzna SOAPExample zawiera definicję i implementację usługi SOAP. Klasa ta oznaczona jest za pomocą @WebService.
Poniższa metoda umożliwia konkatenację słowa powitalnego Hello z parametrem name i jego zwrócenie:
string sayHello(string name)
Poniższej metody można użyć do sprawdzenia, czy istnieje zlecenie sprzedaży o zdefiniowanym rodzaju i numerze.
boolean existSalesOrder(string type, string number)
Poniższa metoda zwraca obiekt bean SalesOrderResult na podstawie zdefiniowanego typu i numeru. Zawiera ona informacje o statusie zamówienia sprzedaży i nazwisko odpowiedzialnego pracownika. Należy pamiętać, że obiekt bean musi zostać zaprogramowany jako statyczna klasa Java.
public SalesOrderResult getSalesOrderByBusinessKey(string type, string number)
Wersja SOAP
Programowalne usługi SOAP używają domyślnie wersji SOAP 1.2 w pliku WSDL. Odpowiedzi SOAP wysyłane są w wersji SOAP, której klient użył do żądania SOAP (SOAP 1.1 lub SOAP 1.2).
W usłudze SOAP można określić, że usługa powinna obsługiwać tylko wersję 1.1 SOAP. W takim przypadku, w pliku WSDL zostanie użyty SOAP 1.1. Dodatkowo należy określić następujące oznaczenie dla klasy wewnętrznej:
@javax.xml.ws.BindingType(value = ja-vax.xml.ws.soap.SOAPBinding.SOAP11HTTP_BINDING)
Należy zauważyć, że nieprogramowalne usługi sieciowe, które zostały opisane w artykule Interfejs usług sieciowych używają SOAP 1.1.
Stanowe usługi SOAP
Usługi SOAP mogą być również wywoływane jako usługi stanowe. Dla każdej usługi, która jest wywoływana w sesji, tworzona jest instancja aplikacji z powiązanym obiektem usługi. Kolejne wywołania tej samej usługi w ramach tej samej sesji są wywoływane na już utworzonym obiekcie usługi.
Usługa może zatem zapisywać stan między różnymi wywołaniami za pomocą atrybutów w instancji aplikacji lub obiektu usługi.
Należy pamiętać, że sesje są kończone automatycznie, jeśli nie są używane po upływie czasu oczekiwania. Aby sesja pozostała otwarta, musi zostać wykonane co najmniej jedno wywołanie dowolnej usługi sieciowej dla tej samej sesji w czasie oczekiwania. W tym celu, system udostępnia bezparametrową metodę ping dla usług SOAP:
com.cisag.sys.tools.webservices.log.Session
Rozwój usługi REST
Stworzona klasa Java musi zawierać klasę wewnętrzną oznaczoną za pomocą JAX-RS:
@Path(“w pełni kwalifikowana nazwa aplikacji REST”)
Oznaczenie to wymaga jako wartości w pełni kwalifikowanej nazwy utworzonej aplikacji, dla której określono Usługa REST jako typ oraz Usługa REST jako specjalne zastosowanie. Nazwa ta reprezentuje zasób główny, który jest wymaganym składnikiem identyfikatora URI żądania usługi REST. Ponadto klasa wewnętrzna musi posiadać publiczny konstruktor.
Funkcjonalności usługi REST dostępne dla klienta REST są reprezentowane przez metody publiczne (metody resource), które są wyróżnione oznaczeniami JAX-RS:
- Request method designator (@GET or @PUT or @POST or @DELETE)
- @Path (“nazwa zasobu oraz wszelkie inne parametery”)
Wartości przypisane do oznaczenia @Path stanowią dalsze składniki identyfikatora URI żądania, które są względne w stosunku do głównego zasobu. Wartości mogą zawierać symbole zastępcze w nawiasach klamrowych.
Podczas programowania metod Resource należy zwrócić uwagę na następujące kwestie w odniesieniu do operacji HTTP:
- GET wysyła zapytanie o reprezentację zasobu. Żądania nie powinny zawierać efektów ubocznych.
- POST służy do dodania czegoś do zasobu. POST zawiera efekty uboczne.
- PUT za pomocą PUT można tworzyć nowe zasoby lub zastępować zawartość istniejących zasobów.
- DELETE służy do usuwania zasobów.
Należy również zwrócić uwagę na następujący opis JAX-RS:
Java™ API for RESTful Web Services
http://jsr311.java.net/nonav/releases/1.1/spec/spec.html
Więcej przydatnych informacji na temat oznaczeń, które mogą być używane w realizacji usługi REST można znaleźć na stronie http://cxf.apache.org/docs/jax-rs-basics.html2. Niektóre z oznaczeń zostały wyjaśnione w przykładzie w niniejszym artykule.
W komentarzach do metod resource można znaleźć informacje jak wywołać funkcjonalność usługi REST. Wszystkie funkcjonalności oznaczone operacją HTTP GET można wywołać bezpośrednio w przeglądarce Internet Explorer. Narzędzie Soap UI może być używane do innych operacji HTTP.
Przykład usługi REST
com.cisag.app.system.webservices.service.rest.RESTExampleService
Metoda init() zawiera inicjalizację obiektu i menedżera transakcji. Klasa wewnętrzna RESTExample zawiera definicję i implementację usługi REST. Klasa ta oznaczona jest za pomocą:
@Path(“com.cisag.app.system.webservices.service.rest.RESTExampleService”)
Poniższa metoda resource umożliwia konkatenację słowa powitalnego Hello z parametrem name i zwrócenie go domyślnie jako plain/text:
@GET
@Path(“sayHello/{name}”)
public string sayHello(@PathParam(“name”) string name)
Oznaczenie @GET wskazuje, że do żądania należy użyć metody HTTP GET. Ozna-czenie @Path zawiera wartość „sayhello/{name}”, gdzie „sayhello” jest identyfikatorem funkcjonalności, a {name} to wymagany symbol zastępczy, który jest powiązany z parametrem “name” metody resource poprzez dodatkowe oznaczenie @PathParam(“name”).
Poniższej metody resource można użyć do sprawdzenia, czy istnieje zamówie-nie sprzedaży o zdefiniowanym typie i numerze.
@GET
@Path(“salesOrderAvailable/{type}/{number}”)
public string existSalesOrder(@PathParam(“type”) string type, @PathParam(“number”) string number)
Poniższa metoda resource zwraca obiekt bean SalesOrderBean na podstawie zdefiniowanego typu i numeru. Zawiera on informacje o typie, numerze i statu-sie zamówienia sprzedaży oraz nazwisko odpowiedzialnego pracownika.
@GET
@Path(“getSalesOrder/{type}/{number}”)
@Produces(MediaType.APPLICATION_XML)
public SalesOrderBean getSalesOrderByBusinessKey(@PathParam(“type”) string type, @PathParam(“number”) string number)
Oznaczenie @Produces opisuje reprezentację w postaci XML. Należy pamiętać, że obiekt bean obsługujący JAXB jest oznaczany za pomocą @XmlRootElement(name = “SalesOrderBean”).
Poniższa metoda resource tworzy w pamięci głównej nową instancję obiektu bean SalesOrderBean o określonym typie, numerze i statusie, i zwraca repre-zentację jako HTML.
@POST
@Path(“newSalesOrderBean/{type}/{number}/{orderStatus}”)
@Produces(MediaType.TEXT_HTML)
public SalesOrderBean newSalesOrder(@PathParam(“type”) string type, @PathParam(“number”) string number, @PathParam(“OrderStatus”) short orderStatus)
Instancja nie jest zapamiętywana. W przeciwieństwie do innych metod resour-ce, ta metoda jest oznaczona za pomocą @POST.
Pobieranie pliku WSDL/WADL
Plik WSDL lub WADL jest wymagany do stworzenia klienta usług internetowych. Struktura odpowiedniego identyfikatora URI żądania jest następująca:
- Dla usługi SOAP
https://<base uri>/services/soap/<w pełni kwalifikowana nazwa aplikacji>?wsdl
Składnik identyfikatora URI żądania „wsdl” sygnalizuje serwerowi usług internetowych, że plik WSDL musi zostać przygotowany i udostępniony. Po wpisaniu identyfikatora URI żądania w pasku adresu przeglądarki pojawi się okno dialogowe uwierzytelniania. Po pomyślnym uwierzytelnieniu wyświetlony zostanie plik WSDL. Można go zapisać za pomocą opcji Zapisz jako przeglądarki Internet Explorer. - Dla usługi REST
https://<base uri>/services/soap/<w pełni kwalifikowana nazwa aplikacji>?_wadl
Składnik identyfikatora URI żądania „wadl” sygnalizuje serwerowi usług internetowych, że plik WADL musi zostać przygotowany i udostępniony. Po wpisaniu identyfikatora URI żądania w pasku adresu przeglądarki pojawi się okno dialogowe uwierzytelniania. Po pomyślnym uwierzytelnieniu pojawi się okno dialogowe pobierania pliku, umożliwiające zapisanie pliku WADL. Należy pamiętać, że plik WADL może być niekompletny, na przykład może brakować parametrów. Zależy to od programowania danej usługi REST.
Uwierzytelnienie i autoryzacja
Aby móc wywołać usługę sieciową, klient musi uwierzytelnić się na serwerze sieciowym. Uwierzytelnianie odbywa się za pomocą uwierzytelniania skrótu lub certyfikatu klienta. W opisie przykładowego klienta w rozdziale: Przykładowy klient usługi SOAP. Uwierzytelnienie odbywa się za pomocą certyfikatu klienta.
Programowalne usługi sieciowe są aplikacjami. Dlatego użytkownik musi posiadać uprawnienia do otwarcia aplikacji, aby móc wywołać usługę sieciową.
Wsparcie w zakresie redukowania liczby błędów (debugowania)
Serwer usług sieciowych systemu ERP umożliwia wyświetlanie informacji o żądaniach od klientów. Dotyczy to zarówno nieprogramowalnych i programowalnych usług sieciowych.
Aby to zrobić należy aktywować debugowanie klasy Java com.cisag.sys.kernel.webservices.CisWebServicesResource w SAS, która jest wywoływana przez klientów.
W zależności od poziomu debugowania, w powłoce narzędzia wyświetlane są następujące informacje:
| Poziom debugowania | Dane wyjściowe |
| INFO | Przy każdym wywołaniu usługi sieciowej informacje wyświetlane są na początku i na końcu przetwarzania w SAS.
Dane wyjściowe zawierają: numer sesji, metodę HTTP, identyfikator URI żądania, czas przetwarzania. |
| FINEST | Oprócz danych wyjściowych poziomu debugowania INFO, poziom FINEST dostarcza zawartość (treść HTTP) żądania klienta i odpowiedź usługi sieciowej. |
Wyświetlanie danych wyjściowych można włączyć i wyłączyć dla uruchomionego SAS za pomocą polecenia toolshell dbgcls (debug class).
Przykłady usług sieciowych klientów
Przykładowy klient usługi SOAP
Poniższa klasa zawiera aktualną implementację klienta:
com.cisag.app.system.webservices.service.soap.client.SOAPExampleClient
Dodatkowo, do programowania klienta potrzebne są następujące klasy:
- com.cisag.app.system.webservices.service.soap.client.ExistSalesOrder
- com.cisag.app.system.webservices.service.soap.client.ExistSalesOrderResponse
- com.cisag.app.system.webservices.service.soap.client.GetSalesOrderByBusinessKey
- com.cisag.app.system.webservices.service.soap.client.GetSalesOrderByBusinessKeyResponse
- com.cisag.app.system.webservices.service.soap.client.ObjectFactory
- com.cisag.app.system.webservices.service.soap.client.SalesOrderResult
- com.cisag.app.system.webservices.service.soap.client.SayHello
- com.cisag.app.system.webservices.service.soap.client.SayHelloResponse
- com.cisag.app.system.webservices.service.soap.client.SOAPExample
- com.cisag.app.system.webservices.service.soap.client.SOAPExampleService
Klasy te tworzone są z pliku WSDL za pomocą narzędzia wsimport. Narzędzie wsimport jest częścią JDK od wersji Java 6.
Plik WSDL tworzony jest za pomocą żądania:
https://<base uri>/services/soap/com.cisag.app.system.webservices.service.soap.SOAPExampleService?wsdl
Zamiast symbolu zastępczego <base uri> podawany jest rzeczywisty adres.
Narzędzie wsimport jest następnie wywoływane w następujący sposób poniżej <Katalog JDK>/bin:
wsimport -p com.cisag.app.system.webservices.service.soap.client -d <ścieżka dla plików .class> -s <ścieżka dla plików źródłowych> <ścieżka z nazwą pliku WSDL> -Xnocompile -extension
Zamiast symbolu zastępczego „path” podawane są rzeczywiste ścieżki.
Po utworzeniu, poniższa klasa zawiera ścieżkę do pliku WSDL:
com.cisag.app.system.webservices.service.soap.client.SOAPExampleService
Ścieżka ta jest zastępowana następującym identyfikatorem URI:
<base uri>/services/soap/com.cisag.app.system.webservices.service.soap.SOAPExampleService?wsdl&oltp=<oltpname>
Poniższa klasa zawiera metodę main, w której odbywa się sprawdzanie parame-trów:
com.cisag.app.system.webservices.service.soap.client.SOAPExampleClient
W ramach tej metody wykonywane jest:
- Utworzenie instancji SOAPExampleService
- Utworzenie obiektu usługi
- Uwierzytelnienie
- Wywołanie metody usługi SOAP existSalesOrder(salesOrderType, sale-sNumber)
Poza systemem klient musi zostać wywołany w następujący sposób:
com.cisag.app.system.webservices.service.soap.client.SOAPExampleClient SOAPServiceAddress userCertificateFileName userCertificateFi-lePassword serverCertificateFileName salesOrderType salesNumber
Zamiast SOAPServiceAddress należy wpisać pełny adres usługi SOAP zawierają-cy nazwę bazy danych OLTP, np.: https://qas.kauftreu.com/services/soap/com.kauftreu.app.system.webservices.service.soap.SOAPExampleService?oltp=QAS51000
Dla salesOrderType i salesNumber należy określić odpowiednio typ zamówienia sprzedaży oraz jego numer.
Zamiast userCertificateFileName i serverCertificateFileName należy wprowadzić pełną ścieżkę i nazwę pliku JKS.
Exception in thread „main” com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLException: Unrecognized SSL mes-sage, plaintext connection? at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:121) at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:142)at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83)at
Przykładowy klient SOAP jest zaprogramowany tak, aby wszystkie żądania były przypisywane do tych samych sesji.
Przykładowy klient usługi REST
Dla poszczególnych żądań można użyć narzędzia Soap UI, który jest opisany w rozdziale Testowanie usług sieciowych za pomocą narzędzia Soap UI.
Testowanie usług sieciowych za pomocą narzędzia Soap UI
Narzędzie Soap Ui umożliwia przetestowania usług SOAP i REST. Poniższy opis dotyczy wersji 3.6.1. Pełna dokumentacja oraz instrukcje instalacji narzędzia znajdują się pod adresem:
http://soapui.org/REST-Testing/getting-started.html
Ustawienia Soap Ui
Do przetestowania usługi sieciowej potrzebny jest plik WSDL lub WADL. Potrzebny jest również plik JKS certyfikatu użytkownika do uwierzytelniania wraz z hasłem do tego pliku. Certyfikat użytkownika musi być przypisany do odpowiedniego użytkownika, który testuje usługę sieciową. Ścieżkę do pliku i hasło należy wprowadzić w sekcji SSL Settings okna dialogowego SoapUI Preferences.
Zalecenie:
Zalecamy wprowadzenie wartości 120000 dla Socket Timeout w sekcji HTTP Settings.
Okno dialogowe SoapUI Preferences można otworzyć za pomocą kombinacji klawiszy CTRL+ALT+P lub wybierając opcję SoapUi Preferences w menu File.
Nowy projekt Soap UI
Po wprowadzeniu ustawień Soap UI należy utworzyć nowy projekt SoapUI za pomocą kombinacji klawiszy CTRL+N lub wybierając opcję New SoapUi Project w menu File. W otwartym oknie dialogowym należy wprowadzić nazwę projektu oraz ścieżkę do pliku WSDL lub WADL. Po naciśnięciu OK zostanie utworzony projekt o hierarchicznej strukturze. Poszczególne węzły reprezentują całą usługę sieciową albo poszczególne funkcjonalności lub ich operacje HTTP (tylko dla usługi REST).
Należy pamiętać, że nazwy ogólnych parametrów zapytania (np. oltp lub context) nie są częścią pliku WSDL czy WADL. Parametry te należy wprowadzić ręcznie:
- W przypadku usługi SOAP należy rozwinąć węzły z funkcjonalnościami do przetestowania aż do węzła Request<number>. Następnie należy najechać na pasek adresu okna dialogowego, wybrać opcję [edit current…] i dodać żądany parametr do identyfikatora URI.
- W przypadku usługi REST należy rozwinąć węzeł z nazwą usługi sieciowej. Powinna to być nazwa aplikacji utworzona w systemie ERP. Należy kliknąć na nią dwa razy. W otwartym oknie dialogowym należy dodać kolejne parametry.
Aby uzyskać dostęp do usługi sieciowej należy rozwinąć węzły z funkcjonalnościami do przetestowania aż do węzła Request<number>. Kliknięcie tego węzła spowoduje wyświetlenie okna dialogowego, w którym można wysłać żądania do usług sieciowych, jak i wyświetlić ich odpowiedzi.
W pewnych przypadkach plik WADL może nie być kompletny, np. może brakować parametrów wymaganych dla żądania. W takim przypadku należy dodać niezbędne parametry ręcznie.
Za pomocą narzędzia Soap UI można wyświetlać różne pliki dziennika. Na przykład zakładki Soap UI log i error log wyświetlane są w dolnej części głównego okna.
