Interfejs dla programowalnych usług sieci Web

Wprowadzenie

Dostępnych jest kilka nieprogramowalnych usług sieciowych, wykorzystujące protokół SOAP do połączeń zdalnych. Należą do nich m.in:

• eksport danych

• import danych

• zdalne wyszukiwanie – jako wyspecjalizowane usługi sieciowe

Dodatkowo, każda aplikacja działająca w tle może zostać wywołana jako bezstanowa usługa sieciowa za pomocą CallApplication. Interfejs ten wykorzystuje ogólnodostępną bibliotekę usług sieciowych Apache Axis.

Dostępny jest również dodatkowy interfejs przeznaczony dla programowalnych usług sieciowych. Umożliwia on implementację własnych usług sieciowych jako:

• usług SOAP

• usług REST

jeśli istnieje taka potrzeba. Interfejs ten opiera się na ogólnodostępnej bibliotece Apache CXF. Szczegółowe informacje na temat biblioteki CXF można znaleźć na oficjalnej stronie projektu:

http://cxf.apache.org/

Dostępne są przykładowe usługi SOAP i REST oraz przykładowy klient SOAP zaimplementowany w języku Java.

Niniejszy artykuł przedstawia kroki niezbędne do opracowania własnych programowalnych usług internetowych, a także opisuje przykładowe usługi i klientów. Pokrótce objaśnione zostało również narzędzie Soap UI, służące do testowania usług SOAP i REST.

Grupa docelowa

• programiści aplikacji

• konsultanci techniczni

Definicje pojęć

JAXB (Java Architecture for XML Binding) – interfejs Java, który opisuje, w jaki sposób dane z instancji schematu XML są automatycznie wiązane z klasami Java i w jaki sposób te klasy Java są generowane ze schematu XML.

JAX-RS (Java API for RESTful Web Services) – specyfikacja interfejsu Java, która umożliwia i standaryzuje wykorzystanie stylu architektonicznego REST w kontekście usług sieciowych.

JAX-WS (Java API for XML Web Services) – specyfikacja interfejsu Java do tworzenia usług sieciowych.

REST (Representational State Transfer) – styl pozwalający na wymianę wiadomości w rozproszonych hipermedialnych systemach informacyjnych opartych na protokole HTTP. Nie ma on charakteru protokołu i nie jest obecnie standaryzowany. W przeciwieństwie do SOAP, żadne konwencje protokołu nie muszą być znane, aby klient i serwer mogły się komunikować. Główną rolę odgrywają następujące podstawowe zasady:

• Adresowalność zasobów
• Wykorzystanie hipermediów opartych na HTML lub XML
• Wykorzystanie standardowych operacji HTTP
• Bezstanowość komunikacji, która nie odnosi się do stanu serwera. REST przewiduje, że stan ten jest utrzymywany przez klienta lub przekształcany w stan zasobu przez serwer. Przejściowy, specyficzny dla klienta stan przechowywany po stronie serwera na czas trwania żądania nie jest zamierzony.

Użycie protokołu HTTP zgodnego z REST (RESTful http) – użycie operacji HTTP w następujący sposób:

• GET – żądanie danych z serwera
• POST – przechowywanie nowych danych na serwerze
• PUT – aktualizacja istniejących danych
• DELETE – usuwanie danych
• HEAD – żądanie metadanych dla zasobu
• OPTIONS – sprawdzenie, które operacje są dostępne dla zasobu

Usługa REST – usługa sieciowa wykorzystująca styl architektoniczny REST.

SOAP (Simple Object Access Protocol) – oparty na XML protokół wymiany wiadomości w systemach rozproszonych. SOAP jest używany do komunikacji między klientami usług internetowych a serwerami.

Usługa SOAP – usługa sieciowa wykorzystująca protokół SOAP do połączeń zdalnych.

WADL (Web Application Description Language) -język opisu usług internetowych zgodnych ze standardem REST.

WSDL (Web Services Description Language) – język opisu interfejsu usługi sieciowej.

Opis

Interfejs programowalnych usług sieci Web można wykorzystać do opracowania usługi sieci Web jako usługi SOAP lub usługi REST. Decyzja o użyciu usługi SOAP lub REST zależy od konkretnych wymagań.

Wymagania wstępne

