Model wymiany danych dla Infrastruktura Wersja dokumentu 0.8-1-2.7 Status Zamrożony Data wdrożenia 1Q 2012 1
Spis treści 1. Dokumenty powiązane...11 2. Słownik pojęć...11 3. Zasady komunikacji...12 3.1. Mapowanie danych biznesowych na komunikaty techniczne...12 3.2. Schemat komunikacji...12 3.2.1. Przesyłanie plików...15 3.3. Kanały komunikacyjne...16 3.3.1. Format komunikatu...16 3.3.2. Kanał WebService...17 3.3.2.1. Dane konfiguracyjne kanału...17 3.3.2.2. Specyfikacja techniczna kanału...17 3.3.2.3. Sposób przesyłania komunikatów w kanale...17 3.3.2.4. Zasady bezpieczeństwa przesyłu danych w kanale...18 3.4. Kanał WWW...19 3.4.1.1. Dane konfiguracyjne kanału...19 3.4.2. Specyfikacja postaci pliku z komunikatami...19 3.4.3. Podgląd historii komunikacji...19 4. Typy danych...20 4.1. Typy podstawowe:...20 4.2. Pola...20 4.2.1. ID (Business Case Number)...20 4.2.2. BOOLEAN...21 4.2.3. PHONE-NUMBER...21 4.2.4. OA...21 4.2.5. BASKET-ID...21 4.2.6. SERVICE-ID...21 4.2.7. ORDER-NUMBER...21 4.2.8. PHONE-RANGE...21 4.2.9. NIP...21 4.2.10. REGON...21 4.2.11. KRS...21 4.2.12. IP-ADDRESS...22 5. Techniczna specyfikacja rekordów...23 5.1. MSG-HEADER...23 5.2. PERIOD...24 5.3. TIME-SLOT...24 5.4. ADDRESS...24 5.5. PERSON2...24 5.6. DOCUMENT...25 5.7. ATTACHMENT...25 5.8. ADDRESS-LOC...25 5.9. REASON-DESCRIPTION...25 5.10. LINK-TERMINATION-A2...25 5.11. DDF-ADDRESS-IN-TP...25 5.12. LINK-TERMINATION-B2...26 2
5.13. ORDERED-LINKS...26 5.14. REMOVED-LINKS...26 5.15. DEVICE-INSTALLATION2...26 5.16. RACK-DIMENSION...27 5.17. EQUIPMENT...27 5.18. POWER-SUPPLY...27 5.19. TRANSMISSION2...27 5.20. DDF-DISTRIBUTION-FRAME2...28 5.21. RA...28 5.22. LINKS-DIRECTION-CHANGE...28 5.23. ROUTING...29 5.24. DEVICE-IN-NEW-RACK...29 5.25. DEVICE-IN-INSTALLED-RACK...29 5.26. DEVICE-IN-OTHER-OPERATOR-RACK...29 5.27. DEVICE-IN-TP-RACK...29 5.28. RACK-TYPE-DESC...30 5.29. OTHER-OPERATOR-RACK-TYPE...30 5.30. DEVICE-WIRING...30 5.31. DEVICE-CONNECTION...30 5.32. DEVICE-CONNECTION-TO-OTHER-OPERATOR...31 5.33. ADD-AO-RACK...32 5.34. REMOVE-AO-RACK...32 5.35. RACK-OTHER-OPERATOR...33 5.36. ADD-AO-DEVICE-SHARED-MODE...33 5.37. REMOVE-AO-DEVICE-SHARED-MODE...33 5.38. ADD-AO-DEVICE-WIRING...33 5.39. REM-AO-DEVICE-WIRING...34 5.40. REMOVE-DEVICE-CONNECTION...34 5.41. DEVICE-ADDRESS-SITE-A...34 5.42. DEVICE-ADDRESS-SITE-B...35 5.43. ATM-PARAMETERS...35 5.44. OA-DETAILS...35 5.45. PERSON-IDENTITY...35 5.46. ADD-REM-ADDITIONAL-SERVICE...36 5.47. POWER-SUPPLY-SPECIFICATION...36 5.48. DDF-PCO-OR-PMO-SPECIFICATION...36 5.49. ODF-PCO-SPECIFICATION...37 5.50. VP-PARAMETERS...37 5.51. LOCATION-ADDRESS...37 5.52. PERSON...38 5.53. REASON...38 5.54. PDU-PARAMETERS...38 5.55. END-A...38 5.56. END-B...38 5.57. LINKS...39 5.58. LINKS-ALL...39 5.59. DISTRIBUTION-FRAME-ODF...39 5.60. CABLE...39 5.61. ATM-ACCESS-LEVEL...40 5.62. IP-ACCESS-LEVEL...40 5.63. FAULT...40 3
5.64. TERMINATION A...41 5.65. LINK-TERMINATION-B...41 5.66. BUNDLE-PURPOSE...41 5.67. LINK-ORDER...42 5.68. ANNEXATION...42 5.69. NUMBERING-RANGE...43 5.70. TRANSMIT-DEVICE...43 5.71. CABLE2...43 5.72. DEVICE-INSTALLATION...44 5.73. TRANSMISSION...44 5.74. CIC-NUMBERS...45 5.75. SERVICE...45 5.76. LINKS-DIRECTION...46 5.77. ROUTING...46 5.78. SHARE...46 5.79. DDF-DISTRIBUTION-FRAME...46 5.80. BUNDLE-BILLING...46 5.81. LINK-TERMINATION-A...47 6. Tabele danych biznesowych...47 7. Specyfikacja komunikatów...54 7.1. ABORT...54 7.2. ACK...55 7.3. MASS-FAILURE...55 7.4. MASS-FAILURE-STATUS...56 7.5. CONF-REM-MASS-FAILURE...57 7.6. WORK-PLANNED...58 7.7. WORK-PLANNED-MAINTENANCE-FILES...59 7.8. WORK-PLANNED-MAINTENANCE...60 7.9. COMPLAINT-FINANCIAL-BSA-LPA...61 7.10. COMPLAINT-FINANCIAL-BSA-LPA-RESULT...62 7.11. COMPLAINT-FINANCIAL-BSA-PDU...63 7.12. COMPLAINT-FINANCIAL-BSA-PDU-RESULT...64 7.13. COMPLAINT-FINANCIAL-LLU-LPA...65 7.14. COMPLAINT-FINANCIAL-LLU-LPA-RESULT...66 7.15. COMPLAINT-FINANCIAL-LLU...67 7.16. COMPLAINT-FINANCIAL-LLU-RESULT...69 7.17. COMPLAINT-FINANCIAL-WLR...70 7.18. COMPLAINT-FINANCIAL-WLR-RESULT...70 7.19. COMPLAINT-FINANCIAL-BILLING-DATA...71 7.20. COMPLAINT-FINANCIAL-BILLING-DATA-RESULT...72 7.21. COMPLAINT-FINANCIAL-INTERCONNECT...73 7.22. COMPLAINT-FINANCIAL-INTERCONNECT-RESULT...74 7.23. COMPLAINT-FINANCIAL-INFRASTRUCTURE...74 7.24. COMPLAINT-FINANCIAL-INFRASTRUCTURE-RESULT...75 7.25. ORDER-CORR-CABLE...76 7.26. FINANCIAL-COMPLAINT-NFV...77 7.27. NFV...77 7.28. PFV...78 7.29. TV-ACCEPTANCE...78 7.30. ORDER-CANCELED...79 7.31. VP-ORDER...79 4
7.32. VP-ORDER-REJECTED...80 7.33. VP-ORDER-ACCEPTED...80 7.34. VP-WT...81 7.35. VP-ORDER-CANCELLATION...81 7.36. VP-ORDER-REALIZATION-REMARK...82 7.37. VP-ORDER-FINISH...82 7.38. CORR-CABLE-DELIVERY-PROTOCOL...82 7.39. ORDER-CORR-CABLE-DEINSTALL...83 7.40. ORDER-INSTALLATION-STATUS...84 7.41. ORDER-SPLITTER-INSTALLATION...84 7.42. SPLITTER-DEINSTALLATION-NOTIFICATION...85 7.43. BUILDING-ACCESS-PERMISSION-REQUEST...86 7.44. BUILDING-ACCESS-PERMISSION-RESPONSE...86 7.45. BUILDING-ACCESS-REQUEST...87 7.46. BUILDING-ACCESS-ACCEPTED...87 7.47. BUILDING-ACCESS-CHANGE...88 7.48. BUILDING-ACCESS-END...88 7.49. ORDER-COLLOCATION...89 7.50. ORDER-MODIFY-COLLOCATION...90 7.51. ORDER-COLLOCATION-PFV...92 7.52. COLLOCATION-TV-RESULT...93 7.53. APPLICATION-FAILURE...96 7.54. APPLICATION-FAILURE-REM-DATE...97 7.55. NO-FAILURE-INFO...97 7.56. ADDITIONAL-INFO-REQ...97 7.57. ADDITIONAL-INFO-RES...97 7.58. APPLICATION-FAILURE-REM-NEW-DATE...98 7.59. APPLICATION-FAILURE-REQ-CLOSED...98 7.60. REQ-CLOSED-ACCEPTANCE...98 7.61. REQUEST-CANCELLATION...99 7.62. REQUEST-CANCELLATION-CONFIRMATION...99 7.63. FAILURE-END...99 7.64. FAILURE-END-CONFIRMATION...99 7.65. WORK-PLANNED-IN-INFORMATION-SYSTEMS...100 7.66. FINANCIAL-SECURITY-AMOUNT...101 7.67. FINANCIAL-SECURITY-REQ...101 7.68. FINANCIAL-SECURITY-AMOUNT-EXPLANATION...102 7.69. FINANCIAL-SECURITY-AMOUNT-CHANGE-PROPOSAL...102 7.70. FINANCIAL-SECURITY-AMOUNT-CHANGE-RESPONSE...103 7.71. FINANCIAL-SECURITY-STATUS...103 7.72. ORDER-PDU-NFV...104 7.73. ORDER-PDU-FULL-NFV...104 7.74. ORDER-PDU-SPLITTER-ACCEPTED...105 7.75. ORDER-PDU-ACCEPTED...105 7.76. ORDER-PDU-ACCEPTED-RIO...106 7.77. ORDER-EXIST-PSS...106 7.78. ORDER-PDU-COLOCATION-TV...108 7.79. ORDER-TV-STATUS...111 7.80. TECHNICAL-PROJECT-RECEIVE...112 7.81. TECHNICAL-PROJECT-ACCEPTANCE...112 7.82. TECHNICAL-PROJECT-PROLONGATION...113 5
7.83. COLLOCATION-AGREEMENT...113 7.84. COLLOCATION-AGREEMENT-PROLONGATION...114 7.85. COLLOCATION-AGREEMENT-SIGNED...114 7.86. ORDER-COLLOCATION-REALIZATION-DATE...115 7.87. ORDER-COLLOCATION-INSTALLATION-DATE...115 7.88. ORDER-COLLOCATION-DELIVERY-PROTOCOL-SIGNED...116 7.89. ORDER-COLLOCATION-DELIVERY-PROTOCOL-CONFIRM...116 7.90. ORDER-COLLOCATION-DELIVERY-PROTOCOL-REMARKS...116 7.91. ORDER-COLLOCATION-DELIVERY-PROTOCOL-ACCEPTANCE...117 7.92. COLLOCATION-INTERVENTION...118 7.93. COLLOCATION-INTERVENTION-CHANGE...118 7.94. NFV-FULL...119 7.95. NFV-REQUEST-FULL...119 7.96. COLLOCATION-INTERVENTION-DATE...120 7.97. COLLOCATION-INTERVENTION-PROTOCOL...120 7.98. OA-SERVICES-FORECAST...121 7.99. PROMPTED-TP...121 7.100. FORECAST-NFV...122 7.101. TP-FORECAST...122 7.102. COLLOCATION-ASSISTANCE...123 7.103. COLLOCATION-ASSISTANCE-CHANGE...123 7.104. COLLOCATION-ASSISTANCE-DATE...124 7.105. COLLOCATION-ASSISTANCE-FINAL...124 7.106. COLLOCATION-ACCEPTANCE...124 7.107. COLLOCATION-ACCEPTANCE-CHANGE...125 7.108. COLLOCATION-ACCEPTANCE-DATE...126 7.109. COLLOCATION-ACCEPTANCE-PROTOCOL...126 7.110. COLLOCATION-DEINSTALLATION...126 7.111. COLLOCATION-DEINSTALLATION-DATE-ACCEPTANCE...127 7.112. COLLOCATION-DEINSTALLATION-DATE-ALTERNATIVE...128 7.113. COLLOCATION-DEINSTALLATION-NEW-DATE-ACCEPTANCE...128 7.114. COLLOCATION-DEINSTALLATION-REMINDER...129 7.115. COLLOCATION-DEINSTALLATION-PROTOCOL...129 7.116. ORDER-CANCELLED-RELEASE...129 7.117. ORDER-PDU-COST-ESTIMATION...130 7.118. ORDER-PDU-COST-ESTIMATION-ACCEPTANCE...131 7.119. ORDER-PDU-COST-ESTIMATION-REMARKS...131 7.120. ORDER-PDU-COST-ESTIMATION-REMARKS-ACCEPTANCE...132 7.121. ORDER-DATE-ACCEPTANCE...132 7.122. CORR-CABLE-REALIZATION-DATE...133 7.123. ASSISTANCE-DATE...133 7.124. PROVIDE-AS-BUILT-DOCUMENTATION...134 7.125. AO-DEVICES-READY-TO-RECEIVE...134 7.126. COMMISSIONING-DATE...135 7.127. NO-PERMISSION-FOR-DEVICES...135 7.128. REMARKS-TO-AS-BUILT-DOCUMENTATION...135 7.129. SUK-ANNEX...136 7.130. SIGNED-SUK-ANNEX-BY-AO...136 7.131. SURVEILLANCE-APPLICATION...136 7.132. OA-POSITION-IN-TV...137 7.133. SUK-ACCEPTANCE...138 6
7.134. ATTACHMENTS...138 7.135. PDU-ORDER...138 7.136. PDU-ORDER-TO-OPER...139 7.137. PDU-ORDER-TO-OPER-ACC...140 7.138. PDU-ORDER-STATUS...140 7.139. PDU-ORDER-FINISH-TO-OPER...141 7.140. PDU-ORDER-FINISH-TO-OPER-ACC...141 7.141. PDU-ORDER-FINISH-STATUS...141 7.142. PDU-MODIFICATION-ORDER...142 7.143. PDU- MODIFICATION-ORDER-TO-OPER...143 7.144. PDU- MODIFICATION-ORDER-TO-OPER-ACC...143 7.145. PDU- MODIFICATION-ORDER-INFO...143 7.146. PDU-MODIFICATION-ORDER-STATUS...144 7.147. PDU-MIGRATION-ORDER...144 7.148. PDU-MIGRATION-ORDER-TO-OPER...145 7.149. PDU-MIGRATION-ORDER-TO-OPER-ACC...145 7.150. PDU-MIGRATION-ORDER-STATUS...145 7.151. MESSAGE-ACK...145 7.152. PSS-ORDER...146 7.153. PSS-ORDER-STATUS...148 7.154. PSS-ORDER-TO-OPER...148 7.155. PSS-ORDER-TO-OPER-ACC...149 7.156. PSS-ORDER-FINISH-STATUS...149 7.157. PSS-ORDER-FINISH-TO-OPER...150 7.158. PSS-ORDER-FINISH-TO-OPER-ACC...150 7.159. LPSS-TEST-ORDER-TO-OPER...150 7.160. LPSS-TEST-ORDER-TO-OPER-ACC...151 7.161. LPSS-TEST-ORDER-INFO...152 7.162. LPSS-TEST-ORDER-STATUS...152 7.163. LPSS-COMMERCIAL-START-TO-OPER...153 7.164. LPSS-COMMERCIAL-START-TO-OPER-ACC...153 7.165. LPSS-COMMERCIAL-START-STATUS...153 7.166. LPSS-COMMERCIAL-PROTOCOL-STATUS...154 7.167. PSS-REDUCTION-ORDER...154 7.168. PSS-REDUCTION-ORDER-STATUS...157 7.169. PSS-REDUCTION-ORDER-TO-OPER...157 7.170. PSS-REDUCTION-ORDER-TO-OPER-ACC...158 7.171. LPSS-MODIFICATION-ORDER...158 7.172. LPSS-MODIFICATION-STATUS...159 7.173. LPSS-NUMBERING-ORDER...160 7.174. LPSS-NUMBERING-ORDER-STATUS...161 Słowniki...161 7.175. TEST-VER...161 7.176. STATE...162 7.177. SERVICE-TYPE...162 7.178. WP-STATUS-INFRASTRUCTURE...162 7.179. WP-STATUS-INFRASTRUCTURE2...162 7.180. WP-STATUS...163 7.181. WP-MSG-TYPE...163 7.182. CORR-CABLE-TYPE...163 7.183. TV-STATUS...164 7
7.184. FINANCIAL-COMPLAINT-TYPE...164 7.185. COMPLAINED-PRODUCT...164 7.186. COLLOCATION-TYPE...165 7.187. PDU-TYPE...165 7.188. STREET-TYPE...165 7.189. CABLE-TYPE...165 7.190. CHANGES-FPSS...166 7.191. CONNECTION-MODE...166 7.192. CHANGES-IN-PDU...166 7.193. TRAFFIC-TYPE...166 7.194. LINK-DIRECTION...167 7.195. RIO-SERVICE-TYPE...167 7.196. OPERATIONS-ON-BUNDLES...167 7.197. REJECTION-CODES...168 7.198. REJECTION-CODES-NFV...168 7.199. RACK-OWNER...168 7.200. LINE-STATUS-MF...168 7.201. INTERVENTION-MODE...169 7.202. FAILURE-SERVICE-TYPE...169 7.203. MF-WP-STATUS...169 7.204. ACCEPTANCE-STATUS...169 7.205. ACCESS-LEVEL-PDU...170 7.206. LINK-TYPE...170 7.207. CHANGE-TYPE...170 7.208. COMPLAINED-SERVICE-TYPE...171 7.209. ABORT-REASON...171 7.210. VI...173 7.211. ACC-STATUS...173 7.212. COMPLAINT-CHARGE-TYPE...173 7.213. COMPLAINT-WLR-CHARGE-TYPE...174 7.214. STM-PORT-TYPES...174 7.215. LLU-ACCESS-TYPE...174 7.216. LINE-STATUS...174 7.217. COMPLAINED-LLU-SERVICE-TYPE...174 7.218. VOICE-ACCESS-TYPE...174 7.219. CALL-TYPE...175 7.220. RACK-TYPE...175 7.221. RACK-DEPTH...175 7.222. COLLOCATION-SERVICE-TYPE...175 7.223. PDU-ORDER-MODE...175 7.224. COLOCATION-MODE...176 7.225. SETTLEMENT-MODEL...176 7.226. TRAFFIC-MODE...176 7.227. PROCESSING-PERIOD...176 7.228. SUBLINK-TYPE...177 7.229. COST-ESTIMATE-TYPE...177 7.230. DOC-TYPE...177 7.231. ORDER-CANCEL...177 7.232. CONFIRMATION-SCOPE...178 7.233. VALID-PERIOD...178 7.234. COLOCATION-TYPE...178 8
7.235. COMPLAINT-NFV...178 7.236. WLR-FINANCIAL-RESULT...179 7.237. LLU-FINANCIAL-RESULT...179 7.238. BSA-FINANCIAL-RESULT...180 7.239. EVENT-TYPE...181 7.240. BUILDING-ACCESS-PERMISSION...181 7.241. BUILDING-ACCESS-OBJECTIVE...181 7.242. CABLE-LINE-TYPE...182 7.243. CABLE-INSERTION-POINT...182 7.244. POZIOM DOSTĘPU...182 7.245. POZIOM DOSTĘPU ATM...182 7.246. TYP INTERFEJSU PDU...182 7.247. REALIZACJA PDU...182 7.248. RODZAJ WŁÓKIEN...182 7.249. RODZAJ KABLA...183 7.250. ROLA...183 7.251. KLASA RUCHU...183 7.252. TYP REKLAMACJI...183 7.253. WYNIK ROZPATRZENIA REKLAMACJI...183 7.254. PDU-ORDER-TO-OPER...183 7.255. PDU-ORDER-STATUS...183 7.256. PDU-ORDER-FINISH-TO-OPER-ACC...184 7.257. PDU-ORDER-FINISH-STATUS...184 7.258. PDU-MODIFICATION-ORDER-STATUS...184 7.259. PDU-MIGRATION-ORDER-STATUS...184 7.260. COMLAIN-STATUS...184 7.261. PDU-ORDER-MODE...184 7.262. POŁĄCZENIE SIECI...184 7.263. TYP RUCHU...185 7.264. ZMIANY FPSS...185 7.265. ZMIANY LPSS...185 7.266. KIERUNEK WIĄZKI...185 7.267. USŁUGI...185 7.268. OPERACJE...185 7.269. PRĘDKOŚĆ ŁĄCZA...186 7.270. WNIOSEK NUMERACJA...186 7.271. SZAFA...186 7.272. RODZAJ KABLA...Błąd! zdefiniowano zakładki. 7.273. RODZAJ MODYFIKACJI...186 7.274. RODZAJ USŁUGI...186 7.275. POWÓD...186 7.276. REKLAMOWANY PRODUKT...188 7.277. WYNIK ROZPATRZENIA REKLAMACJI jest...błąd! zdefiniowano zakładki. 7.278. ROLA...188 7.279. PSS-ORDER-STATUS...188 7.280. PSS-ORDER-FINISH-STATUS...188 7.281. PSS-ORDER-FINISH-TO-OPER-ACC...188 7.282. LPSS-TEST-ORDER-TO-OPER...189 7.283. LPSS-TEST-ORDER-TO-OPER-ACC...189 7.284. LPSS-TEST-ORDER-STATUS...189 7.285. LPSS-COMMERCIAL-START-STATUS...189 9
7.286. PSS-REDUCTION-ORDER-STATUS...189 7.287. PSS-REDUCTION-ORDER-TO-OPER-ACC...189 7.288. LPSS-MODIFICATION-STATUS...189 7.289. LPSS-NUMBERING-ORDER-STATUS...189 7.290. FAULT-STATUS...190 7.291. FAULT-TO-OPER-STATUS...190 7.292. FAULT-ACC-STATUS...190 7.293. COMPLAIN-STATUS...190 7.294. PSS-ORDER-MODE...190 7.295. Rodzaj WMŁ...190 7.296. TYP NUMERACJI...191 7.297. SPOSÓB ROZLICZENIA...191 7.298. RODZAJ RUCHU...191 7.299. POCZĄTEK SIECI SZKIELETOWEJ...191 10
1. Dokumenty powiązane [1] L.p. Wersja Data MWD Procesy (Infrastruktura) dla Modelu Współpracy Międzyoperatorskiej zgodny z Ofertą Ramową (SOR) 2011-05-31 2. Słownik pojęć Awaria Pojęcie Awaria masowa Łącze Abonenckie Łącze Abonenckie Aktywne (ŁAA) Łącze Abonenckie aktywne (ŁAN) PP Dzień Roboczy (DR) Przedsiębiorca Telekomunikacyjny (PT), Operator alternatywny, Operator korzystający Siła wyższa Stan techniczny sieci telekomunikacyjnej lub jej elementów związany z nieprawidłowym ich działaniem, uniemożliwiający lub poważnie ograniczający świadczenie Usługi. Opis Awaria uniemożliwiająca lub poważnie ograniczająca świadczenie usług dla Abonentów TP lub PT znajdujących się w zasięgu działania przynajmniej jednego węzła sieci telekomunikacyjnej, wynikająca z tego samego zdarzenia; nie dotyczy sytuacji spowodowanej Pracami Planowymi w sieci. Obwód składający się z odcinków sieci magistralnej i rozdzielczej oraz Przyłącza Abonenckiego albo bez Przyłącza Abonenckiego, łączący Zakończenie sieci bezpośrednio z punktem dostępu do stacjonarnej publicznej sieci telekomunikacyjnej w szczególności z PG lub równoważnym urządzeniem stanowiącym punkt dostępu do Sieci TP. Wyróżniamy Łącze Abonenckie Aktywne i Łącze Abonenckie aktywne Łącze Abonenckie wraz z Przyłączem Abonenckim, na którym TP świadczy Usługę Abonencką lub Usługę Regulowaną Łącze Abonenckie, na którym TP nie świadczy Usług Abonenckich lub Usług Regulowanych wraz z oznaczeniem czy dane łącze posiada Przyłącze Abonenckie lub nie posiada Przyłącza Abonenckiego Prace Planowe działania utrzymaniowe TP niezbędne dla zapewnienia prawidłowej eksploatacji infrastruktury telekomunikacyjnej TP. Każdy dzień tygodnia, poza sobotami, niedzielami i innymi dniami ustawowo uznanymi za wolne od pracy w Rzeczypospolitej Polskiej, Przedsiębiorca lub inny podmiot uprawniony do wykonywania działalności gospodarczej na podstawie Ustawy, który wykonuje działalność gospodarczą polegającą na dostarczaniu sieci telekomunikacyjnych, udogodnień towarzyszących lub świadczeniu usług telekomunikacyjnych, z wyłączeniem TP. Zdarzenie zewnętrzne o charakterze nadzwyczajnym niezależne od Strony, któremu nie można zapobiec przy dołożeniu najwyższych staranności, a w szczególności: wojna a w tym: wojna domowa, zamieszki, akty sabotażu, rozruchy, katastrofy naturalne np. burze, huragany, trzęsienia ziemi, powodzie. 11
3. Zasady komunikacji 3.1. Mapowanie danych biznesowych na komunikaty techniczne Dokument [1] opisuje zakres danych przesyłanych pomiędzy aktorami procesu w danym kroku. Niniejszy dokument przedstawia w jaki sposób dany zakres informacyjny ma zostać przesłany pomiędzy systemami informatycznymi. Stąd przy każdym komunikacie wyróżniono numer oraz nazwę rozdziału w dokumencie [1]. Zapis ten pozwoli połaczyć techniczną specyfikację komunikatów na kroki poszczególnych procesów. Przy tworzeniu nazw komunikatów przyjęto nastepującą konwencję nazewniczą -STATUS- Sufiks Rozwinięcie (ang.) Znaczenie -FV formal verification Wynik weryfikacji formalnej Komunikat jest informacją statusie zlecenia/zamówienia lub informuje o jego wyniku. -NFV negative formal verification Negatywny wynik weryfikacji formalnej -PTV positive technical verification Pozytywny wynik weryfikacji technicznej -NTV negative technical verification Negatywny wynik weryfikacji technicznej 3.2. Schemat komunikacji Komunikacja w ramach MWD jest realizowana zawsze wg tego samego schematu. Dane wspólne dla wszystkich komunikatów wydzielono do nagłówka MSG-HEADER. Komunikaty wymieniane w ramach jednego procesu są powiązane poprzez pole order-number (Identyfikator zamówienia / zgłoszenia). W ramach pojedynczego procesu może dojść do wielu interakcji (wymiany danych). Pojedyncza interakcja składa się z wysłania odpowiedniego komunikatu przez nadawce oraz odebrania lub odrzucenia przez odbiorcę skorelowane przy pomocy pola interaction-id. 12
sd Model pojedynczej interakcji Nadawca Odbiorca komunikat(state=req) alt [niemożliwe odebranie komunikatu] ABORT(state=ABR) [komunikat niezgodny ze specyfikacją] ACK(state=ACK, acc-status=odrzucony) [komunikat poprawny] ACK(state=ACK, acc-status=przyjęty) Nadawca wysyła komunikat definiując następujące pola nagłówka: Pole interaction-id subject-id dest-subject-id order-number msg-ver test-ver state Znaczenie numer interakcji rozumiany jako wysłanie komunikatu oraz otrzymania potwierdzenia (komunikatu ACK). a para komunikatów posiada wspólny numer interakcji. Identyfikator interakcji (INTERACTION-ID) musi być unikalnym identyfikatorem wymiany danych w obrębie danego źródła komunikatu (Przedsiębiorcy telekomunikacyjnego). Identyfikator ten będzie liczbą całkowitą o długości maksymalnej 15 znaków [INT(15)]. Identyfikator nie musi zachowywać sekwencyjności numeracji. Wszystkie komunikaty niosące treść biznesową są sparowane z odpowiednim komunikatem potwierdzenia. Komunikat ABORT nie jest on w sensie ścisłym część interakcji w ramach której został wysłany, a jedynie sygnałem, że interakcja się nie powiodła. numer jednoznacznie identyfikujący nadawcę komunikatu poprzez numer pod jakim Operator figuruje w rejestrze przedsiębiorców telekomunikacyjnych UKE. Na potrzeby niniejszego modelu wymiany danych TP-Hurt będzie posiadała identyfikator 0 numer jednoznacznie identyfikujący odbiorcę komunikatu poprzez numer pod jakim Operator figuruje w rejestrze przedsiębiorców telekomunikacyjnych UKE. Na potrzeby niniejszego modelu wymiany danych TP-Hurt będzie posiadała identyfikator 0 numer oznaczający identyfikator zamówienia/zgłoszenia, dla komunikatów rozpoczynających proces numer musi być unikalny w ramach jednego PT pole określające zgodnie z którą wersją MWD przygotowany został komunikat. W wypadku komunikatów zgodnych z niniejszym MWD jego wartość będzie stała SOR 1.0i pole określające, czy komunikat jest komunikatem produkcyjnym czy testowym. Strony w wypadkach szczególnych dopuszczają możliwość wysyłania komunikatów testowych na środowisku produkcyjnym. Komunikat taki spowoduje odesłanie właściwego komunikatu potwierdzenia ACK jednak bez uruchamiania procesów biznesowych pole określające stan interakcji w ramach którego nastąpiło generowania komunikatu. Dopuszczalne wartości to REQ dla żądania, ACK dla potwierdzenia i ABR dla komunikatu. 13
Dodatkowa wartość ATTACHMENT jest wykorzystywana przy przesyłaniu plików (patrz 3.2.1) W przypadku gdy: 1. odbiorca nie jest w stanie odebrać/odczytać komunikatu (z powodu błędów krytycznych w strukturze wiadomości, niepoprawnego uwierzytelnienia nadawcy, awarii systemu, wyłączenia systemu na czas prac konserwacyjnych, wyłączenia kanału komunikacyjnego itp.) odpowiada nadawcy komunikatem ABORT 2. przesłany komunikat nie spełnia wymagań nakładanych na dany komunikat, w szczególności a) brakuje wymagalnych pól b) wartości pól są niezgodne z typem lub wartościami słownikowymi c) komunikat nie spełnia wyspecyfikowanych dla każdego komunikatu reguł odbiorca odpowiada komunikatem ACK z flagą acc-status=odrzucony oraz opisem błędu (pole rejection-reason-code) zgodnym ze słownikiem VI 3. w przeciwnym wypadku odbiorca odpowiada komunikatem ACK z flagą acc-status=przyjęty, który potwierdza dostarczenie komunikatu Komunikaty ABORT oraz ACK powinny posiadać identyczne pole interaction-id jak w komunikacie od nadawcy. Po otrzymaniu informacji o odrzuceniu wiadomości nadawca może ponownie wysłać poprawiony komunikat ale ze zmienioną wartością pola interaction-id. TP-Hurt weryfikuje wszystkie przychodzące komunikaty zgodnie z poniższym schematem: weryfikacja informatyczna przedwstępna (w przypadku niepowodzenia powoduje wysłanie komunikatu ABORT) o weryfikacja czy nadawca ma uprawnienia do komunikacji kanałem przychodzącym o weryfikacja czy komunikat jest możliwy do odszyfrowania i odczytania o weryfikacja czy komunikat posiada prawidłowe pole interaction-id. weryfikacja informatyczna (w przypadku niepowodzenia powoduje wysłanie komunikatu ACK z flagą acc-status=odrzucony) o weryfikacja wersji MWD oraz jej zgodności przesłanego komunikatu o weryfikacja czy komunikat posiada wymagane pola o weryfikacja czy pola komunikatu mają prawidłowy format techniczny o weryfikacja czy wskazane daty realizacji zamówienia/zlecenia spełniają warunki wyspecyfikowane w [1] weryfikacja formalna polega na sprawdzeniu poprawności danych biznesowych, w komunikacie zawsze jest poprzedzona wysłaniem komunikatu ACK z flagą acc-status=przyjęty. Ewentualne błędy sa zwracane jako osobny komunikat zdefiniowany w [1] W ramach pojedynczej interakcji istnieje możliwość przesłania tylko pojedynczego komunikatu. Specyfikacja nie umożliwia przesyłanie wielu komunikatów na raz (paczkowanie komunikatów). 14
3.2.1. Przesyłanie plików W przypadku, gdy polem komunikatu jest plik obowiązują następujące zasady jego przesyłania: 1. Pole w komunikacie zawierające nazwę pliku jest typu DOCUMENT 2. W ramach tej samej interakcji plik jest przesyłany osobnym komunikatem ATTACHMENTS przed lub po wysłaniu własciwego komunikatu, lecz z tym samym polem order-number oraz interaction-id w nagłówku MSG-HEADER 3. W ramach jednej interakcji odbiorca oczekuje na liczbę attachment-quantity komunikatów typu ATTACHMENTS oraz jeden komunikat biznesowy (state=req), po czym odsyła komunikat ACK potwierdzający poprawność wszystkich komunikatów w interakcji 4. Załączniki muszą być kodowane w standardzie BASE64 5. W polu checksum przesyłane jest też CRC, w celu zabezpieczenia przed błędami. CRC generowane funkcją SHA-1. 6. Rozmiar załączonego pliku nie może przekroczyć wartości konfiguracyjnej (obecnie 10MB). W przypadku większych plików, Nadawca musi podzielić plik korzystając ze standardu ZIP i wysyłać jako oddzielne paczki (osobne komunikaty) 7. Przewiduje się możliwość przesyłania następujących formatów plików PDF, JPG, RTF, DOC, TXT, XLS, TIFF. Przesyłanie innych formatów jest dozwolone natomiast jeśli ich odczytanie nie będzie możliwe przy użyciu oprogramowania wykorzystywanego przez Odbiorcę, załącznik nie będzie brany pod uwagę przy procesowaniu zlecenia. Odbiorca i nadawca mogą uzgodnić rozszerzoną listę obsługiwanych formatów. Poniższy rysunek pokazuje scenariusz przesłania pliku załącznika w dwóch paczkach. Wartości X, Y należy zastąpić wartościami liczbowymi zgodnie ze specyfikacją. Wartośc attachmentguantity informuje o ilości paczek natomiast attachment-number jest numerem konkretnej paczki. 15
sd Przesyłanie plików Nadawca Odbiorca ATTACHEMENTS(order-number=X, interaction-id=y, state=attachement, attachment-quantity=2, attachment-number=1) ATTACHEMENTS(order-number=X, interaction-id=y, state=attachement, attachment-quantity=2, attachment-number=2) komunikat(order-number=x, interaction-id=y, state=req, attachment-quantity=2) alt weryfikacja informatyczna [pozytywna] ACK(order-number=X, interaction-id=y, state=ack, acc_status=przyjęty) [negatywna] ACK(order-number=X, interaction-id=y, state=ack, acc_status=odrzucony) 3.3. Kanały komunikacyjne Komunikaty zdefiniowane w niniejszej secyfikacji mogą być przesyłane poprzez jeden z następujących kanały komunikacji WebService WWW Kanał WWW jest realizowany na infrastrukturze TP-Hurt. Kanał WebService wymaga od Przedsiębiorcy Telekomunikacyjnego zapewnienia własnej części infrastruktury niezbędnej do wymiany informacji. 3.3.1. Format komunikatu Komunikaty będą zapisane w stronie kodowej UTF-8. W celu umożliwienia kontroli postaci plików XML, TP przekaże Przedsiębiorcom Telekomunikacyjnym schematy XSD pozwalające na parsowanie zawartości komunikatów przed ich wysłaniem. Należy zaznaczyć, iż XML Schema nie pozwala na weryfikację wszystkich reguł zawartych w specyfikacji np. wymagalności pól w zależności od wartości innych pól. Są to ograniczenia samego standardu XML Schema. Dane konfiguracyjne XML dla komunikatów z zakresu: 7.1 7.134: root-tag Dana cbnp-message Wartość namespace nampespace (dla komunikatu ABORT) 1 http://www.tp.pl/cbnp/cbnp-xml-protocol/ver_6_0 http://www.tp.pl/cbnp/cbnp-xml-protocol/ver_4_1 1 Komunikat ABORT w nagłówku może nie posiadać pola interaction-id i/lub pola order-nmber (w przypadku, gdy w komunikacie przychodzącym tych informacji nie było). Stąd konieczność wprowadzenia osobnego namespace dla tego komunikatu. 16
Dla komunikatów z zakresu 7.135 7.180 obowiązuje specyfikacji konfiguracji XML z modelu ISI_3b. 3.3.2. Kanał WebService Kanał WebService udostępnia możliwość przesyłania komunikatów MWD w technologii WebService. 3.3.2.1. Dane konfiguracyjne kanału Do uruchomienia kanału konieczne są następujące dane konfiguracyjne Dostarczony przez TP-Hurt Specyfikacja WSDL Dana konfiguracyjna TP-Hurt i PT TP-Hurt i PT TP-Hurt I PT TP-Hurt i PT TP-Hurt URL pod jakim dostępny jest WebService certyfikat SSL serwera (wystawiany przez CC Signet) certyfikat SSL klienta (wystawiany przez CC Signet) dane kontaktowe do administratora systemu (imię i nazwisko, nr telefonu, adres e-mail) maksymalny rozmiar załącznika 3.3.2.2. Specyfikacja techniczna kanału Protokół Wersja/Specyfikacja komunikat MWD XML 1.0 kodowanie UTF-8 SOAP WS-I Basic Profile 1.1 / One-Way Operation HTTP metoda POST 1.1 Komunikaty będą przekazywane w trybie asynchronicznym zgodnie z zasadami komunikacji jednokierunkowej (One-Way Operation, komunikacja typu "push") zawartej w specyfikacji Basic Profile w wersji 1.1 opublikowaną przez Web Services Interoperability Organization (http://www.wsi.org/profiles/basicprofile-1.1.html). 3.3.2.3. Sposób przesyłania komunikatów w kanale Komunikaty MWD będą przesyłane w kanale uzupełnione o nagłówek SOAP. Sposób przesyłu SOAP został pokazany poniżej 17
sd Model komunikacji w kanale WebService Nadawca Odbiorca HTTP POST() alt autoryzacja [negatywna] HTTP 401 Anauthorized() [pozytywna] HTTP 200 OK() Nadawca przesyła komunikat SOAP do odbiorcy. Komunikat podlega autoryzacji nadawcy. W przypadku braku autoryzacji wysyłany jest komunikat HTTP 401 (bez koperty SOAP). W przypadku poprawnej transmisji komunikatu SOAP odbiorca odsyła nadawcy komunikat HTTP 200 (bez koperty SOAP). Oznacza on jedynie poprawne dostarczenie komunikatu. W kanale obowiązują nastepujące zasady oznacza poprawności samego komunikatu MWD. oznacza on także wysłania komunikatu ACK. i komunikat jest wysyłany jako nowy komunikat SOAP. W kanale obowiązują nastepujące zasady: - odpowiedź HTTP instancji serwisu nie może zawierać koperty SOAP, ani też innej treści (poza informacją statusową dotyczącą transmisji HTTP) - klient serwisu musi ignorować ewentualną kopertę SOAP przekazaną w odpowiedzi HTTP - klient serwisu nie może interpretować pomyślnego statusu transmisji HTTP (np. 200 bądź 202) jako uznanie komunikatu za prawidłowy czy też przyjęty do przetwarzania - żądania powinny być przekazywane do serwisu metodą POST - status przekazany w odpowiedzi HTTP ze strony serwisu oznaczający błąd oznacza błąd na poziomie transmisji i nie niesie informacji o ewentualnych błędach żądania SOAP - przyjmujemy, że w przypadku poprawnej transmisji HTTP serwis udzieli odpowiedzi ze statusem 200 - serwis będzie akceptował w nagłówku SOAP (soap:header) znaczniki Message-Id oraz In-Reply-To - komunikaty zawierające żądania (REQUEST) powinny zawierać w nagłówku SOAP (soap:header) znacznik Message-Id (zapewnienie unikalności w okresie miesiąca wydaje się dostateczne) - komunikaty zawierające potwierdzenia poprawności informatycznej (ACK) oraz odrzucenia (ABORT) powinny zawierać w nagłówku SOAP (soap:header) znaczniki Message-Id oraz In-Reply-To, przyczym znacznik In-Reply-To będzie zawierał wartość znacznika Message-Id dla odnośnego żądania 3.3.2.4. Zasady bezpieczeństwa przesyłu danych w kanale Kanał WebService wykorzystuje zabezpieczenie trasmisji danych poprzez zastosowanie protokołu HTTPS z uwierzytelnieniem po stronie serwera i stronie klienta. Do uwierzytelnienia będą wykorzystywane certyfikate wydane przez Centrum Certyfikacji Signet. 18
3.4. Kanał WWW Możliwe jest realizowanie komunikacji za pomocą strony WWW. W tym celu na serwerze TP przygotowane zostaną formatki umożliwiające składanie zgłoszeń (zamówień, reklamacji itp.). W kanale WWW możliwe będzie także odbieranie komunikatów wysyłanych do Przedsiębiorcy Telekomunikacyjego (wynik zlecenia). Ze względu na interakcyjny charakter takiej komunikacji nie wymaga ona tworzenia dedykowanych komunikatów w z góry ustalonym formacie. Zakłada się, że potwierdzeniem przyjęcia zgłoszenia będzie komunikat tekstowy pojawiający się na stronie WWW. 3.4.1.1. Dane konfiguracyjne kanału Do uruchomienia będą konieczne następujące dane konfiguracyjne Dostarczony przez TP-Hurt adres serwisu WWW Dana konfiguracyjna TP-Hurt TP-Hurt konto z uprawnieniami do tworzenia subkont certyfikat X.509 dla każdego użytkownika 3.4.2. Specyfikacja postaci pliku z komunikatami Kanał WWW udostepnia dodatkową funkcjonalność ręcznego ładowania plików z komunikatami. Stosowana przy tym będzie zasada, że w jednym pliku będzie jeden komunikat XML. Format nazwy pliku odpowiadał będzie następującemu szablonowi : [<identyfikator Przedsiębiorcy telekomunikacyjnego wg UKE>]www[INTERACTION-ID]<nazwa typu komunikatu>[<xml>] Przykładowa nazwa pliku : [99]www[123456]ZAMOWIENIE-MIGRACJA[xml] Załadowanie pliku jest równoznaczne z wypełnieniem formatki. Kanał WWW udostępnia takie same informacje o zleceniach wprowadzonych poprzez formatkę oraz zleceniach inicjowanych poprzez załadowanie pliku. 3.4.3. Podgląd historii komunikacji W wypadku komunikatów składanych przez kanał WWW nie przewiduje się generowania i odsyłania komunikatów zwrotnych. zależnie od kanału, którym będą składane komunikaty możliwe będzie za pośrednictwem dedykowanej strony zapoznanie się z komunikatami tak wysłanymi kanałem e-mail jak i wygenerowanymi lecz nie wysłanymi w kanale WWW. Możliwe będzie wygenerowanie pliku z taką historią w kontekście pojedynczego zamówienia/zgłoszenia. 19
Plik taki będzie miał domyślną nazwę historia.xml zaś jego zawartość będą stanowiły uszeregowane chronologicznie właściwe komunikaty XML bez oznaczeń tytułów przesyłek pocztowych lub nazw plików. 4. Typy danych Rozdział opisuje typy danych używane w komunikatach. 4.1. Typy podstawowe: Przyjmuje się następującą interpretację typów prostych danych: INT(n) DATE Typ Opis liczba całkowita, nieujemna, reprezentowana przez ciąg n znaków; zera wiodące są ignorowane Typ data zapisana zgodnie z specyfikacją typu xsd:date (http://www.w3.org/tr/xmlschema-2/). Typ datetime specyfikuje zapis daty oraz czasu. Zapis jest definiowany według następującego formatu: "YYYY-MM-DDThh:mm:ss", gdzie DATE-TIME YYYY - rok MM - miesiąc DD - m T rozpoczecie sekcji czasu hh - godzina mm - minuty ss - sekundy DECIMAL(n,m) TIME CHAR(n) FLOAT(n,m) swaref wartość liczbowa (dodatnia lub ujemna) zapisana zgodnie z z specyfikacją typu xsd:decimal (http://www.w3.org/tr/xmlschema-2/); parametry n,m określają format liczby Typ czas zgodnie ze specyfikacją xsd:time. Format hh:mm:ss.sss pole znakowe o długości od 1 do n znaków liczba rzeczywista zmiennoprzecinkowa; parametry n,m określają format liczby Wskazanie na załącznik wiadomości SOAP zgodnie z http://ws-i.org/profiles/basic/1.1/swaref.xsd 4.2. Pola Sekcja opisuje pola o specyficznej składni/formacie. 4.2.1. ID (Business Case Number) Identyfikator zamówienia/zgłoszenia/reklamacji itp. nadany przez operatora wysyłającego komunikat służący do identyfikacji sprawy. Identyfikator ten musi być unikalnym w skali spraw podnoszonych przez nadawcę. Pole o typie CHAR(15) w formacie XXXXXYYYYYYYYYY, pięć cyfr XXXXX będzie uzupełnionym o wiodące zera kodem operatora/przedsiębiorcy nadany przez UKE, a kolejne dziesięć cyfr będzie uzupełnionym o wiodące zera numerem sprawy danego operatora np. 000010000002323. 20