Interfejs usług sieciowych

Usługi sieciowe to interfejsy do zdalnego wywoływania funkcji. Należą one do tej samej kategorii interfejsów co CORBA.

Comarch ERP Enterprise oferuje interfejs usług sieciowych z łączem do Business Integration Service (BIS) na potrzeby funkcji eksportu i importu danych. Dzięki temu jednostki biznesowe (Business Entitys) mogą być eksportowane do aplikacji klienckiej lub importowane z niej za pomocą usług sieciowych. Ponadto istnieje możliwość wywoływania aplikacji w tle poprzez interfejs usług sieciowych. Niniejszy dokument zawiera opis usług sieciowych.

Użytkownik może programować własne usługi sieciowe, które do zdalnych wywołań funkcji wykorzystują protokół SOAP lub realizują reguły REST. Szczegółowe informacje znajdują się w dokumencie Interfejs dla programowalnych usług sieciowych.

W przeciwieństwie do interfejsu CORBA, interfejs usług sieciowych nie został stworzony do przesyłania dużych ilości danych lub do krótkich czasów reakcji, ale z myślą o możliwie jak najprostszej obsłudze dla klientów, którzy nie znają skomplikowanych logik lub protokołów.

Interfejs usług sieciowych wykorzystuje ogólnie dostępną bibliotekę usług sieciowych Apache Axis dla usług sieciowych, które nie są programowalne. Axis można również wykorzystać do implementacji klientów w Java. Szczegółowe informacje o Axis dostępne są na stronie:

http://ws.apache.org/axis/

Comarch ERP Enterprise posiada klientów przykładowych zarówno dla Java, jak również dla „Microsoft.Net”. Obsługa dla klientów Java oparta jest na Axis, natomiast klienci „Microsoft.Net” realizowani są w formie arkusza Microsoft Excel z przynależnym kodem C#. Opis klientów przykładowych znajduje się w rozdziale 6.

Z uwagi na złożoność funkcjonalności zaleca się używanie usług sieciowych przez programistów lub doradców technicznych.

Definicje pojęć

WSDL – web Services Description Language, język opisu dla interfejsu usługi sieciowej.

SOAP – simple Object Access Protocol. Protokół oparty na XML przeznaczony do wymiany wiadomości w systemach rozproszonych. SOAP jest wykorzystywana do komunikacji pomiędzy klientami a serwerami serwisów sieciowych.

Opis

Nieprogramowalne usługi sieciowe

Comarch ERP Enterprise oferuje cztery usługi sieciowe, których nie można programować. Usługi te wykorzystują do połączeń zdalnych protokół SOAP. Z jednej strony są to specjalistyczne usługi sieciowe: eksport i import danych oraz zdalne wyszukiwanie. Z drugiej strony istnieje możliwość uruchomienia dowolnych aplikacji w tle.

Wywołanie aplikacji w tle

Każdą z aplikacji w tle można wywołać za pomocą tej usługi sieciowej. Aplikacje mogą być jednak wywołane tylko bez statusu (CallApplication). Inaczej niż w przypadku COBRA, gdzie możliwe jest wywołanie aplikacji w konkretnym stanie (RunApplication).

Eksport danych

Ta usługa sieciowa może być wykorzystywana do eksportu danych jednostki biznesowej (dostępna w aplikacji Eksport danych). Filtr ustawiony w Comarch ERP Enterprise określa liczbę eksportowanych atrybutów i rekordów danych. Klient zewnętrzny może wtedy wywołać ten eksport i jako odpowiedź otrzyma atrybuty ustawione w filtrze.

Import danych

Ta usługa sieciowa może być wykorzystywana do importu danych dla jednostki biznesowej (dostępna w aplikacji Import danych). Filtr ustawiony w Comarch ERP Enterprise określa liczbę importowanych atrybutów. Klient zewnętrzny może wywołać ten import, po czym zwracany jest wynik procesu importu oraz wszelkie nieprawidłowe rekordy danych.

Zdalne wyszukiwanie

Ta usługa sieciowa może być wykorzystywana do wyszukiwania poszczególnych rekordów danych jednostki biznesowej. W zależności od wyszukiwania OQL zapisanego w Comarch ERP Enterprise parametry wysyłane są do serwera, który następnie zwraca znalezione rekordy danych.

Wywołanie usługi sieciowej

Wywołanie usługi sieciowej odbywa się poprzez API, które musi być wygenerowane specjalnie dla wybranej usługi sieciowej. Aby była możliwość wygenerowania API, każda usługa sieciowa udostępnia opis swoich parametrów i wartości wynikowych w formie WSDL. WSDL musi następnie zostać przekształcone w odpowiednie API. Służy do tego narzędzie dostępne w Comarch ERP Enterprise. To API jest następnie wykorzystywane przez klienta do wywołanie usługi sieciowej.

Usługi sieciowe mogą być wywołane przez dowolnego klienta w dowolnym języku programowania. Comarch ERP Enterprise wspiera tylko klientów utworzonych w Java i .NET. Wszystkie inne formy klientów mogą wymagać dodatkowych instrumentów. Poniżej jako przykład przedstawiono API klienta Axis 1 dla języka Java.

API klienta

Każda usługa sieciowa składa się z dwóch interfejsów: interfejs lokalizatora (Locator) i interfejs usługi sieciowej (Web Service). Interfejs Locator odpowiada Factory, a interfejs usługi sieciowej Proxy.

Interfejs Locator jest wykorzystywany na kliencie w formie klasy implementującej. Klasa ta nosi nazwę usługi sieciowej plus dodatek Locator. Najważniejsze metody interfejsu Locator są trzy metody GET, które można wykorzystać do uzyskania dostępu do adresu usługi sieciowej i proxy dla usługi sieciowej.

Obiekt proxy zawiera jedną metodę dla każdej operacji usługi sieciowej. Każda metoda otrzymuje jako parametr obiekt typu Request. Jest on charakterystyczny dla wybranej usługi sieciowej, wybranej operacji oraz ew. dla wybranej bazy danych OLTP i wybranego filtra. To samo dotyczy wartości wynikowej typu Response. Obiekt typu Response otrzyma następnie dane wygenerowane przez aplikację w tle.

W tabeli poniżej znajduje się zestawienie metod:

Obsługa błędów przy wywoływaniu usługi sieciowej

W przypadku wywoływania usług sieciowych wymagana jest stopniowana obsługa błędów. Typowe wywołanie usługi sieciowej przebiega następująco:

try {
    Response response= service.process(request);
    Result result = response.getResult();
    if(result != null) {
        // application specific interpretation of results.
    }
    MessageQueue mQueue = response.getMessageQueue();
    // interpret or print messages from queue
}
catch (RemoteException ex) {
    // technical problem with the service
}

Wystąpienie wyjątku podczas wywoływania usługi sieciowej ma przyczynę techniczną. Wśród możliwych przyczyn są błędy przesyłu danych lub błędy w składni danych XML. Jeśli nie wystąpią żadne błędy techniczne, wówczas zostanie zwrócony obiekt Response. W przypadku wystąpienia błędów w wywoływanej usłudze sieciowej, obiekt Response nie będzie zawierał żadnego obiektu Result. Jeśli więc response.getResult() zwraca wartość zero, oznacza to błąd w wywołanej usłudze sieciowej. Jeśli istnieje obiekt Result, konieczna jest dalsza interpretacja wyników, w celu wykrycia ewentualnych błędów podczas opracowywania danych. Na przykład wywołanie usługi importu może zwrócić rekordy danych, które nie spełniają wymogów weryfikacji właściwych dla jednostek biznesowych. W każdym z przypadków obiekt Response otrzyma obiekt MessageQueue. Dlatego nie jest możliwe, aby wywołanie metody response.getMessageQueue() zwróciło wartość zero. Samo MessageQueue może być jednak puste, to znaczy, może nie zawierać żadnych obiektów Message. Jeśli obiekt Response ma wartość zero, to obiekt MessageQueue zawsze zawiera przynajmniej jeden obiekt Message.

Parametry API usług sieciowych

Poniżej opisane zostały parametry usług sieciowych określanych za pomocą API. Inne parametry są określane nie poprzez API, ale za pomocą URI zapytania (patrz rozdział Zapytanie URI dla usług sieciowych)

CallApplication

Usługa sieciowa CallApplication wywołuje metodę RUN dla aplikacji w tle. Możliwe jest określenie przez klienta parametrów metody RUN podczas wywoływania usługi sieciowej. Po stronie klienta przekazywana jest nazwa kwalifikowana aplikacji w tle, akcja do wywołania oraz tablicę (Array) obiektów ParameterListEntry. Przy czym obiekty ParameterListEntry odpowiadają parametrom aplikacjom w tle.

Wynik wywołanej aplikacji w tle jest zwracany do usługi sieciowej CallApplication. Również w formie tablicy obiektów ParameterListEntry.

Należy pamiętać, że usługa sieciowa CallApplication obsługuje tylko typy danych, które zostały wymienione poniżej. Dotyczy to parametrów wywołania u wartości wynikowych. Nie można poprawnie wywołać aplikacji w tle, które wykorzystują inne typy danych.

Klasa ParameterListEntry

Każdy ParameterListEntry posiada nazwę, typ i wartość. Przy czym wartość musi odpowiadać typowi. Typ jest definiowany jako stała z klasy ParameterListEntryType.

Podczas tworzenia obiektu ParameterListEntry zawsze należy podać nazwę, typ i wartość. Można stosować jeden z dwóch konstruktorów. Najprostsze jest zastosowanie domyślnego konstruktora (bez parametrów), wtedy jednak należy ustawić nazwę, typ i wartość za pomocą odpowiedniej metody set.

Klassa ParameterListEntryType

Dla tego typu danych dostępne są następujące stałe:

BYTE_ARRAY_STRING może być zastosowane dla parametrów aplikacji w tle GUID i Binary. Jako wartość na kliencie usługi sieciowej podawany jest szesnastkowy ciąg numeru GUID lub byte[].

W rozdziale CallApplication znajduje się przykład zastosowania różnych typów danych.

Import

Istnieją dwie specjalne klasy parametrów dla importu. Są one generowane na podstawie WSDL. W celu uruchomienia procesu importu należy wygenerować obiekt ImportRequest, odpowiedź importu jest zawarta w obiekcie ImportResponse.

Filtr

Dla importu należy zastosować filtr dodany w systemie Comarch ERP Enterprise. Jest on określany w adresie URI dla żądania usługi.

WSDL usługi zależy od zastosowanego filtra. Dlatego filtr należy wskazać również podczas wywoływania WSDL. Każdorazowo po zmianie filtra należy ponownie pobrać WSDL i ew. wygenerować nowe klasy po stronie klienta.

Struktura wywoływania dla importu

Podczas generowania obiektu Request należy określić wszystkie parametry importu.

Konstruktor ImportRequest(…)

Służy do generowania obiektu ImportRequest z odpowiednimi parametrami:

• WarningsMode warningsMode – określa obsługę ostrzeżeń pojawiających się podczas importu
  • Ostrzeżenia z wartością CONFIRM_NONE powodują błędy importu i są zapisywane do pliku błędów
  • Ostrzeżenia z wartością CONFIRM_ALL są ignorowane

• CorrectionMode correctionMode – określa, czy w Comarch ERP Enterprise mają zostać poprawione nieprawidłowe dane.

Wartość NONE oznacza brak korekty w Comarch ERP Enterprise. Nieprawidłowe dane zostaną przekazane do klienta w obiekcie Reponse-Object.

Wartość WORKFLOW oznacza, że korekta ma zostać wykonana w Comarch ERP Enterprise po powiadomieniu poprzez workflow. Nieprawidłowe dane nie zostaną przekazane do klienta, ale zapisane w formie pliku błędów w systemowym repozytorium wiedzy w folderze kstore://<Arbeitsbereich>/Import/ RemoteErrorFiles. Jako obszar roboczy stosowany jest domyślny obszar roboczy bazy danych, do której dane zostały zaimportowane.

• EntityWrapper importData – obiekt Wrapper zawiera dane do zaimportowania.

Konstruktor EntityWrapper( … )

• Title[] title – tablica rekordów danych do zaimportowania
• Message[] _message – nieużywane. Zaleca się przeniesienie wartości null.

Struktura wartości zwracanych dla importu

Po skutecznym wywołaniu importu zwracany jest obiekt ImportResponse, z którego można odczytać odpowiednie wartości za pomocą metod get.

Klasa ImportResponse

Dostępne metody:

• ImportResult getResult() – zwraca obiekt Result, może mieć wartość null
• MessageQueue getMessageQueue() – zwraca MessageQueue

Klasa ImportResult

Dostępne metody:

• int getImportedObjectCount() – zwraca liczbę poprawnie zaimportowanych rekordów danych
• int getInvalidObjectCount() – zwraca liczbę niezaimportowanych rekordów danych, które mogą być poprawione
• int getNotCorrigibleObjectCount() – zwraca liczbę niezaimportowanych rekordów danych, których nie można poprawić
• boolean isHasErrorFile() – jeśli metoda zwraca wartość true, wówczas zwracane są błędne rekordy danych
• EntityWrapper getErrorData() – zwraca obiekt EntityWrapper

Klasa EntityWrapper

• Title[] getTitle() – zwraca nieprawidłowe rekordy danych, których nie można zaimportować. W przypadku braku nieprawidłowych danych metoda zwraca wartość null.
• MessageQueue getMessageQueue() – zwraca MessageQueue, w której mogą znajdować się komunikaty

Eksport

Istnieją dwie specjalne klasy parametrów dla importu. Są one generowane na podstawie WSDL. W celu uruchomienia procesu eksportu należy wygenerować obiekt Request, odpowiedź eksportu zawarta jest w obiekcie Response.

Filtr

Dla eksportu należy zastosować filtr dodany w systemie Comarch ERP Enterprise. Jest on określany w adresie URI dla żądania usługi.

Wskazówki odnoszące się do filtrów importu mają również zastosowanie dla eksportu.

Struktura wywoływania dla eksportu

Podczas generowania obiektu ExportRequest należy określić wszystkie parametry eksportu.

Konstruktor ExportRequest(…)

Generuje obiekt ExportRequest z odpowiednimi parametrami:

Parametry-Opis

• String dynamicOQLSearch – instrukcja OQL pozwalająca ograniczyć eksportowane rekordy danych. Szczegółowe informacje o strukturze aplikacji OQL znajdują się w dokumencie Eksport danych Jeśli zamiast instrukcji OQL będzie zastosowane wyszukiwanie OQL, należy wprowadzić w tym miejscu pusty ciąg.
• String searchName – pełna nazwa wyszukiwania OQL. Jeśli zamiast wyszukiwania OQL będzie zastosowana instrukcja OQL, należy wprowadzić w tym miejscu pusty ciąg.
• ParameterListEntry[] searchParameters – parametry wyszukiwania do ograniczania wyników za pomocą wyszukiwania OQL. Wartość to tablica z wpisami, które zawierają po jednym parametrze wyszukiwania. Nazwa parametru odpowiada nazwie pola wyszukiwania z wyszukiwania OQL, wartością parametru jest natomiast Selection String. Należy określić te parametry wyszukiwania, które mają być zastosowane do ograniczania wyników wyszukiwania.

W przypadku ograniczania za pomocą instrukcji OQL ten parametr nie jest wykorzystywany.

• String searchSortOrder – sortowanie eksportowanych instancji dla ograniczenia za pomocą wyszukiwania OQL. Wartością domyślną jest sortowanie domyślne wprowadzone dla wyszukiwania QOL. Składnia sortowania została opisana w dokumencie Interfejsy programistyczne do wymiany danych, w rozdziale Format funkcji sortowania. W przypadku ograniczania za pomocą instrukcji OQL ten parametr nie jest wykorzystywany.

Struktura wartości zwracanych dla eksportu

Po skutecznym wywołaniu eksportu zwracany jest obiekt ExportResponse, z którego można odczytać odpowiednie wartości za pomocą metod get.

Klasa ExportResponse

Dostępne metody:

• int getExportedObjectCount() – zwraca liczbę wyeksportowanych rekordów danych
• Title[] getExportData() – zwraca tablicę wszystkich wyeksportowanych rekordów danych
• MessageQueue getMessageQueue() – zwraca MessageQueue, w której mogą znajdować się komunikaty

Search

Usługa sieciowa Search zawiera obie operacje Wyszukaj i Sprawdź występowanie. O ile podczas wyszukiwania w zbiorze wyników można znaleźć szereg rekordów danych, operacja Sprawdź występowanie będzie zawierać jedynie rekord danych, który ma zostać sprawdzony. Jeśli parametry określone w operacji Sprawdź występowanie odpowiadają wielu rekordom danych w bazie, to mimo to zwrócony zostanie tylko jeden rekord danych.

Dla usługi sieciowej Search dostępne są trzy specjalne klasy parametrów. Są one generowane na podstawie WSDL. W celu uruchomienia wyszukiwania należy wygenerować obiekt SearchRequest lub SearchExist, odpowiedź usługi jest zawarta w obiekcie SearchResponse.

Struktury wywoływania dla wyszukiwania

Podczas generowania obiektu SearchRequest lub SearchExistRequest należy określić wszystkie parametry wyszukiwania.

Klasa SearchRequest(…)

Generuje obiekt SearchRequest z odpowiednimi parametrami:

• String searchName – w pełni kwalifikowana nazwa wyszukiwania OQL, które ma być wykonane na wskazanej bazie danych
• ParameterListEntry[] searchParameters – wartości parametrów dla wskazanego wyszukiwania OQL (opcjonalne)
• String searchSortOrder – sortowanie eksportowanych instancji dla ograniczenia za pomocą wyszukiwania OQL. Wartością domyślną jest sortowanie domyślne wprowadzone dla wyszukiwania QOL. Składnia sortowania została opisana w dokumencie Interfejsy programistyczne do wymiany danych, w rozdziale Format funkcji sortowania.
• String database – alias bazy danych Należy zastosować dane z wygenerowanej klasy Database
• pageSize – określa maksymalną liczbę rekordów danych, które mają zostać przekazane do klienta
• SearchFormat searchParametersFormat – określa format, w którym mają być podawane parametry wyszukiwania. Należy zastosować dane z wygenerowanej klasy SearchFormat.
• SearchFormat searchResultFormat – Określa format atrybutów zwracanych w wynikach wyszukiwania. Należy zastosować dane z wygenerowanej klasy SearchFormat.

Klasa SearchExistRequest(…)

Dostępne parametry:

Parametry-Opis

• String searchName – w pełni kwalifikowana nazwa wyszukiwania OQL, które ma być wykonane na wskazanej bazie danych
• ParameterListEntry[] searchParameters – wartości parametrów dla wskazanego wyszukiwania OQL (opcjonalne)
• String database – alias bazy danych Należy zastosować dane z wygenerowanej klasy Database.
• SearchFormat searchParametersFormat – określa format, w którym mają być podawane parametry wyszukiwania. Należy zastosować dane z wygenerowanej klasy SearchFormat.