SAS, na którym uruchamiana jest programowalna usługa sieciowa, musi zostać uruchomiony razem z serwerem sieciowym. W ten sposób uruchamiany jest również serwer usług sieciowych. Serwer usług sieciowych nie może zostać uruchomiony oddzielnie od serwera sieciowego.

Tworzenie programowalnej usługi internetowej

Opracowanie programowalnej usługi sieciowej obejmuje kilka etapów — od utworzenia obiektu deweloperskiego typu Application, aż po implementację wewnętrznej klasy Java, w której definiowane są funkcje danej usługi sieciowej.

Projektowanie interfejsu usługi sieciowej

Interfejs programowalnej usługi sieciowej powinien zostać zaprojektowany zgodnie z określonymi wymaganiami technicznymi oraz biznesowymi.

Należy zwrócić uwagę, że infrastruktura dostępna w systemie do realizacji usług sieciowych nie jest przeznaczona do przetwarzania dużych ilości danych. Może wystąpić sytuacja, w której zarówno odebrane, jak i wysyłane dane muszą zostać w całości przetworzone w pamięci operacyjnej serwera aplikacji.

Takie działanie może prowadzić do istotnego obciążenia serwera aplikacji, a w konsekwencji — do wyraźnego spadku wydajności systemu.

Jeśli komunikaty są generowane w kolejce komunikatów podczas żądania klienta w ramach implementacji usługi sieciowej, nie są one automatycznie przekazywane z powrotem do klienta.

W przypadku, gdy zwrot tych komunikatów jest wymagany, to właśnie implementacja usługi sieciowej powinna zadbać o ich zwrócenie do klienta.

Tworzenie obiektów deweloperskich typu Java class i Application

Należy utworzyć obiekt programistyczny typu Java class. Zaleca się, aby:

• nazwa klasy Java była identyczna z nazwą aplikacji

• stosować przyrostek Service w nazwie klasy

Przestrzeń nazw powinna rozpoczynać się analogicznie jak odpowiednia przestrzeń nazw .log, jednak zakończenie powinno przyjmować postać .soap lub .rest, zamiast .log.

Utworzona klasa Java musi dziedziczyć po abstrakcyjnej klasie CisWebServiceApplication.
Nadklasa ta definiuje metodę init(), która stanowi punkt wyjścia do dalszej implementacji.

Dalszy przebieg implementacji zależy od rodzaju tworzonej usługi — SOAP lub REST.

W kolejnym kroku należy utworzyć obiekt programistyczny typu Application.

W pełni kwalifikowana nazwa tej aplikacji jest wykorzystywana do jednoznacznej identyfikacji usługi sieciowej:

• Typ aplikacji musi zostać ustawiony na usługa RPC (RPC service).

• W zależności od charakteru tworzonej usługi w polu Specjalne zastosowanie należy wybrać odpowiednio:

  • SOAP service

  • REST service

Jeśli do aplikacji ze specjalnym zastosowaniem usługa REST przypisana została klasa Java, w której zdefiniowano i zaimplementowano usługę SOAP — lub odwrotnie — to niezgodność ta zostanie wykryta dopiero podczas wywołania usługi, a następnie zostanie wygenerowany komunikat o błędzie.

URI żądania

Identyfikator URI żądania usługi sieci Web

Aby wywołać usługi sieciowe, należy wywołać oddzielny identyfikator URI specyficzny dla danej usługi sieciowej. Struktura tego identyfikatora URI jest następująca:

• dla usługi SOAP

https://<base-url>/services/soap/<w pełni kwalifikowana nazwa aplikacji>?oltp=<nazwa bazy danych>

Składnik services/soap identyfikatora URI żądania sygnalizuje serwerowi usługi sieci Web, że adresowana jest usługa SOAP.

• dla usługi REST

https://<base-url>/services/rest/<w pełni kwalifikowana nazwa aplikacji>/<zasoby>/<możliwe parametry>/?oltp=<nazwa bazy danych>

Składnik services/rest identyfikatora URI żądania sygnalizuje serwerowi usługi sieciowej, że adresowana jest usługa REST. Składnik <resource> adresuje żądaną funkcjonalność, która jest wywoływana z wymaganymi parametrami, jeśli to konieczne.

Ogólne parametry zapytania URI żądania

Można użyć następujących ogólnych parametrów zapytania:

W przypadku użycia kilku parametrów zapytania, są one oddzielone znakiem & lub średnikiem (;).

