Model Wymiany Danych dla dostępu do aplikacji CHECK przy użyciu WebService Telekomunikacja Polska S.A. - Przedsiębiorca telekomunikacyjny

Model Wymiany Danych dla dostępu do aplikacji CHECK przy użyciu WebService Telekomunikacja Polska S.A. - Przedsiębiorca telekomunikacyjny Wersja r1.76 Status: (zamrożony)aktualizowany

2 Spis Treści 1 WPROWADZENIE... 3 2 SŁOWNIK POJĘĆ... 4 3 PODSTAWOWE DANE KONFIGURACYJNE... 4 3.1. USTAWIENIA TECHNICZNE SYSTEMÓW TP I PRZEDSIĘBIORCY TELEKOMUNIKACYJNEGO... 5 3.2. ZASADY BEZPIECZEŃSTWA PRZESYŁU DANYCH... 5 3.3. SPECYFIKACJA POSTACI WIADOMOŚCI.... 6 4 TYPY DANYCH... 6 4.1. TYPY PÓL... 6 4.1.1. DATE... 6 4.1.2. CITY-NAME... 6 5 PROCES OBSŁUGI ZAPYTAŃ DO APLIKACJI CHECK... 7 5.1. WYSŁANIE ZAPYTANIA DO APLIKACJI CHECK... 7 5.1.1. Proces po stronie Operatora Korzystającego... 7 5.1.2. Komunikat SOAP zapytania do aplikacji CHECK... 7 6 ODPOWIEDŹ NA ZAPYTANIE DO APLIKACJI CHECK... 9 6.1. ODPOWIEDŹ NA ZAPYTANIE DO APLIKACJI CHECK.... 9 6.1.1. Proces po stronie Operatora Korzystającego... 10 6.1.2. Komunikat SOAP odpowiedzi z aplikacji CHECK... 10 7 SPECYFIKACJA KOMUNIKATÓW WEJŚCIOWYCH I WYJŚCIOWYCH... 15 { PAGE 172

3 1 Wprowadzenie Niniejszy dokument zawiera opis Modelu Wymiany Danych (MWD) pomiędzy Telekomunikacją Polską S.A. (dalej zwaną TP), a Operatorami Korzystającymi (dalej zwanym OK) na potrzeby dostępu do aplikacji Check OA przy użyciu WebServices. Dostęp do aplikacji CHECK możliwy jest także poprzez stronę Internetową, zasady korzystania z www zostały opisane w oddzielnych dokumentach (porozumienie, umowa) Celem niniejszego dokumentu jest określanie zasad realizacji dokonanych przez Strony uzgodnień w zakresie udostępniania przez TP informacji o parametrach łączy w aspekcie szerokopasmowej transmisji danych. W przypadku zmiany zasad współpracy Stron poprzez umowę zawartą między Stronami, Strony niezwłocznie dokonają zmian w niniejszym dokumencie celem dostosowania go do wprowadzonych zmian. Opisany w tym dokumencie MWD ma zastosowanie przy współpracy pomiędzy Telekomunikacją Polska i Operatorami Korzystającymi. Modelowy przebieg komunikacji MWD na platformie Web Services przedstawia poniższy rysunek, na którym jest widoczny ogólny schemat realizacji zapytań. AP stem OK W A N stem TP S AP Dostęp do aplikacji CHECK przy użyciu WebService jest dedykowany dla Przedsiębiorców Telekomunikacyjnych, którzy zamierzają podpisać umowę komercyjną na CHECK. { PAGE 173

4 2 Słownik pojęć ADSL Check CHECK DR DSLAM KNA MWD OK Strona TP UTF-8 XML ŁA Asymmetric Digital Subscriber Line asymetryczna cyfrowa linia abonencka zgodna ze standardem ITU G.992.1 (G.DMT). Narzędzie dostępne poprzez Internet, dzięki któremu Operator, który zawarł Umowę z TP może uzyskać wstępną informację o możliwości świadczenia usług szerokopasmowego dostępu do Internetu na Łączu Abonenckim Aktywnym będącym przedmiotem zapytania. Aplikacja Check dla Operatorów Alternatywnych Dzień Roboczy - dzień powszedni Digital Subscriber Line Access Multiplexer dostępowy multiplekser cyfrowych linii abonenckich. Krajowy Numer Abonencki Model Wymiany Danych Operator Korzystający operator korzystający z dostępu do LPA poprzez Węzły sieci telekomunikacyjnej TP na potrzeby sprzedaży usług szerokopasmowej transmisji danych lub wnioskujący o zapewnienie takiego dostępu. TP lub Operator Korzystający (lub łącznie Strony). Telekomunikacja Polska S.A. Sposób kodowania Unikodu, tj. komputerowego zestawu znaków mającego w zamierzeniu obejmować wszystkie pisma używane na świecie. Definiują go dwa standardy - Unicode oraz ISO 10646. Znaki obu standardów są identyczne. Standard Unicode obejmuje przydział przestrzeni numeracyjnej poszczególnym grupom znaków, nie obejmuje zaś sposobów bajtowego kodowania znaków. Jest kilka metod kodowania, oznaczanych skrótami UCS (Universal Character Set) lub UTF (Unicode Transformation Format) Extensible Markup Language, w wolnym tłumaczeniu Rozszerzalny Język Znaczników, to uniwersalny język formalny przeznaczony do reprezentowania różnych danych w ustrukturalizowany sposób. XML jest niezależny od platformy, co umożliwia łatwą wymianę dokumentów pomiędzy różnymi systemami. Łacze Abonenckie aktywne 3 Podstawowe dane konfiguracyjne Wymiana danych pomiędzy TP i Operatorem Korzystającym odbywać się będzie na Platformie Web Services z wykorzystaniem protokołu SOAP i https. Wersje protokołów: Soap SOAP version 1.1 RPC Https z wykorzystaniem TLSv1 lub SSLv3 Timeout (Maksymalny czas na udzielenie odpowiedzi na zapytanie do systemy przez Aplikachę Check dla OA to) 2 minuty Maksymalna ilość zapytań na miesiąc (50 000 ) - nieodpłatanie. Powyżej liczby 50 000 zapytań/operator (oboma kanałami).zostaną naliczane opłaty za każde zapytanie. Dotyczy kanały web service jak i komunikacji po przez stronę www. Maksymalna zbiorcza ilość obsłużonych zapytań przez TP w miesiącu 200 000 przez Operatora, powyżej 200 000 nie gwarantujemy dostępnosić aplikacji z czasem odpowiedzi 2 minuty.. Adres domenowy aplikacji Check: Adres serwera brzegowego operatora { PAGE 174

5 Każda ze Stron uczestniczących w wymianie komunikatów jest zobowiązana do zapewnienia własnej części infrastruktury niezbędnej do wymiany informacji. Komunikaty będą kodowane w standardzie UTF-8. TP zapewnia dostępność aplikacji Check OA we wszystkie dni robocze oraz w soboty i niedziele w godzinach 8:00 22:00. W czasie poza gwarantowaną dostępnością aplikacji dokonywana będzie aktualizacja bazy danych. W tym czasie TP nie gwarantuje dostępności aplikacji. Aktualizacja danych w bazie odbywa się w godzinach poza wskazanym okresem dostępności aplikacji. Baza danych aplikacji CHECK nie będzie aktualizowana w soboty, niedziele i inne dni ustawowo wolne od pracy. Wszystkie komunikaty przesyłane do TP jak i przez TP oraz logi z zapytań składanych przez stronę www będą archiwizowane i będą wykorzystane w przypadku rozpatrywania reklamacji. 3.1. Ustawienia techniczne systemów TP i Przedsiębiorcy telekomunikacyjnego Dostęp do aplikacji CHEK-OA będzie realizowany jedynie ze wskazanych adresów IP serwerów OK. W przypadku konieczności zmiany adresów IP lub nazwy domenowej, strony powiadomią siebie najdalej na 10 dni roboczych przed planowaną zmianą. Niniejszy dokument w ramach prac zespołów roboczych, TP i Operatora Korzystającego będzie ulegał modyfikacji. Modyfikacje będą wykonywane w formie pisemnej i będą wymagały akceptacji przez Strony. 3.2. Zasady bezpieczeństwa przesyłu danych Dla zapewnienia bezpiecznego przesyłu informacji połączenie WebServices będzie realizowane przy użyciu bezpiecznego połączenia https z wykorzystaniem TLSv1 lub SSLv3. Uwierzytelnienie i autoryzacja dostępu do WebService odbywać się będzie z wykorzystaniem uwierzytelnienia certyfikatem klienckim. Każdy z operatorów będzie generował we własnym zakresie klucz prywatny, oraz CSR, który będzie wysyłany do TP. W odpowiedzi odsyłany będzie certyfikat w formie plikowej ( der lub pem ). Certyfikat będzie ważny przez okres 3 lat i na administratorze OA spoczywa odpowiedzialność ponownego wystąpienia o certyfikat przed upłynięciem jego ważności. Komunikacja Operatorów z WebService będzie ograniczona do wcześniej określonego adresu IP Operatora. Adres IP będzie ściśle powiązany z certyfikatem, stąd połączenia z wykorzystaniem danego certyfikatu będą możliwe wyłącznie z określonych adresów IP. Jeśli otrzymany komunikat nie może być obsłużony przez system informatyczny Przedsiębiorcy telekomunikacyjnego z powodu błędów krytycznych w strukturze wiadomości, awarii systemu, wyłączenia systemu na czas prac konserwacyjnych, wyłączenia kanału komunikacyjnego z powodu awarii po stronie Przedsiębiorcy telekomunikacyjnego itp., strona, do której był skierowany komunikat odpowie komunikatem awaryjnym FAULT zgodnie ze standardem SOAP v 1.1. W zależności od przyczyny odrzucenia przesyłki strona, która wygenerowała przesyłkę jest zobowiązana do poprawienia błędów i powtórnego wysłania przesyłki lub uruchomienia komunikacji kanałem awaryjnym (opis procedury dla komunikacji awaryjnej zostanie doprecyzowany podczas spotkań roboczych). Poprawiony komunikat powinien zawierać zaktualizowane informacje o dacie jego generacji. Formaty komunikatów są opisane w tym dokumencie. Do identyfikacji operatorów używane będą numery z rejestru przedsiębiorców telekomunikacyjnych { PAGE 175

6 3.3. Specyfikacja postaci wiadomości. CheckValidationException LINE_SERVICE_INPUT LINE_SERVICE_OUTPUT 4 Typy danych Jeśli szczegółowy opis w specyfikacji komunikatów nie stanowi inaczej, przyjmuje się następującą interpretację typów danych: INT, INTEGER - liczba całkowita z zakresu od 0 do 32767, reprezentowana przez ciąg znaków INT(n) - liczba całkowita, nieujemna, reprezentowana przez ciąg n znaków DATE - data reprezentowana przez ciąg znaków w postaci RRRR-MM-DD GG:mm:SS, gdzie RRRR - rok (4 cyfry), MM - miesiąc (2 cyfry od 01 do 12), DD dzień (2 cyfry od 01 do 31), GG - godzina (2 cyfry od 00 do 23), mm - minuty (2 cyfry od 00 do 59), SS - sekundy (2 cyfry od 00 do 59) np. 2007-11-15 13:52:45 oznacza datę 15 listopada 2007 godz. 13:52:45. CHAR - jeden znak CHAR(512) - pole znakowe o długości 512 znaków W przypadku typów INT, zera wiodące są ignorowane przez systemy, dlatego jeśli np. w jednym komunikacie pole <QUERY-ID> będzie zawierało ciąg znaków "1234", a w kolejnym takim komunikacie pole <QUERY-ID> będzie zawierało ciąg znaków "00001234", to drugi komunikat zostanie odrzucony z powodu powtórzonego <QUERY-ID>. 4.1. Typy pól 4.1.1. DATE Data jest podawana w formacie RRRR-MM-DD HH24:MI:SS, 4.1.2. CITY-NAME Miejscowość do 50 znaków { PAGE 176

7 5 Proces obsługi zapytań do aplikacji CHECK 5.1. Wysłanie zapytania do aplikacji CHECK 5.1.1. Proces po stronie Operatora Korzystającego System Operatora Korzystającego przesyła komunikat - zapytanie do aplikacji CHECK na platformie Web Services. Pola komunikatu, ich format oraz wymagalność opisuje rozdział 5.1.2 5.1.2. Komunikat SOAP zapytania do aplikacji CHECK Komunikat przesyłany od OA do systemu CHECK. Nazwa pola Typ Opis Czy wymagany? LINE_SERVICE_IN PUT Rekord MSG CHAR(256) NIE QUERY_AGREEME NT BOOLEAN TAK Rekord nadrzędny MSG_HEADER Rekord Identyfikacja komunikatu TAK LINE_SER VICE_INP UT SUBJECT_ID CHAR(40) Identyfikacja nadawcy komunikatu TAK DEST_SUBJECT_ID CHAR(40) Identyfikacja odbiorcy komunikatu TAK TEST_VER INT(1) Identyfikator komunikatu testowego 0 komunikat produkcyjny 1 komunikat testowy LINE_SERVICE_QU ERY GENERATE_DATE NIE TAK Rekord TAK LINE_SER VICE_INP UT DATE (RRRR-MM- DD GG:MM:SS) Data generacji zapytań. Data przysłana w komunikacie musi miescic sie w przedziale +- 60min od aktualnego czasu serwera. Check LINE_SERVICE_QU ERY_ELEMENT Rekord QUERY_ID CHAR(20) Identyfikator zapytania. Zawiera ID Operatora Korzystającego pierwsze 5 znaków QUERY_ID to identyfikator OA (uzupełniany zerami do 5 znaków) NUMBER CHAR(9) Numer telefonu (tylko cyfry). Zamiennie z SERVICE_ID TAK TAK, Jeżeli pole SERVICE_I LINE_SER VICE_QUE RY Unikalny w skali operatora { PAGE 177

8 Nazwa pola Typ Opis Czy wymagany? SERVICE_ID CHAR(15) Identyfikator usługi (12-znakowy). OA podaje 12 znakowy ID. Zamiennie z NUMBER -, wymagane jeśli pole NUMBER (Nr KNA) pusty SERVICE_SYMBOL CHAR(1) Identyfikator grupy usług regulowanych. Dopuszczalne wartości to identyfikatory grup usług ze słownika dict_service_group skonfigurowane jako regulowane - pole dict_service_group.is_regulated ma wartość 1 D jest puste TAK, Jeżeli pole NUMBER jest puste TAK Rekord nadrzędny { PAGE 178

6 Odpowiedź na zapytanie do aplikacji CHECK 6.1. Odpowiedź na zapytanie do aplikacji CHECK. Aplikacja Check OA w trybie on-line przesyła na platformie Web Services komunikat odpowiedzi na zapytanie do systemu OK. W przypadku gdy KNA podany w zapytaniu nie należy do TP lub TP nie posiada danych niezbędnych do prekwalifikacji aplikacja CHECK będzie generować komunikat o braku danych. W każdym ze wskazanych powyżej przypadków będzie generowany kod przyczyny braku danych, pozwalający na jednoznaczną identyfikację powodu jego wystąpienia. Check uwzględnia rozdzielenie informacji uzyskiwanej w odpowiedzi dla negatywnego wyniku prekwalifikacji z powodu: - braku numeru, - braku danych do prekwalifiakcji Z powodu braku informacji o technologii zastosowanej na ŁA, CHECK nie będzie prezentować danych dla numerów z puli TP które trafiły do OA w ramach usługi NP. W takich przypadkach będzie prezentowany komunikat brak danych. Check OA nie będzie prezentować danych dla łączy uwolnionych na rzecz innych operatorów w ramach usługi LLU. W przypadku łączy PCM lub braku możliwości świadczenia usługi odpowiedz w aplikacji dla pola przepływność będzie - Łącze zwielokrotnione PCM brak możliwości w zależności od przyczyny dla której aplikacja nie jest wstanie udzielić informacji.

10 6.1.1. Proces po stronie Operatora Korzystającego System Operatora Korzystającego odbiera komunikat - odpowiedź z aplikacji CHECK na platformie Web Services. Pola komunikatu, ich format oraz wymagalność opisuje rozdział 6.1.2 6.1.2. Komunikat SOAP odpowiedzi z aplikacji CHECK Komunikat przesyłany z systemu CHECK do systemu zewnętrznego OA. Nazwa pola Typ Opis Czy wymagany? LINE_SERVICE_O UTPUT Rekord Rekord nadrzędn y MSG_HEADER Rekord Identyfikacja komunikatu TAK LINE_SE RVICE_O UTPUT TAK SUBJECT_ID CHAR(40) Identyfikacja nadawcy komunikatu TAK DEST_SUBJECT_I D CHAR(40) Identyfikacja odbiorcy komunikatu TAK TEST_VER INT(1) Identyfikator komunikatu testowego 0 komunikat produkcyjny 1 komunikat testowy LINE_SERVICE_Q UERY_RESULT GENERATE_DATE DATE (RRRR-MM- DD GG:MM:SS) LINE_SERVICE_Q UERY_RESULT_E LEMENT TAK Rekord TAK LINE_SE RVICE_O UTPUT Rekord Data generacji. QUERY_ID CHAR(20) Identyfikator zapytania TAK NUMBER CHAR(9) Numer telefonu (tylko cyfry) TAK Jeżeli pole SERVICE-ID jest puste SERVICE_ID CHAR(15) Identyfikator usługi 12 znakowy ID TAK Jeżeli pole NUMBER jest puste CITY_NAME CHAR(50) Miasto NIE SERVICE_TYPE CHAR NIE SERVICE_SYMBO L CHAR(1) Identyfikator grupy usług regulowanych TAK LINE_SE RVICE_Q UERY_RE SULT { PAGE 1710

11 Nazwa pola Typ Opis Czy wymagany? LINE_SERVICE_Q UERY_RESULT_P ARAMETERS_ELE MENTS PARAMETERS_EL EMENT Rekord Rekord Wyniki prekwalifikacji. Rekord grupuje w osobne sekcje parametry dla poszczególnych technologii. W przypadku braku wyników dla danej technologii sekcja dla tej technologii nie jest obecna w komunikacie. Wynik prekwalifikacji dla pojedynczej technologii. Każda technologia dla której jest poprawny wynik ma osobną sekcję TAK może występowa ć wielokrotni e TAK może występowa ć wielokrotni e ATTR_ID Char(50) dopuszczalne atrybuty TAK ATTR_NAME Char(50) opis atrybutu - w komunikacie może być inny lub pusty ATTR_VALUE Char(50) możliwe lub przykładowe wartości dla atrybutów; jeśli w komunikacie pojawią się inne wartości niż wymienione to powinny być zignorowane. Rekord nadrzędn y LINE_SE RVICE_O UTPUT LINE_SE RVICE_Q UERY_RE SULT_ PARAME TERS_EL EMENTS RESULT Rekord TAK LINE_SE RVICE_O UTPUT RESULT_CODE INT(6) Kod wyniku przetwarzania: RESULT_CODE = 0 wynik pozytywny RESULT_CODE <> 0 wynik negatywny MSG CHAR(1024) Komunikat błedu NIE NIE TAK TAK, gdzie dopuszczalne atrybuty sekcji PARAMETERS_ELEMENT zdefiniowane są następująco: ATTR_ID ATTR_NAME ATTR_VALUE WIRE_LENGTH WIRE_LENGTH Długość łącza wyrażona w km SWITCH_NAME SWITCH_NAME Nazwa obiektu centralowego/systemowego, w którym znajduje się węzeł świadczenia usługi głosowej (POTS/ISDN LINE_INFO LINE_INFO Informacja o łączu - komunikat NWT; opis słowny, np. PCM, ISDN PORT_AVAILABILIT PORT_AVAILABILIT Tak/Nie. Jeśli DSL_TYPE=ADSL lub ADSL2+ lub SHDSL to pole określa dostępność portów ADSL, ADSL2+ i SHDSL w { PAGE 1711

12 sumie. Jeśli DSL_TYPE=VDSL to pole określa dostępność portów tylko dla VDSL. Wartość Tak/Nie wyznaczana jest poprzez porównanie dostępnych portów z progiem zapisanym w konfiguracji. (W 2 połowie 2011 system Check zostanie dostosowany do zwracania dostępności portów precyzyjnie dla każdej technologii.) DSLAM_TYPE DSLAM_TYPE IP, ATM, IP/ATM THROUGHPUT_DO WN Throughput_down Najwyższa przepływność IP dla downstream, np. 6144 THROUGHPUT_UP Throughput_up Najwyższa przepływność IP dla upstream, np. 512 THROUGHPUT_XDS L_DOWN THROUGHPUT_XDS L_UP Throughput_xdsl_down Throughput_xdsl_up Najwyższa przepływność xdsl dla downstream, np. 7644 Najwyższa przepływność xdsl dla upstream, np. 640 LOSS LOSS Wartość rzeczywista tłumienności LOC_ADDRESS LOC_ADDRESS Adres Obiektu DSL_TYPE DSL_TYPE Rodzaj karty. Pole zawiera jedną z wartości: ADSL, ADSL2+, SHDSL, VDSL Dla każdej sekcji PARAMETERS_ELEMENT będzie pokazywał konkretną technologię, której dotyczy sekcja SERVICE_TYPE SERVICE_TYPE Czy usługa głosowa. Parametr opcjonalny. BROADBAND BROADBAND Czy usługa szerokopasmowa. Parametr opcjonalny. Słownik pola RESULT_CODE i MSG: 100, Nieznany błąd 1, Brak numeru 2, Brak prekwalifikacji dla podanych parametrów wejściowych 103, Brak możliwości określenia przepustowości 104, Niejednoznaczny wynik. Odnaleziono wiele wpisów dotyczących łącza { PAGE 1712

13 105, Nie odnaleziono danych kabli logicznych dla podanego przebiegu 106, Niespójne dane kabla logicznego 0, OK 108, Błąd w formacie numeru telefonu: prawidłowy format to 9 cyfr 166, Błąd w formacie ID_łącza 17, Nie można rozkodować wiadomości 4, Pole wymagane 5, Niejednoznaczne zapytanie. Oczekiwany jest albo numer telefonu albo numer usługi 6, Nierozpoznane źródło 7, Brak uprawnień do wykonywania operacji. Dana usługa nie jest usługą regulowaną 8, Nierozpoznana usługa 9, Niepoprawny numer telefonu użytkownika lub jego brak 111, Błędna data wygenerowania odpowiedzi 18, Nieprawidłowy numer sesji 12, Podmiot żądający nie jest zarejestrowany lub nie ma uprawnień 14, Nieprawidłowe dane przebiegu 15, Wybrany walidator nie posiada uprawnień do przeprowadzenia walidacji obiektu komunikatu) wejściowego 21, Nierozpoznany typ karty 20, Za długi wiersz 13, Niepoprawna grupa usług lub brak parametrów modelu dla zadanej grupy usług 19, Nierozpoznawalny numer 22, Nieprawidłowy kod weryfikujący. 23, Niepoprawna zmiana hasla. 24, Poprawna zmiana hasla. Kody NWT dla komunikatu WS: Id NWT Nazwa NWT Komunikat NWT w polu LINE_INFO Zidentyfikowano zaniżone parametry łącza. <br>usługa szerokopasmowa może nie uzyskać synchronizacji lub działać 1 NSP niestabilnie. 2 DUBLE_NA_DELTA Brak informacji NWT 3 BLAD_NA_DELTA Brak informacji NWT 4 BLAD_NA_PQ Brak informacji NWT 5 BLAD_APLIKACJI Brak informacji NWT Łącze zwielokrotnione (PCM).<br>Zidentyfikowano zaniżone parametry łącza. <br>usługa szerokopasmowa może nie uzyskać 6 PCM_NSP synchronizacji lub działać niestabilnie. UWAGA - Łącze cyfrowe.<br>zidentyfikowano zaniżone parametry łącza. <br>usługa szerokopasmowa może nie uzyskać synchronizacji 7 ISDN_NSP lub działać niestabilnie. Brak możliwości świadczenia usługi szerokopasmowej - zbyt duża tłumienność. <br>zidentyfikowano zaniżone parametry łącza. <br>usługa szerokopasmowa może nie uzyskać synchronizacji lub 8 DUZA_TLUMIENNOSC_NSP działać niestabilnie. Brak węzła świadczącego usługę DSL.<br>Zidentyfikowano zaniżone parametry łącza. <br>usługa szerokopasmowa może nie uzyskać 9 BRAK_DSL_NSP synchronizacji lub działać niestabilnie. 10 SRDA Łącze nie jest naturalnym torem miedzianym 11 PCM Łącze zwielokrotnione (PCM) 12 NMT Łącze nie jest naturalnym torem miedzianym 13 ISDN UWAGA - Łącze cyfrowe Brak możliwości świadczenia usługi szerokopasmowej - zbyt duża 14 DUZA_TLUMIENNOSC tłumienność 15 NIE_ZESTAWIONE Brak wymaganych danych do wykonania prekwalifikacji { PAGE 1713

14 16 BRAK_DSL Brak węzła świadczącego usługę DSL 17 BRAK_M_WEZLA Węzeł nie posiada możliwości świadczenia wybranej usługi 18 DEFAULT Nieznane NWT 19 SAT Łącze nie jest naturalnym torem miedzianym { PAGE 1714

15 7 Specyfikacja komunikatów wejściowych i wyjściowych Format komunikatów wejściowych i wyjściowych opisuje WSDL załączony poniżej: PrequalificationServic ewsoaimpl.xml <definitions name='prequalificationservicewsoaimplservice' targetnamespace='http://www.tp.pl/checkoa' xmlns='http://schemas.xmlsoap.org/wsdl/' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' xmlns:tns='http://www.tp.pl/checkoa' xmlns:xsd='http://www.w3.org/2001/xmlschema'> { PAGE 1715

16 <xs:schema targetnamespace='http://www.tp.pl/checkoa' version='1.0' { PAGE 1716

17 { PAGE 1717

18 <xs:element name='checkvalidationexception' type='tns:checkvalidationexception'/> <xs:element name='line_service_input' nillable='true' type='tns:line_service_input'/> <xs:element name='line_service_output' nillable='true' type='tns:line_service_output'/> <xs:complextype name='line_service_input'> <xs:element name='msg_header' type='tns:msg_header'/> <xs:element maxoccurs='unbounded' minoccurs='0' name='line_service_query' type='tns:line_service_query'/> <xs:element minoccurs='0' name='query_agreement' type='xs:boolean'/> <xs:element minoccurs='0' name='msg' type='xs:string'/> <xs:complextype name='msg_header'> <xs:element name='subject_id' type='xs:string'/> <xs:element name='dest_subject_id' type='xs:string'/> <xs:element minoccurs='0' name='test_ver' type='xs:int'/> <xs:complextype name='line_service_query'> <xs:element name='generate_date' type='xs:datetime'/> <xs:element name='line_service_query_element' type='tns:line_service_query_element'/> <xs:complextype name='line_service_query_element'> <xs:element name='query_id' type='xs:string'/> <xs:element name='number' type='xs:string'/> <xs:element name='service_id' type='xs:string'/> <xs:element name='service_symbol' type='xs:string'/> <xs:complextype name='line_service_output'> <xs:element name='msg_header' type='tns:msg_header'/> <xs:element name='line_service_query_result' type='tns:line_service_query_result'/> <xs:element maxoccurs='unbounded' minoccurs='0' name='line_service_query_result_parameters_elements' type='tns:parameters_element'/> <xs:element name='result' type='tns:result'/> <xs:complextype name='line_service_query_result'> <xs:element name='generate_date' type='xs:datetime'/> <xs:element name='line_service_query_result_element' type='tns:line_service_query_result_element'/> <xs:complextype name='line_service_query_result_element'> <xs:element name='query_id' type='xs:string'/> <xs:element name='number' type='xs:int'/> <xs:element name='service_id' type='xs:string'/> <xs:element name='city_name' type='xs:string'/> <xs:element name='service_type' type='xs:string'/> <xs:element name='service_symbol' type='xs:string'/> <xs:complextype name='parameters_element'> { PAGE 1718

19 <xs:element maxoccurs='unbounded' minoccurs='0' name='parameters_element' type='tns:item_element'/> <xs:complextype name='item_element'> <xs:element name='attr_id' type='xs:string'/> <xs:element minoccurs='0' name='attr_name' type='xs:string'/> <xs:element name='attr_value' type='xs:string'/> <xs:complextype name='result'> <xs:element name='result_code' type='xs:integer'/> <xs:element minoccurs='0' name='msg' type='xs:string'/> <xs:complextype name='checkvalidationexception'> <xs:element name='errorcode' type='xs:int'/> <xs:element minoccurs='0' name='message' type='xs:string'/> </xs:schema> </types> <message name='checkvalidationexception'> <part element='tns:checkvalidationexception' name='checkvalidationexception'></part> </message> <message name='checkporttypesoapoa_sendquery'> <part element='tns:line_service_input' name='lineservicequery'></part> </message> <message name='checkporttypesoapoa_sendqueryresponse'> <part element='tns:line_service_output' name='lineservicequeryresponse'></part> </message> <porttype name='checkporttypesoapoa'> <operation name='sendquery' parameterorder='lineservicequery'> <input message='tns:checkporttypesoapoa_sendquery'></input> <output message='tns:checkporttypesoapoa_sendqueryresponse'></output> <fault message='tns:checkvalidationexception' name='checkvalidationexception'></fault> </operation> </porttype> <binding name='checkporttypesoapoabinding' type='tns:checkporttypesoapoa'> <soap:binding style='document' transport='http://schemas.xmlsoap.org/soap/http'/> <operation name='sendquery'> <soap:operation soapaction='/sendquery'/> <input> <soap:body use='literal'/> </input> <output> <soap:body use='literal'/> </output> <fault name='checkvalidationexception'> <soap:fault name='checkvalidationexception' use='literal'/> </fault> </operation> </binding> <service name='prequalificationservicewsoaimplservice'> <port binding='tns:checkporttypesoapoabinding' name='checkporttypesoapoaport'> <soap:address location='http://localhost/check-checkejb/prequalificationservicewsoaimpl'/> { PAGE 1719

20 </port> </service> </definitions> { PAGE 1720