Struktury zwracanych wartości dla wyszukiwania

Po skutecznym wywołaniu wyszukiwania zwracany jest obiekt SearchResponse, z którego można odczytać odpowiednie wartości za pomocą metod get.

Klasa SearchResponse

Dostępne metody:

• SearchResult getResult() – zwraca obiekt SearchResult zawierający wyniki wyszukiwania. Może mieć wartość null.
• MessageQueue getMessageQueue() – zwraca MessageQueue, które może zawierać komunikaty

Klasa SearchResult

Dostępne metody:

• int getCurrentObjectCount() – wskazuje liczbę zwracanych rekordów danych.
• String getContent() – zwraca rekordy danych w formie ciągu zawierającego plik XML zakodowany w UTF8

Komunikaty dla zwracanych wartości

Klient usługi sieciowej otrzymuje z serwera usług sieciowych nie tylko wyniki wywoływania, ale może również otrzymywać szereg komunikatów, np. o wystąpieniu błędów. Są one dostarczane do klienta w formie specjalnej struktury danych składającej się z klas MessageQueue i Message.

Wszystkie obiekty Message wysyłane przez serwer do klienta są zestawione w obiekcie MessageQueue. Każdy obiekt Message zawiera z kolei obiekt MessageSeverity opisujący typ komunikatu (błąd, ostrzeżenie, informacja itd.).

Uwierzytelnienie

Zarówno klient usług sieciowych musi zostać uwierzytelniony dla serwera usług sieciowych, jak i serwer usług sieciowych dla klienta usług sieciowych.

Axis wspiera tylko uwierzytelnianie BASIC i uwierzytelnianie przy użyciu certyfikatów. Comarch ERP Enterprise obsługuje tylko uwierzytelnianie DIGEST oraz uwierzytelnianie przy użyciu certyfikatów. Dlatego klient usługi sieciowej może komunikować się z serwerem Comarch ERP Enterprise dla usług sieciowych tylko za pomocą uwierzytelniania przez certyfikaty.

Klient usługi sieciowej potrzebuje certyfikatu serwera do weryfikacji serwera usług internetowych oraz certyfikatu użytkownika na potrzeby własnej identyfikacji. Certyfikat użytkownika musi zawierać klucz prywatny i dlatego najczęściej jest zapisywany w postaci pliku „.pfx” lub „.jks”, chronionym hasłem (Java 1.5 obsługuje tylko pliki „.jks” bez dodatkowych bibliotek.)

Przykłady programowania klienta usługi sieciowej znajdują się w rozdziale Programowanie klienta usługi sieciowej.

Obszary nazw XML

Klient usługi sieciowej jest tworzony na podstawie WSDL danej usługi sieciowej. To WSDL definiuje jeden lub wiele obszarów nazw. Definiowany jest przynajmniej obszar nazw XML dla samego wywołania usługi sieciowej razem z domyślnymi parametrami. Jeśli wymagane są jeszcze dodatkowe dane, np. w przypadku zdalnej usługi sieciowej, wówczas definiowany jest jeszcze obszar nazw dla typów danych dodatkowych oraz obszar nazw XML danych.

Te obszary nazw XML są również odwzorowane w klasach Java wygenerowanych z WSDL. Zasadniczo obszary nazw XML języka WSDL skutkują powstaniem obszarów nazw klasy Java, które niekoniecznie są oczekiwane. Dlatego istnieje też możliwość odwzorowania tych obszarów nazw w dowolnych obszarach nazw Java podczas generowania klas Java. Szczegółowe parametry tego odwzorowania można znaleźć w rozdziale Generowanie plików źródłowych Java z WSDL.

Obszarom nazw XML nadawane są następujące klasy:

• obszar nazw XML common

Klasy należące do obszaru nazw XML common są stosowana przez usługę sieciową CallApplication oraz wspólnie przez wszystkie usługi sieciowe. Klasy wygenerowane dla tego obszaru nazw XML:

CallApplication
CallApplicationLocator
CallApplicationRequest
CallApplicationResponse
CallApplicationService
CallApplicationSoapBindingStub
Message
MessageQueue
MessageSeverity
ParameterListEntry
ParameterListEntryType

• obszary nazw XML Eksport/Baza danych/Filtry, Import/Baza danych/<Filtry>, Search

Wszystkie opisy klas dla danych użytkowych usługi sieciowej Export, Import i Search znajdują się w ich odpowiednim oddzielnym obszarze nazw XML.

• obszary nazw XML Eksport/<Baza danych>/<Filtry>/data oraz Import/<Baza danych>/<Filtry>/data.

Wszystkie opisy klas dla danych użytkowych usługi sieciowej Export lub Import znajdują się w oddzielnym obszarze nazw XML. To, jakie klasy będą generowane, zależy m.in. od wybranej jednostki biznesowej (business entity), bazy danych OLTP oraz ustawień filtra.

Instrukcje

W tym rozdziale opisano sposób tworzenie klienta usług sieciowych w języku Java przy użyciu biblioteki klienta Axis 1. Zastosowano usługę eksportu.

Generowanie WSDL

Dla każdej usługi sieciowej można wykonać zapytanie o przynależne WSDL. Wystarczy wpisać w przeglądarce URI w następującej formie:

https://<server>:<port>/webservices/<service>?wsdl;oltp=<oltp>;filter=<filter>;oltpMode=<oltpMode>

Wymagane parametry:

Parametry-Opis

• server – adres serwera aplikacji systemu ERP, do którego jest wysyłane zapytanie
• port – port usługi sieciowej zapytania. Wartość domyślna to 443.
• service – identyfikator usługi sieciowej zapytania. Dostępne wartości:
  • CallApplication
  • Import
  • Export
  • Search
• Oltp – identyfikator bazy danych OLPT, na której loguje się klient (browser), aby wykonać zapytanie o WSDL
• Filter – identyfikator filtra, który ma być zastosowany do określenia WSDL
• oltpMode – tryb OLPT. Określa, czy nazwa bazy danych OLTP powinna być zawarta w obszarze nazw usługi sieciowej. Dostępne wartości:
  • oltp – po wybraniu tej wartości w obszarze nazw pojawi się nazwa bazy danych OLTP, a wygenerowane WSDL może zostać zastosowane na aktualnym systemie i dla podanej bazy OLTP.
  • extended – po wybraniu tej wartości WSDL może być wykorzystywane na dowolnym systemie lub bazie danych OLTP. Należy jednak upewnić się, że używany filtr istnieje w odpowiednich bazach danych OLTP i ma te same ustawienia.