Tworzenie usługi SOAP

W utworzonej klasie Java musi znajdować się klasa wewnętrzna, oznaczona za pomocą adnotacji JAX-WS: @WebService

Adnotacja ta nie wymaga podawania żadnych wartości.

Klasa wewnętrzna pełni funkcję definicji i implementacji usługi SOAP. Nazwa tej klasy określa nazwę usługi w pliku WSDL.
Zaleca się, aby nazwa klasy wewnętrznej nie kończyła się przyrostkiem Service, aby uniknąć redundancji i niejednoznaczności w dokumentacji WSDL.

Wszystkie publiczne metody zaimplementowane w tej klasie wewnętrznej będą udostępnione klientowi SOAP jako funkcjonalne składniki usługi SOAP.

Dodatkowe informacje dotyczące JAX-WS, a w szczególności wykorzystania adnotacji @WebService, można znaleźć pod adresem:
http://cxf.apache.org/docs/developing-a-service.html

Przykład usługi SOAP

Udostępniona została aplikacja oraz odpowiadająca jej klasa Java:

com.cisag.app.system.webservices.service.soap.SOAPExampleService

Metoda init() zawiera inicjalizację wewnętrznego menedżera obiektów oraz menedżera transakcji.
Wewnętrzna klasa SOAPExample zawiera definicję i implementację usługi SOAP. Klasa ta oznaczona jest adnotacją @WebService.

Poniższa metoda umożliwia połączenie powitania Hello z wartością parametru name i zwrócenie go jako ciąg tekstowy:

String sayHello(String name)

Za pomocą poniższej metody można sprawdzić, czy istnieje zlecenie sprzedaży o określonym typie i numerze.

boolean existSalesOrder(String type, String number)

Poniższa metoda zwraca obiekt typu SalesOrderResult na podstawie zdefiniowanego typu i numeru zlecenia. Zwracany obiekt zawiera informacje o statusie zlecenia sprzedaży oraz odpowiedzialnym pracowniku.
Należy pamiętać, że obiekt typu SalesOrderResult musi zostać zaimplementowany jako statyczna klasa Java (static Java class):

public SalesOrderResult getSalesOrderByBusinessKey(String type, String number)

Wersja SOAP

Programowalne usługi SOAP domyślnie wykorzystują wersję SOAP 1.2 w pliku WSDL. Odpowiedzi SOAP są przesyłane w tej wersji protokołu, którą klient zastosował przy wysyłaniu żądania, czyli SOAP 1.1 lub SOAP 1.2.

Możliwe jest określenie, że dana usługa SOAP ma obsługiwać wyłącznie SOAP 1.1. W takim przypadku w pliku WSDL również zostanie użyta wersja SOAP 1.1. W tym celu należy dodać do klasy wewnętrznej następującą adnotację:

Należy pamiętać, że usługi sieciowe nieprogramowalne, opisane w artykule Interfejs usług sieciowych korzystają z wersji SOAP 1.1.

Stanowe usługi SOAP

Usługi SOAP mogą być również wywoływane w trybie stanowym. Dla każdej usługi wywoływanej w ramach sesji tworzona jest oddzielna instancja aplikacji wraz z powiązanym obiektem usługi. Kolejne wywołania tej samej usługi w tej samej sesji wykonywane są na już istniejącym obiekcie, co umożliwia zachowanie stanu między żądaniami.

Stan może być przechowywany za pomocą atrybutów zarówno w instancji aplikacji, jak i w obiekcie usługi. Dzięki temu możliwe jest przekazywanie danych lub kontekstu pomiędzy kolejnymi wywołaniami tej samej sesji.

Należy pamiętać, że sesje są automatycznie zamykane po określonym czasie bezczynności. Aby utrzymać sesję aktywną, konieczne jest wykonanie przynajmniej jednego wywołania dowolnej usługi sieciowej w obrębie tej samej sesji przed upływem czasu oczekiwania.

W tym celu system udostępnia także metodę podtrzymującą sesję – bezparametrową metodę ping(), dostępną w usłudze SOAP:

com.cisag.sys.tools.webservices.log.Session

Tworzenie usługi REST

W przechwyconej klasie Java musi znajdować się klasa wewnętrzna, która oznaczona jest następującą adnotacją JAX-RS:

@Path("W pełni kwalifikowana nazwa aplikacji REST")

Adnotacja ta wymaga jako wartości w pełni kwalifikowanej nazwy przechwyconej aplikacji, dla której ustawiono typ usługa RPC oraz specjalne zastosowanie usługa REST.

Podana nazwa reprezentuje zasób główny (root resource), który stanowi wymagany składnik URI żądania dla usługi REST.

Dodatkowo, klasa wewnętrzna musi posiadać publiczny konstruktor.

Funkcjonalności usługi REST, które są dostępne dla klienta REST, reprezentowane są przez publiczne metody klasy (tzw. metody zasobów), oznaczone adnotacjami JAX-RS. Stosowane są następujące adnotacje:

• Request-Method Designator:
  @GET, @PUT, @POST, @DELETE

• @Path("Nazwa zasobu i opcjonalne parametry")
  Adnotacja @Path określa ścieżkę dostępu do zasobu i może zawierać parametry dynamiczne zapisane jako symbole zastępcze w nawiasach klamrowych (np. {Id}).

Wartości przypisane do adnotacji @Path tworzą dodatkowe składniki URI żądania, które są względne względem zasobu głównego (root resource).

Podczas programowania metod zasobów należy przestrzegać następujących zasad w odniesieniu do operacji HTTP:

• GET – służy do pobierania reprezentacji zasobu. Zgodnie z zasadami REST, żądania typu GET nie powinny wywoływać żadnych efektów ubocznych.
• POST – umożliwia dodanie danych do zasobu. W przeciwieństwie do metody GET, POST nie jest wolna od efektów ubocznych.
• PUT – umożliwia tworzenie nowych zasobów lub zastępowanie zawartości już istniejących zasobów.
• DELETE – umożliwia usunięcie zasobów.

Należy również zwrócić uwagę na poniższy opis JAX-RS:

Java™ API for RESTful Web Services http://jsr311.java.net/nonav/releases/1.1/spec/spec.html

W komentarzach do metod zasobów można znaleźć informacje o tym, jak można wywołać funkcjonalność usługi REST. Wszystkie funkcje oznaczone operacją HTTP GET można wywołać bezpośrednio w przeglądarce. Narzędzie Soap UI może być używane do innych operacji HTTP.

Przykład usługi REST

Udostępniono aplikację i klasę Java o tej samej nazwie:

com.cisag.app.system.webservices.service.rest.RESTExampleService

Metoda init() zawiera inicjalizację obiektu i menedżera transakcji. Wewnętrzna klasa RESTExample zawiera definicję i implementację usługi REST. Klasa charakteryzuje się adnotacją:

@Path("com.cisag.app.system.webservices.service.rest.RESTExampleService")

Udostępniana jest metoda zasobu, która konkatenacją słowa powitania Hello z podaną nazwą parametru zwraca reprezentację jako zwykły tekst:

@GET
@Path("sayhello/{nazwa}")
public String sayHello(@PathParam("Name") String name)

Adnotacja @GET wskazuje, że do żądania wykorzystywana jest metoda HTTP GET. Adnotacja @Path zawiera wartość sayhello/{Name}, gdzie sayhello to identyfikacja funkcjonalności, a {Name} to wymagany symbol zastępczy. Symbol ten jest powiązany z parametrem metody zasobu Name przez adnotację @PathParam(„Name”).

Dostępna jest również metoda zasobu umożliwiająca sprawdzenie, czy istnieje zamówienie sprzedaży o określonym typie i numerze:

@GET
@Path("salesOrderAvailable/{Type}/{Number}")
public String existSalesOrder(@PathParam("Type") String type, @PathParam("Number") String number)

Kolejna metoda zasobu zwraca instancję SalesOrderBean na podstawie zdefiniowanego typu i numeru. Instancja zawiera informacje o typie, numerze, statusie zlecenia sprzedaży oraz nazwisku odpowiedzialnego pracownika:

@GET
@Path("getSalesOrder/{Type}/{Number}")
@Produces(MediaType.APPLICATION_XML)
public SalesOrderBean getSalesOrderByBusinessKey(@PathParam("Type") String type, @PathParam("Number") String number)

Adnotacja @Produces wskazuje, że reprezentacja zwracana jest w postaci XML. Klasa fasoli obsługującej JAXB oznaczona jest adnotacją:

@XmlRootElement(name = "SalesOrderBean")

Udostępniona jest także metoda zasobu tworząca nową instancję SalesOrderBean w pamięci roboczej na podstawie określonego typu, numeru i statusu. Zwracana jest reprezentacja w postaci 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 zapisywana. W odróżnieniu od pozostałych metod zasobów, metoda ta wykorzystuje adnotację @POST.

Pobieranie pliku WSDL/WADL

Plik WSDL lub WADL jest wymagany do opracowania klienta usługi sieci Web. Struktura odpowiedniego identyfikatora URI żądania jest następująca:

• dla usług SOAP:

https://<basis-uri>/services/soap/<w pełni kwalifikowana nazwa aplikacji>?wsdl

Składnik URI żądania wsdl sygnalizuje serwerowi usług internetowych, że plik WSDL musi zostać przygotowany i udostępniony. Po wprowadzeniu identyfikatora URI żądania w pasku adresu przeglądarki pojawia się okno dialogowe uwierzytelniania. Po pomyślnym uwierzytelnieniu wyświetlony zostanie plik WSDL. Można go zapisać za pomocą akcji Zapisz jako… w przeglądarce.

• dls usług REST:

https://<base-url>/services/soap/<w pełni kwalifikowana nazwa aplikacji>?_wadl

Składnik URI żądania _wadl sygnalizuje serwerowi usług internetowych, że plik WADL musi zostać przygotowany i udostępniony. Po określeniu identyfikatora URI żądania na pasku adresu przeglądarki wyświetlane jest okno dialogowe uwierzytelniania. Po pomyślnym uwierzytelnieniu pojawi się okno dialogowe pobierania pliku. Plik WADL można zapisać. 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.

Uwierzytelnianie i autoryzacja

Aby móc wywołać usługę internetową, klient musi uwierzytelnić się na serwerze internetowym. Uwierzytelnianie odbywa się za pomocą uwierzytelniania hasła lub certyfikatu klienta. W opisie przykładowego klienta w rozdziale Przykładowy klient usługi SOAP uwierzytelnianie odbywa się za pomocą certyfikatu klienta.

Programowalne usługi sieciowe są aplikacjami. Dlatego użytkownik musi mieć uprawnienia do otwarcia aplikacji, aby móc wywołać usługę sieciową.

Wsparcie dla rozwiązywania problemów

Serwer systemu usług internetowych umożliwia wyświetlanie informacji o żądaniach pochodzących od klientów. Dotyczy to zarówno usług sieciowych nieprogramowalnych, jak i programowalnych.

W tym celu należy aktywować debugowanie klasy Java com.cisag.sys.kernel.webservices.CisWebServicesResource na serwerze SAS, do którego kierowane są żądania klientów. W zależności od poziomu debugowania, w Toolshell pojawiają się następujące komunikaty:

Wyświetlanie komunikatów może być włączane i wyłączane dla działającego SAS-a za pomocą polecenia powłoki narzędziowej debugowanie klasy (dbgcls).

Przykłady klientów usług sieciowych

Przykładowy klient usługi SOAP

Udostępniony został następujący przykład klienta usługi SOAP. Klient ten sprawdza, czy zamówienie sprzedaży istnieje. Poniższa klasa zawiera rzeczywistą implementację klienta:

com.cisag.app.system.webservices.service.soap.client.SOAPExampleClient

Następujące klasy są również wymagane do programowania klienta:

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 są generowane z pliku WSDL przez narzędzie wsimport. Narzędzie wsimport jest częścią JDK.

Plik WSDL jest generowany przez następującą specyfikację:

https://<basis-uri>/services/soap/com.cisag.app.system.webservices.service.soap.SOAPExampleService?wsdl

Rzeczywisty adres jest określany zamiast symbolu zastępczego <base-uri>.

Narzędzie wsimport jest następnie wywoływane w następujący sposób poniżej <katalogu 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 symboli zastępczych „ścieżka” określane są rzeczywiste ścieżki.

Poniższa klasa zawiera ścieżkę do pliku WSDL po wygenerowaniu:

com.cisag.app.system.webservices.service.soap.client.SOAPExampleService

Ścieżka ta jest zastępowana następującym identyfikatorem URI

<basis-uri>/services/soap/com.cisag.app.system.webservices.service.soap.SOAPExampleService?wsdl&oltp=<oltpname>