Wartość domyślna: oltp.

https://rXYZ.semiramis.com/webservices/Export?wsdl;oltp= OLTPDB00;filter=TITLE

Generowanie klas Java

W kolejnym kroku należy przetłumaczyć WSDL na klasy Java. Można w tym celu użyć narzędzi z pakietu AXIS, ale łatwiej jest to zrobić za pomocą polecenia CreateWSDLJavaSources.

Ta komenda nie tylko tłumaczy WSDL na klasy Java, ale może również automatycznie wykonać zapytanie o WSDL z serwera usługi sieciowej. Szczegółowy opis wszystkich parametrów znajduje się w rozdziale Generowanie plików źródłowych Java z WSDL

CreateWSDLJavaSources 	
    -server:rXYZ.semiramis.com 	
    -service:Export	
    -oltp:DATABASE00	
    -filter:TITLE 	
    -userCertificateFileName:C:\temp\XYZ.jks 	
    -userCertificateFilePassword:1234567  	
    -serverCertificateFileName:C:\temp\XYZ.jks 	
    -outputDirectory:C:\semiramis\work\job0xxxx\usrXYZ\source 	
    -outputNameSpace:http://webservices.semiramis.com/2006-01/Export/extended/TITLE
        =com.cisag.app.system.webservices.log.export.generated
-outputNameSpace:http://cisag.com/pgm/external/webservices/2006-01
    -outputNameSpace:http://webservices.semiramis.com/2006-01/common
        =com.cisag.app.system.webservices.log.export.generated 	
    -outputNameSpace:http://webservices.semiramis.com/2006-01/Export/extended/TITLE/data
        =com.cisag.app.system.webservices.log.export.generated

Teraz należy przetłumaczyć utworzone klasy Java.

Programowanie klienta usługi sieciowej

Klient Java może zastosować wygenerowane klasy w celu wywołania żądanej usługi sieciowej. W tym celu należy wykonać następujące kroki:

1. Ustawić ścieżki pliku zawierającego certyfikat użytkownika oraz hasła do otwarcia tego pliku.
2. Ustawić ścieżki pliku zawierającego certyfikat serwera. Można to zrobić poprzez ustawienia odpowiednich właściwości (properties).

System.setProperty("javax.net.ssl.keyStore", userCertificate);
System.setProperty("javax.net.ssl.keyStorePassword",password);
System.setProperty("javax.net.ssl.trustStore", serverCertificate); 

3. Utworzyć obiekt locator i wykonać zapytania dla obiektu service.