Poniższa klasa zawiera główną metodę, w której odbywa się sprawdzanie parametrów:

com.cisag.app.system.webservices.service.soap.client.SOAPExampleClient

W tej metodzie wykonywane są następujące czynności:

• tworzona jest instancja SOAPExampleService
• tworzony jest obiekt usługi
• przeprowadzane jest uwierzytelnianie
• wywoływana jest metoda usługi SOAP existSalesOrder(salesOrderType, salesNumber).

Klient musi zostać wywołany poza systemem w następujący sposób:

com.cisag.app.system.webservices.service.soap.client.SOAPExampleClient SOAPServiceAddress userCertificateFileName userCertificate-FilePassword serverCertificateFileName salesOrderType salesNumber

Zamiast SOAPServiceAddress wprowadź pełny adres usługi SOAP, w tym nazwę bazy danych OLTP, np. https://qas.kauftreu.com/services/soap/com.kauftreu.app.system.webservices.service.soap.SOAPExampleService?oltp=QAS61000.

Zamiast salesOrderType i salesNumber należy wpisać typ zamówienia sprzedaży i jego numer.

Zamiast userCertificateFileName i serverCertificateFileName wprowadź pełną ścieżkę i nazwę pliku JKS.

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óre zostało opisane w rozdziale Narzędzie SOAP UI do testowania usług sieciowych.

Narzędzie SOAP UI do testowania usług sieciowych

Narzędzie SOAP UI umożliwia testowanie zarówno usług SOAP, jak i REST.

Ustawienia Soap Ui

Przed przystąpieniem do testowania usługi sieciowej konieczne jest posiadanie pliku WSDL (dla usług SOAP) lub WADL (dla usług REST). Wymagany jest również plik JKS zawierający certyfikat użytkownika, który służy do uwierzytelniania, oraz odpowiadające mu hasło dostępu.

Certyfikat użytkownika musi być przypisany do konta użytkownika, które wykonuje testy danej usługi sieciowej. Ścieżkę do pliku JKS oraz hasło należy skonfigurować w sekcji SSL Settings w oknie dialogowym SoapUI Preferences.

Zalecenie:

Zaleca się ustawienie wartości 120000 dla opcji Socket Timeout w sekcji HTTP Settings.

Okno dialogowe SoapUI Preferences można otworzyć na dwa sposoby:

• za pomocą skrótu klawiaturowego CTRL + ALT + P

• wybierając z menu górnego opcję File → SoapUI Preferences

Nowy projekt SOAP UI

Po wprowadzeniu ustawień SoapUI należy utworzyć nowy projekt SoapUI, naciskając kombinację klawiszy CTRL + N lub wybierając pozycję New SoapUI Project z menu File. Pojawi się okno dialogowe, w którym należy wprowadzić nazwę projektu oraz ścieżkę do pliku WSDL lub WADL. Po naciśnięciu przycisku [OK] tworzony jest projekt o strukturze hierarchicznej. Poszczególne węzły reprezentują całą usługę sieciową lub jej poszczególne funkcjonalności, bądź operacje HTTP (dotyczy tylko usług REST).

Należy pamiętać, że nazwy ogólnych parametrów zapytań (np. oltp lub context) nie są częścią pliku WSDL ani WADL. Parametry te należy wprowadzić ręcznie:

• W przypadku usługi SOAP należy rozwinąć węzły odpowiadające funkcjonalnościom przeznaczonym do testowania, aż będzie możliwe przejście do węzła Request<number>. Następnie należy zaznaczyć pasek adresu w oknie dialogowym, wybrać opcję [edit current…] i dodać żądany parametr do URI.

• W przypadku usługi REST należy rozwinąć węzeł zawierający nazwę usługi internetowej (powinna to być nazwa aplikacji wprowadzona w systemie), a następnie kliknąć go dwukrotnie. Pojawi się okno dialogowe, w którym można dodać dodatkowe parametry.

Aby uzyskać dostęp do usługi internetowej, należy rozwinąć węzły odpowiadające funkcjom przeznaczonym do testowania, aż możliwe będzie przejście do węzła Request<number>. Kliknięcie tego węzła spowoduje wyświetlenie okna dialogowego, w którym można wysyłać żądania do usługi sieciowej oraz przeglądać odpowiedzi tej usługi.