ExportLocator loc= new ExportLocator();
URL url= new URL(“https://<server>:<port>/webservices/<service>? oltp=<oltp>;filter=<filter>“);
service = loc.getExport( url );

4. Wygenerować obiekt request i ustawić parametry.

ExportRequest request= new ExportRequest();
request.setSearchName("com.cisag.app.general.obj.Title");
// ustawienie innych parametrów …

5. Wywołać usługę sieciową:

ExportResponse response= service.export(request);

6. Przeanalizować zwracane dane:

ExportResult result = response.getResult();
if (result != null) {
Title[] instances = result.getExportData();
}

Wymagane biblioteki

W celu uruchomienia klienta Java wymagane są następujące biblioteki:

Biblioteki można pobrać ze strony projektu Apache.

Zapytanie URI dla usług sieciowych

Aby uruchomić usługi sieciowe, należy wywołać odpowiedni identyfikator URI specyficzny dla danej usługi sieciowej.

• CallApplication
  https://<server>:<port>/webservices/CallApplication?oltp=<oltp>
• Export
  https://<server>:<port>/webservices/Export?oltp=<oltp>;filter=<filter>;oltpMode=<mode>
• Import
  https://<server>:<port>/webservices/Import?oltp=<oltp>;filter=<filter>;oltpMode=<mode>
• Search
  https://<server>:<port>/webservices/Search?oltp=<oltp>

Dostępne parametry:

• server – adres serwera aplikacji systemu ERP
• port – port serwera aplikacji systemu ERP
• oltp – identyfikator bazy danych OLPT, na której loguje się usługa sieciowa, w celu uzyskania wyniku zapytania
• filter – identyfikator filtra dostępnego w podanej bazie danych OLTP, który określa atrybuty jednostki biznesowej i inne ustawienia, np. format czasu/ Ten parametr jest wymagany tylko dla usług sieciowych Import i Export.
• oltpMode – tryb OLPT. Określa, czy nazwa bazy danych OLTP powinna być zawarta w obszarze nazw usługi sieciowej. Dostępne wartości:
  • oltp – po wybraniu tej wartości w obszarze nazw pojawi się nazwa bazy danych OLTP, a wygenerowane WSDL może zostać zastosowane na aktualnym systemie i dla podanej bazy OLTP.
  • extended – po wybraniu tej wartości WSDL może być wykorzystywane na dowolnym systemie lub bazie danych OLTP. Należy jednak upewnić się, że używany filtr istnieje w odpowiednich bazach danych OLTP i ma te same ustawienia.

Wartość domyślna: oltp. Ten parametr jest wymagany tylko dla usług sieciowych Import i Export.

Klienci testowi

Comarch ERP Enterprise oferuje pięciu klientów testowych służących jako szablony dla indywidualnych rozwiązań. Są oni dostępni w klasie Java w obszarze nazw com.cisag.app.system.webservices i mogą być wywołani z poziomu Toolshell za pomocą opisanych poniżej komed.

W przypadku wszystkich klientów testowych należy pamiętać, że wielokrotne wywoływanie klienta testowego w tym samym procesie może prowadzić do problemów z połączeniem, jeśli używane są różne certyfikaty serwera. Jeśli podczas uruchamiania klientów testowych z poziomu Toolshell wystąpią błędy połączenia, należy spróbować ponownie uruchomić serwer aplikacji.

Generowanie plików źródłowych Java z WSDL

Na przykład dla klienta CreateWSDLJavaSources dostępne są następujące parametry:

• userCertificateFileName – pełna nazwa pliku zawierającego certyfikat użytkownika.
• userCertificateFilePassword – hasło do otwarcia pliku zawierającego certyfikat użytkownika.
• serverCertificateFileName – pełna nazwa pliku zawierającego certyfikat serwera.
• uri – adres URI dla WSDL, które ma zostać przetłumaczone. Ten parametr może zostać zastosowany do otwarcia WSDL z dowolnego adresu internetowego (https://…) lub w systemie pliku (file:///…). Parametr nie może być stosowany razem z parametrami server, port, service, oltp i filter.
• server – Adres serwera usługi sieciowej. Parametr nie może być stosowany razem z parametrem uri.
• port – Port serwera usługi sieciowej. Parametr nie może być stosowany razem z parametrem uri.
• service – żądana usługa sieciowa serwera. Parametr nie może być stosowany razem z parametrem uri.
• oltp – identyfikator bazy danych OLPT serwera, na której loguje się usługa sieciowa. Parametr nie może być stosowany razem z parametrem uri.
• filter – identyfikator filtra serwera usługi sieciowej, który ma być używany podczas wyboru atrybutów jednostki biznesowej. W tym miejscu należy wybrać ten sam filtr, który został wybrany podczas generowania WSDL. W przypadku udostępnionych klientów testowych jest to filtr o nazwie TITLE. Parametr nie może być stosowany razem z parametrem uri.
• outputNameSpace – nazwa obszaru nazw, w którym mają się zawierać wygenerowane klasy Java. Dla każdego obszaru XML w WSDL można określić jeden obszar nazw Java w formie
  http://cisag…=com.example.app….
• outputDirectory – folder w lokalnym systemie plików, do którego są zapisywane wygenerowane pliki źródłowe Java
• oltpMode – format obszarów nazw w żądanym WSDL. Dostępne wartości: extended lub oltp. Opcjonalnie, wartość domyślna to oltp.
• help – dostarcza krótki opis wszystkich parametrów. Opcjonalnie
• verbose – dostarcza informacje podczas generowania plików źródłowych Java. Opcjonalnie.
• debug – dostarcza informacje dotyczące debugowania podczas generowania plików źródłowych Java. Opcjonalnie.

CreateWSDLJavaSources -server:rXYZ.cisag.com -service:CallApplication -userCertificateFileName:C:\temp\XYZ.jks -userCertificateFilePassword:1234567 -serverCertificateFileName:C:\temp\XYZ.jks -outputDirectory: C:\semiramis\work\jobxxxxx\usrXYZ\source -outputNameSpace:http://webservices.semiramis.com/2006-01/common=com.cisag.app.system.webservices.log.generated

Eksport

Dla klienta testowego WebServicesRemoteExportTestClient dostępne są następujące parametry:

• userCertificateFileName – pełna nazwa pliku zawierającego certyfikat użytkownika
• userCertificateFilePassword – hasło do otwarcia pliku zawierającego certyfikat użytkownika
• serverCertificateFileName – pełna nazwa pliku zawierającego certyfikat serwer
• server – adres serwera usługi sieciowej
• port – port serwera usługi sieciowej
• oltp – identyfikator bazy danych OLPT serwera, na której loguje się usługa sieciowa
• filter – identyfikator filtra serwera usługi sieciowej, który ma być używany podczas wyboru atrybutów jednostki biznesowej. W tym miejscu należy wybrać ten sam filtr, który został wybrany podczas generowania WSDL. W przypadku udostępnionych klientów testowych jest to filtr o nazwie TITLE.
• select – wzorzec wyszukiwania pozwalający ograniczyć eksportowane rekordy danych. Podana wartość jest porównywana z nazwą rekordów danych. Domyślną wartością jest *, co oznacza, że wybierane są wszystkie obiekty.
• help – dostarcza krótki opis wszystkich parametrów

WebServicesRemoteExportTestClient -server:rXYZ.cisag.com -oltp:DATABASE00 -filter:TITLE -userCertificateFileName:C:\temp\XYZ.jks 	-userCertificateFilePassword:1234567  	-serverCertificateFileName:C:\temp\XYZ.jks

Klasy Java klienta testowego:

• Obszar nazw com.cisag.app.system.webservices.log
  • WebServicesClientBase
  • WebServicesClientDebugHelper
  • WebServicesRemoteExportTestClient
• Obszar nazw com.cisag.app.system.webservice.log..generated.exp
  • Export
  • ExportLocator
  • ExportService
  • ExportSoapBindingStub
  • ExportRequest
  • S
  • java
  • Title
• Obszar nazw com.cisag.app.system.webservices.tools
  • ExportService
• Obszar nazw com.cisag.app.system.webservices.log.generated
  • Message
  • MessageQueue
  • MessageSeverity
  • ParameterListEntry
  • ParameterListEntryType

Import

Dla klienta testowego WebServicesRemoteImportTestClient dostępne są następujące parametry:

• userCertificateFileName – pełna nazwa pliku zawierającego certyfikat użytkownika
• userCertificateFilePassword – hasło do otwarcia pliku zawierającego certyfikat użytkownika
• serverCertificateFileName – pełna nazwa pliku zawierającego certyfikat serwera
• Server – adres serwera usługi sieciowej
• Port – port serwera usługi sieciowej
• Oltp – identyfikator bazy danych OLPT serwera, na której loguje się usługa sieciowa
• Filter – identyfikator filtra serwera usługi sieciowej, który ma być używany podczas wyboru atrybutów jednostki biznesowej. W tym miejscu należy wybrać ten sam filtr, który został wybrany podczas generowania WSDL. W przypadku udostępnionych klientów testowych jest to filtr o nazwie TITLE.
• Help – dostarcza krótki opis wszystkich parametrów

WebServicesRemoteImportTestClient -server:rXYZ.cisag.com -oltp:DATABSE00 -filter:TITLE -userCertificateFileName:C:\temp\XYZ.jks 	-userCertificateFilePassword:1234567  	-serverCertificateFileName:C:\temp\XYZ.jks

Klasy Java klienta testowego:

• Obszar nazw com.cisag.app.system.webservices.log
  • WebServicesClientBase
  • WebServicesClientDebugHelper
  • WebServicesRemoteImportTestClient
• Obszar nazw com.cisag.app.system.webservice.log..generated.imp
  • Import
  • ImportLocator
  • ImportService
  • ImportSoapBindingStub
  • ImportRequest
  • ImportResponse
  • ImportResult
  • EntityWrapper
  • Title
• Obszar nazw com.cisag.app.system.webservices.tools
  • ImportService
• Obszar nazw com.cisag.app.system.webservices.log.generated
  • Message
  • MessageQueue
  • MessageSeverity
  • ImportMode
  • ImportCorrectionMode
  • ImportWarningsMode

Wyszukiwanie

Dla klienta testowego WebServicesRemoteSearchTestClient dostępne są następujące parametry:

• userCertificateFileName – pełna nazwa pliku zawierającego certyfikat użytkownika
• userCertificateFilePassword – hasło do otwarcia pliku zawierającego certyfikat użytkownika
• serverCertificateFileName – pełna nazwa pliku zawierającego certyfikat serwera
• server – adres serwera usługi sieciowej
• port – port serwera usługi sieciowej
• oltp – identyfikator bazy danych OLPT serwera, na której loguje się usługa sieciowa
• searchName – w pełni kwalifikowana nazwa wyszukiwania OQL
• searchParameter – parametr wyszukiwania OQL (opcjonalne). Parametr musi mieć format <name>=<wert>. Nazwa odpowiada nazwie pola wyszukiwania z wyszukiwania OQL, wartością parametru jest natomiast Selection String.

Możliwe ciągi selection zależą od typu danych pola wyszukiwania i są opisane w dokumencie Zdalne interfejsy BIS, sekcja Typy danych w wyszukiwaniu.

WebServicesRemoteSearchTestClient
-server:rXYZ.semiramis.com
-oltp:OLTPDB00
-searchName: com.cisag.app.general.obj.TitleSearch
-userCertificateFileName:C:\temp\XYZ.jks
-userCertificateFilePassword:1234567
-serverCertificateFileName:C:\temp\XYZ.jks

Klasy Java klienta testowego:

• Obszar nazw com.cisag.app.system.webservices.log
  • WebServicesClientBase
  • WebServicesClientDebugHelper
  • WebServicesRemoteSearchTestClient
• Obszar nazw com.cisag.app.system.webservice.log..generated.search
  • Search
  • SearchLocator
  • SearchService
  • SearchSoapBindingStub
  • SearchRequest
  • SearchExistsRequest
  • SearchResponse
  • SearchExistsResponse
  • SearchResult
  • SearchExistsResult
  • SearchFormat
• Obszar nazw com.cisag.app.system.webservices.tools
  • SearchService
• Obszar nazw com.cisag.app.system.webservices.log.generated
  • Message
  • MessageQueue
  • MessageSeverity
  • ParameterListEntry
  • ParameterListEntryType

Klient Excel (Microsoft.Net-Client)

Comarch ERP Enterprise oferuje również klienta usług sieciowych dla programu Microsoft Excel. Składa się on ze skoroszytu programu Excel i dodatkowej biblioteki. Na tym kliencie mogą być eksportowane, edytowane i ponownie importowane wszystkie rekordy danych obiektu biznesowego Title (com.cisag.app.general.obj.Title). Klient Excel jest więc jednocześnie klientem eksportu i klientem importu.

Klient Excel składa się z dwóch arkuszy: Logowanie i Dane. W arkuszu Logowanie użytkownik musi wprowadzić wszystkie dane wymagane dla loginu eksportu. Wyeksportowane dane są wyświetlane w arkuszu Dane i mogą być edytowane przez użytkownika.

Wymagania

Do samodzielnego rozwoju klienta Excel wymagane są następujące pakiety oprogramowania:

• .NET 2.0
• MS Visual Studio 2005 Professional Edition
• MS Office 2003 Professional
• MS Visual Studio 2005 Tools for the Microsoft Office System (Na DVD MSDN jest to dodatek do Visual Studio; w innych przypadkach jest to osobna edycja)

Instalacja klienta

Klient testowy Excel jest udostępniany i aktualizowany jako plik wydania  „com.cisag.sys.delivery.Install-Web-Services-Clients“ w postaci „.zip”. Za pomocą odpowiedniego programu archiwizującego należy rozpakować plik files/install/webservices/web-services-clients.zip z folderu serwera plików systemu Comarch ERP Enterprise do folderu głównego dysku „C:”. Powstaje następująca struktura folderu:

C:\
    semiramis\
          webservices\
                   ExcelImportExportTestClient\

Folder ExcelImportExportTestClient zawiera wszystkie pliki niezbędne do rozwoju i korzystania z klienta Excel.

Klient Excel wykorzystuje uwierzytelnianie hasłem. Dlatego, aby móc korzystać z klienta Excel, w przeglądarce Internet Explorer musi być zainstalowany tylko certyfikat serwera lub certyfikat z nadrzędnego urzędu certyfikacji (plik .cer).

Uruchomienie klienta

Należy otworzyć folder C:\semiramis\webservices\ExcelRemoteImportExportClient w Windows Explorer. Dwukrotnie kliknąć na plik ExcelRemoteImportExportClient.sln. Spowoduje to otwarcie klienta w Visual Studio. Następne należy uruchomić klienta wybierając z menu opcję Debug/Run without Debugging. Klient pojawi się w Microsoft Excel. Poniżej znajduje się opis obsługi klienta.

Arkusz Logowanie

W arkuszu Logowanie należy wprowadzić następujące wartości:

• Serwer – adres serwera aplikacji systemu ERP, na którym udostępniane są usługi sieciowe
• Port – port, na którym udostępniane są usługi sieciowe (wartość domyślna 443)
• OLTP – identyfikator bazy OLAP, z której ma być wykonany eksport
• Filtr – identyfikator filtra na podanej bazie OLAP. Należy wprowadzić filtr dla jednostki biznesowej cisag.app.general.obj.Title. Dla udostępnionego klienta testowego filtr musi mieć nazwę TITLE. Tę nazwę również należy wprowadzić w tym polu. Atrybuty name i description muszą być wybrane w samym filtrze, a ustawienie języka filtra musi mieś wartość Jeden język.
• Użytkownik – identyfikator użytkownika, na którego ma nastąpić logowanie. Użytkownik musi być przyporządkowany do systemu i posiadać uprawnienia do logowania na podanej bazie OLAP.
• Hasło – hasło dla podanego użytkownika

Oprócz pól wprowadzania danych w arkuszu znajdują się dwa przyciski: Importuj i Eksportuj. Służą one do uruchamiania importu lub eksportu po uzupełnieniu wymaganych danych logowania. Po uruchomieniu przycisku następuje komunikacja z serwerem. Po zakończeniu komunikacji pojawia się okno dialogowe z komunikatem.

Arkusz Dane

Wyeksportowane dane są wyświetlane w arkuszu Dane i mogą być edytowane przez użytkownika. Dostępne są dwa przyciski Dodaj i Usuń. Za pomocą przycisku Dodaj użytkownik dodaje nowy, pusty wiersz na końcu tabeli, w którym można wprowadzić nowy rekord danych. Przycisk Usuń usuwa rekord danych z aktualnie aktywnej komórki arkusza. Nie powoduje to jednak usunięcia tego rekordu danych w bazie danych OLTP w przypadku późniejszego importu. Zasadniczo żaden rekord danych nie może zostać usunięty z bazy danych przez tego klienta testowego.

Obsługa błędów

Serwer usługi sieciowej Comarch ERP Enterprise umożliwia wydanie informacji o żądaniach klientów. Dotyczy to zarówno programowalnych, jak i nieprogramowalnych usług sieciowych.

W tym celu należy aktywować debugowanie klasy Java com.cisag.sys.kernel.webservices.CisWebServicesResource na serwerze aplikacji systemu ERP, który jest wywoływany przez klientów. W zależności od poziomu debugowania, w Toolshell pojawiają się następujące dane wyjściowe:

• INFO – podczas każdego wywołania usługi sieciowej wydania są generowane na początku i na końcu przetwarzania w SAS. Utworzone wydania: Numer sesji, Metoda HTTP, URI zapytania, czas przetwarzania.
• FINEST – oprócz wydań na poziomie INFO, poziom FINEST podaje zawartość (treść HTTP) żądania klienta i odpowiedź usługi. Wydania można aktywować i dezaktywować dla aktualnego SAS za pomocą komendy Toolshell dbgcls.

Załącznik

Zastawienie wszystkich komend Toolshell wymaganych do utworzenia plików źródłowych Java dla klientów testowych lub do uruchomienia klientów testowych.

#
# CallApplication
#
# Abfragen der WSDL:
# https://rXYZ.semiramis.com/webservices/CallApplication?wsdl

CreateWSDLJavaSources -server:rXYZ.cisag.com -service:CallApplication -userCertificateFileName:C:\temp\XYZ.jks -userCertificateFilePassword:1234567 -serverCertificateFileName:C:\temp\XYZ.jks -outputDirectory: C:\semiramis\work\jobxxxxx\usrXYZ\source -outputNameSpace:http://webservices.semiramis.com/2006-01/common=com.cisag.app.system.webservices.log.generated


WebServicesTestClient -server:rXYZ.semiramis.com -oltp:OLTPDB00-userCertificateFileName:C:\temp\XYZ.jks 	-userCertificateFilePassword:1234567  	-serverCertificateFileName:C:\temp\XYZ.jks 	


#
# Export
#
# Zapytania WSDL:
# https://rXYZ.semiramis.com/webservices/Export?wsdl;oltp=OLTPDB00;filter=TITLE

CreateWSDLJavaSources -server:rXYZ.cisag.com -service:Export -oltp:OLTPDB00 -filter:TITLE -oltpMode:extended -userCertificateFileName:C:\temp\XYZ.jks -userCertificateFilePassword:1234567 -serverCertificateFileName:C:\temp\XYZ.jks -outputDirectory: C:\semiramis\work\jobxxxxx\usrXYZ\source -outputNameSpace:http://webservices.semiramis.com/2006-01/Export/extended/TITLE=com.cisag.app.system.webservices.log.generated.exp -outputNameSpace:http://webservices.semiramis.com/2006-01/common=com.cisag.app.system.webservices.log.generated -outputNameSpace:http://webservices.semiramis.com/2006-01/Export/extended/TITLE/data=com.cisag.app.system.webservices.log.generated.exp


WebServicesRemoteExportTestClient -server:rXYZ.semiramis.com -oltp:OLTPDB00 -filter:TITLE -userCertificateFileName:C:\temp\XYZ.jks 	-userCertificateFilePassword:1234567  	-serverCertificateFileName:C:\temp\XYZ.jks 	


#
# Import
#
# Zapytania WSDL:
# https://rXYZ.semiramis.com/webservices/Import?wsdl;oltp=OLTPDB00;

CreateWSDLJavaSources 	-server:rXYZ.semiramis.com 	-service:Import	-oltp: OLTPDB00 -filter:TITLE -oltpMode:extended -userCertificateFileName:C:\temp\XYZ.jks 	-userCertificateFilePassword:1234567  	-serverCertificateFileName:C:\temp\XYZ.jks 	-outputDirectory:C:\semiramis\work\jobxxxxx\usrXYZ\source 	-outputNameSpace:http://webservices.semiramis.com/2006-01/common=com.cisag.app.system.webservices.log.generated -outputNameSpace:http://webservices.semiramis.com/2006-01/Import/extended/TITLE=com.cisag.app.system.webservices.log.generated.imp -outputNameSpace:http://webservices.semiramis.com/2006-01/Import/extended/TITLE/data=com.cisag.app.system.webservices.log.generated.imp	

WebServicesRemoteImportTestClient -server:rXYZ.semiramis.com -oltp:OLTPDB00 -filter:TITLE -userCertificateFileName:C:\temp\XYZ.jks 	-userCertificateFilePassword:1234567  	-serverCertificateFileName:C:\temp\XYZ.jks


#
# Search
#
# Zapytania WSDL:
# https://rXYZ.semiramis.com/webservices/Search?wsdl;oltp=OLTPDB00;

CreateWSDLJavaSources 	-server:rXYZ.semiramis.com 	-service:Search	-oltp:OLTPDB00 	-userCertificateFileName:C:\temp\XYZ.jks 	-userCertificateFilePassword:1234567  	-serverCertificateFileName:C:\temp\XYZ.jks 	-outputDirectory:C:\semiramis\work\jobxxxxx\usrXYZ\source 	-outputNameSpace:http://webservices.semiramis.com/2006-01/common=com.cisag.app.system.webservices.log.generated -outputNameSpace:http://webservices.semiramis.com/2006-01/Search=com.cisag.app.system.webservices.log.generated.search

WebServicesRemoteSearchTestClient -server:rXYZ.semiramis.com -oltp:OLTPDB00 -searchName:com.cisag.app.general.obj.TitleSearch 	-userCertificateFileName:C:\temp\XYZ.jks 	-userCertificateFilePassword:1234567  	-serverCertificateFileName:C:\temp\XYZ.jks