Návrh a implementace systému pro zřizování ADSL

M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

           0 1 
2 ./  ,  *+ !"#$ %&'()

Návrh a implementace systému pro zˇrizování ADSL D IPLOMOVÁ PRÁCE

Jan Holˇcapek

Brno, jaro 2005

Prohlášení fake: tady bude formular zadani diplomky

ii

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

iii

Podˇekování Dˇekuji vedoucímu své diplomové práce Mgr. Janu Kasprzakovi za ochotu vést práci, která se odehrávala a jejíž výsledek je používán v komerˇcní sféˇre. Dˇekuji pracovníkum ˚ a kolegum ˚ z firmy SkyNet, a. s., kteˇrí se podíleli na zavádˇení nového zpusobu ˚ zˇrizování DSL, jmenovitˇe Mgr. Janu Pazdziorovi za praktické rady pˇri samotné realizaci, technickému rˇ editeli Ing. Daliboru Šafáˇrovi, který mi umožnil spojit zamˇestnání s psaním diplomové práce, dále Ing. Martinˇe Neˇcasové, Mgr. Janu Polákovi a Ing. Petru Šedivému. Dˇekuji zástupcum ˚ operátoru˚ za svolení citovat údaje z jejich interních materiálu, ˚ jmenovitˇe Zdenku ˇ Müllerovi ze spoleˇcnosti Telenor Networks, s. r. o. a Stanislavu Hemrle ze ˇ spoleˇcnosti Ceský Telecom, a. s..

iv

Shrnutí Práce popisuje návrh a implementaci systému, který slouží jako prostˇredník v komuˇ nikaci mezi systémem firmy SkyNet, a. s. (provider), a systémy spoleˇcností Ceský Telecom, a. s., a Telenor Networks, s. r. o. (operátoˇri). Komunikace se odehrává zejména za úˇcelem zˇrizování DSL pˇripojení v rámci služby providera. Systém, který je produktem praktické cˇ ásti této diplomové práce, odstinuje ˇ systém providera od technických a významových rozdílu˚ na rozhraních systému˚ operátoru. ˚

v

Klíˇcová slova DSL pˇripojení, komunikace systému, ˚ objednávka, notifikace, stavová hláška

vi

Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Pˇripojení k Internetu skrze telefonní sít . . . . . . . . . 1.1.1 Vytáˇcené pˇripojení v PSTN síti . . . . . . . . . . 1.1.2 Vytáˇcené pˇripojení v ISDN síti . . . . . . . . . . 1.1.3 Rodina technologií DSL . . . . . . . . . . . . . . 1.2 Pronájem místní smyˇcky . . . . . . . . . . . . . . . . . . 1.3 Komunikace provideru˚ s operátory . . . . . . . . . . . . 1.4 Obsah a cˇ lenˇení dalšího textu . . . . . . . . . . . . . . . 2 Proces objednání DSL . . . . . . . . . . . . . . . . . . . . . . 2.1 Vymezení pojmu˚ . . . . . . . . . . . . . . . . . . . . . . 2.2 Výchozí stav . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Navrhované zmˇeny . . . . . . . . . . . . . . . . . . . . . 2.4 Shrnutí úkolu˚ nového systému . . . . . . . . . . . . . . 3 Návrh a implementace . . . . . . . . . . . . . . . . . . . . . . 3.1 Okolní systémy . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 OmniTracker . . . . . . . . . . . . . . . . . . . . ˇ 3.1.2 Systémy Ceského Telecomu a Telenor Networks 3.2 Celkový náhled na systém BlackBox . . . . . . . . . . . 3.3 Spoleˇcný pˇrístup k rˇ ešení úkolu˚ . . . . . . . . . . . . . . 3.3.1 Do one thing and do it well . . . . . . . . . . . . 3.3.2 Spuštˇení dávek naneˇcisto . . . . . . . . . . . . . 3.3.3 Použité nástroje . . . . . . . . . . . . . . . . . . . ˇ 3.3.4 Rešení bˇehových chyb . . . . . . . . . . . . . . . 3.4 Distribuce cˇ íselníku˚ . . . . . . . . . . . . . . . . . . . . . 3.4.1 Pˇrehled cˇ íselníku˚ . . . . . . . . . . . . . . . . . . 3.4.2 Zpusob ˚ pˇredávání . . . . . . . . . . . . . . . . . 3.5 Zjišt’ování dostupnosti DSL . . . . . . . . . . . . . . . . 3.5.1 Výstupy služeb operátoru˚ . . . . . . . . . . . . . 3.5.2 Dotazování na dostupnost DSL . . . . . . . . . . 3.6 Evidence komunikace s operátorem . . . . . . . . . . . 3.6.1 Tabulka service . . . . . . . . . . . . . . . . . . 3.6.2 Tabulka operation . . . . . . . . . . . . . . . . 3.6.3 Tabulka conversation . . . . . . . . . . . . . . 3.7 Fronta požadavku˚ na objednávky k operátorovi . . . . 3.8 Odesílání objednávek operátorovi . . . . . . . . . . . . 3.8.1 Fiktivní odeslání . . . . . . . . . . . . . . . . . . 3.8.2 Skuteˇcné odeslání . . . . . . . . . . . . . . . . . . 1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 4 5 5 5 6 7 8 9 9 9 11 16 18 18 18 18 19 20 20 20 21 22 22 23 23 26 26 29 32 33 33 34 34 37 39 40

O BSAH 3.9 Fronta objednávek cˇ ekajících na dostupné DSL . . . . . . 3.10 Pˇríjem notifikací o prubˇ ˚ ehu objednávky . . . . . . . . . . 3.10.1 Vzorová notifikace . . . . . . . . . . . . . . . . . . 3.10.2 Mapování stavu˚ notifikací na stavové hlášky . . . 3.11 Upozornování ˇ na dlouho bˇežící objednávky u operátora 3.11.1 Odesílání stavových hlášek . . . . . . . . . . . . . 4 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pˇrílohy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Datový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . Obsah pˇriloženého CD . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

41 41 42 43 46 47 48 49 50 50 53

2

Seznam výpisu˚ 3.1 3.2 3.3 3.4 3.5

Výstup služby checkDSLAMnew . . . . . . Výstup služby ADSLcheck . . . . . . . . . Výstup skriptu check_dslam.mpl . . . . Obecná struktura objednávky k operátorovi Obecná struktura notifikace od operátora .

3

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

26 26 27 37 42

Seznam obrázku˚ 2.1 2.2 2.3 2.4

Puvodní ˚ schéma komunikace lidí a systému˚ pˇri objednávání DSL . . Schéma komunikace lidí a systému˚ po aplikování navržených zmˇen Posloupnost událostí pˇri zadávání objednávky zákazníkem. . . . . . Posloupnost komunikace . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

10 12 13 15

3.1 3.2 3.3 3.4

Schéma systému BlackBox . . . . . . . . . . . . . . . . . . . . . . . . . . . Vztah tabulek service, operation a conversation. . . . . . . . . . ˇ Stavový diagram objednávky ORDER k operátorovi Ceský Telecom. . . . Stavový diagram objednávky ORDER k operátorovi Telenor Networks. .

. . . .

19 33 44 46

4

. . . .

Kapitola 1

Úvod Internet, nebo lépe pˇrístup k nˇemu a jeho používání, je v dnešní dobˇe již zcela bˇežným jevem. Je pracovním nástrojem, používáme ho pˇri studiu i jako zdroj nˇekterých druhu˚ zábavy, v neposlední rˇ adˇe je také vyhledávaným pˇredmˇetem obchodu. Tˇežko si už pˇredstavit, že bychom takˇrka dennˇe nepoužívali WWW nebo elektronickou poštu, dvˇe nejznámˇejší služby Internetu. Na cˇ eském trhu funguje množství ISP (Internet Service Provider, poskytovatel pˇripojení k Internetu, dále jen provider) s ruzným ˚ rozsahem pusobnosti ˚ od národních provozovatelu˚ páteˇrních sítí až po lokální na úrovni mˇestských cˇ ástí. Významou pozici mají ty zpusoby ˚ pˇripojení, které jako pˇrístupový bod k Internetu využívají pevnou telefonní linku, cˇ ímž výraznˇe snižují poˇcáteˇcní zˇrizovací náklady. Navíc se dá s úspˇechem pˇredpokládat, že pevná telefonní sít’ pokrývá pˇrevážnou cˇ ást území, a bude tedy možné pˇripojit se takˇrka odkudkoliv.

1.1 Pˇripojení k Internetu skrze telefonní sít Telefonní sít’ má obecnˇe tˇri základní druhy komponent: • ústˇredny, které jsou odstupnovány ˇ podle velikosti území, jež obhospodaˇrují, • dˇríve jen metalické, dnes už i optické spoje mezi ústˇrednami, • výhradnˇe metalické (mˇedˇené) vedení mezi ústˇrednou a koncovým zaˇrízením uživatele (zpravidla telefonním pˇrístrojem), které je oznaˇcováno jako místní smyˇcka (local loop) nebo úˇcastnické resp. koncové vedení (last mile). ˇ V Ceské republice koexistují dva typy telefonní sítˇe. Prvním z nich je PSTN (Public Switched Telephone Network, veˇrejná komutovaná telefonní sít’). Dˇríve šlo o sít’, pracující výhradnˇe s analogovým signálem. Postupem doby byl provoz na vedeních mezi ústˇrednami nahrazen digitálním signálem, analogový signál je pˇrenášen už jen v místní smyˇcce. Primárním úˇcelem tohoto druhu sítˇe je pˇrenos hlasu, klasická telefonie. Druhým typem je mnohem mladší ISDN (Integrated Services Digital Network, digitální sít’ integrovaných služeb). Oproti PSTN pracuje bez výjimky s digitálním signálem, tedy i na místní smyˇcce. Umí pˇrenášet nejménˇe dva na sobˇe nezávislé kanály (v USA právˇe 2, v Evropˇe až 30), z nichž jeden je typicky vyhrazen pro pˇrenos hlasu a zbylé pro pˇrenos dat, lze však oželet pˇrenos hlasu a veškeré dostupné kanály použít pro data. Oba druhy sítˇe umožnují ˇ dva rozdílné pˇrístupy pro využití, resp. sdílení místní smyˇcky pro pˇrenos dat. 5

1. Ú VOD 1.1.1 Vytáˇcené pˇripojení v PSTN síti Oznaˇcení vytáˇcené vychází z toho, že pokaždé, když se chceme pˇripojit, je nutné uskuteˇcnit telefonní hovor, byt’ ne v bˇežném smyslu slova. Provideˇri, kteˇrí nabízejí takový druh pˇripojení, mají pro tento úˇcel vyhrazená telefonní cˇ ísla. Když se nˇe uživatelé dovolají, jsou pˇripojeni do datové sítˇe providera a tou pak typicky dále do Internetu. PSTN sít’ používá pro pˇrenos hlasu frekvenˇcní pásmo od 300 Hz do 3400 Hz. Toto pásmo, oznaˇcované jako hovorové, je bˇehem pˇripojení zcela využito pro pˇrenos dat, a tak není možné na stejné telefonní lince zárovenˇ telefonovat. K tomu, abychom mohli pˇrenášet po místní smyˇcce digitální data, je tˇreba na stranˇe uživatele i poskytovatele použít zaˇrízení modem, které je schopno modulovat digitální signál na analogový a demodulovat jej v opaˇcném smˇeru. Pˇrenosová rychlost dosahuje rˇ ádovˇe nˇekolika desítek kilobitu˚ za vteˇrinu. Poplatky za takový druh pˇripojení se odvíjí od toho, kolik cˇ asu strávíme pˇripojeni, tj. kolik impulsu˚ provoláme. Pˇres své nedostatky zustává ˚ tento druh pˇripojení oblíbeným, a na místech, která neumožnují ˇ nasazení technologií popsaných v následujících odstavcích, také jediným. 1.1.2 Vytáˇcené pˇripojení v ISDN síti Podstatným rozdílem oproti pˇredchozímu zpusobu ˚ pˇripojení je to, že možnost telefonovat není díky nˇekolika na sobˇe nezávislých kanálech v dobˇe pˇripojení k Internetu omezena. Stejné zustává ˚ to, že zákazník platí za telefonní impuls, ovšem zvlášt’ na každém využitém kanále. Výsledná vyšší rychlost pˇripojení je tak zˇrejmˇe vykoupena vyšší cenou. Dalším rozdílem je maximální dosažitelná pˇrenosová rychlost. Každý ISDN kanál má pˇrenosovou rychlost 64 Kb/s, celková rychlost pˇripojení k Internetu je dána násobkem poˇctu kanálu˚ pro tento úˇcel vyhrazených. V pˇrípadˇe, že všechny kanály využijeme pro pˇrenos dat, je možné v USA dosánout rychlosti 128 Kb/s (dvojnásobek kapacity jednoho kanálu) a v Evropˇe až 1920 Kb/s (tˇricetinásobek kapacity jednoho kanálu). Poslední zmˇenou je doba, za kterou je ustaven hovor. V PSTN síti se muže ˚ vyšplhat až na nˇekolik desítek vteˇrin, zatímco v pˇrípadˇe ISDN by nemˇela pˇrekroˇcit jednotky vteˇrin. 1.1.3 Rodina technologií DSL Zkratka DSL (Digital Subsriber Line, digitální koncová pˇripojka) oznaˇcuje obecný zpusob ˚ pˇrenosu digitálního signálu v nevyužité cˇ ásti frekvenˇcního pásma koncového vedení bez ohledu na typ sítˇe. V pˇrípadˇe, že médium (v našem pˇrípadˇe místní smyˇcku), resp. cˇ ást jeho frekvenˇcního spektra, používáme primárnˇe k pˇrenosu nˇejakého signálu (hlasu v PSTN a nˇekolika kanálu˚ v ISDN), a v nevyužitém pásmu pˇrenášíme další signál, mluvíme o broadbandovém využití média. Pro úˇcely pˇripojení k Internetu se broadband používá kromˇe telefonních linek i na vedeních kabelových televizí, kde je médiem koaxiální kabel a primárním signálem obraz a zvuk. Varianty DSL jsou rozlišeny podle toho, v jakém pomˇeru rychlostí lze pˇrenášet data ke koncovému zaˇrízení uživatele (smˇer oznaˇcovaný jako downstrean) a opaˇcnˇe od nˇej (smˇer upstream). 6

1. Ú VOD Dalším kritériem je agregace DSL provozu nˇekolika koncových vedení na jednom kanále (nikoliv ISDN) vedoucím z ústˇredny, v níž se vedení sbíhají do zaˇrízení DSLAM (viz. níže v sekci), dále do sítˇe, typicky Internetu. Typické jsou agragace 1:50 až po 1:1. Nejznámˇejší odrudou ˚ DSL je pravdˇepodobnˇe ADSL (Ansymmetric DSL, asymetrické DSL). Asymetrické proto, že downstreamová rychlost je vyšší než upstreamová. V nabídkách provideru˚ jsou k vidˇení ADSL s pomˇery od 256/64 kb až do 4096/384 kb za vteˇrinu. ADSL je typicky oznaˇcováno jako broadbandové pˇripojení (hlasové pásmo je využíváno, ale provozem DSL není ovlivnováno). ˇ Druhou známou a rozšíˇrenou variantou je SHDSL (Single-pair High-speed DSL, vysokorychlostní DSL), která naní broadbandovou technologií. Pˇrepodkládá totiž, že uživatel nechce a nebude využívat místní smyˇcku k primárnímu úˇcelu (pˇrenos hlasu v PSTN síti nebo provoz nˇekolika kanálu˚ v síti ISDN), ale že celé její frekvenˇcní pásmo vyhradí pro úˇcely pˇripojení k Internetu DSL zpusobem. ˚ Tato varianta je typicky symetrická, rychlosti ve smˇeru down- i upstream jsou stejné. Pˇrenosová rychlost muže ˚ pˇresáhnout 4 Mb/s v každém smˇeru. Koncový uživatel musí používat dvˇe zaˇrízení, která jsou nezbytná pro pˇripojení k Internetu výše uvedeným zpusobem: ˚ DSL modem (protože dále budeme uvažovat jen DSL technologie, omezíme se nˇekdy i na pouhé oznaˇcení modem), který má stejnou funkci jako v 1.1.1, a splitter, jenž rozdˇeluje a sluˇcuje signál na nízkých (primání signál) a vysokých frekvencích (DSL provoz). Splitter v poˇradí následuje telefonní linku, pak je vmístˇen DSL modem, který je spojen s koncovým zaˇrízením uživatele. Funkˇcnˇe obdobná zaˇrízení jsou zapotˇrebí i v ústˇrednˇe, do které místní smyˇcka smˇerˇ uje. Navíc pˇribývá prvek známý jako DSLAM (DSL Access Multiplexer, sdružovaˇc DSL linek), do kterého vede již výhradnˇe DSL signál z každé jednotlivé místní smyˇcky. Zaˇrízení DSLAM je bránou do datových sítí a dále do Internetu.

1.2 Pronájem místní smyˇcky Majoritním vlastníkem a provozovatelem pevné telefonní sítˇe (ve významu fyzické inˇ frastruktury bez ohledu na typ sítˇe), rˇ íkejme operátorem, je v Ceské republice spoleˇcnost ˇ ˇ Ceský Telecom, a.s. (dále budeme uvádˇet jen Ceský Telecom), a to z duvod ˚ u˚ zejména historických (jedná se o bývalý státní podnik, který byl v pozici monopolu). Duležitý ˚ je zejména fakt, že majoritní operátor byl zprvu výhradním vlastníkem místních smyˇcek. ˇ V dobˇe, kdy zaˇcal Ceský Telecom jako první nabízet koncovým zákazníkum ˚ testovací ADSL pˇripojení (ˇcervenec 2001), byl jediným subjektem, který byl technicky schopen tento druh pˇripojení provozovat. To proto, že mˇel pˇrístup ke koncovým vedením. Staˇcilo jen pˇridat do vybraných ústˇreden DSLAM. Na to samozˇrejmˇe rychle zareagovaly ostatní spoleˇcnosti, z nichž nˇekteré v té dobˇe ˇ ˇ už konkurovaly Ceskému Telecomu na poli hlasových služeb. Mˇely obavu, že Ceský Telecom získá dominantní podíl na trhu, aniž by dal pˇríležitost jim, potenciálním alternativním operátorum. ˚ Ze strany zájemcu˚ o provozování vlastních DSL služeb, jakožto i ze ˇ ˇ strany odborné veˇrejnosti, byl vyvíjen tlak na vládní instituce, zejména na CTÚ (Ceský Telekomunikaˇcní Úˇrad). Tento vyústil (na podzim roku 2004) po dlouhých právních a obchodních jednáních v rˇ ešení, které umožnilo i ostatním obchodním subjektum ˚ pˇrístup

7

1. Ú VOD k místním smyˇckám. Toto rˇ ešení je známé jako LLU (Local Loop Unbundling, pronájem místní smyˇcky). Z názvu vyplývá, že na základˇe smlouvy mezi majoritním a alternativním operátorem bude mít ten druhý možnost pˇristupovat k vybrané místní smyˇcce. Vybrané proto, že není tˇreba mít pˇrístup ke všem smyˇckám, které se sbíhají do konkrétní ústˇredny, ale jen ke smyˇckám zákazníku, ˚ kteˇrí chtˇejí využívat DSL služeb alternativního operátora. V praxi je to realizováno tak, že do ústˇredny majoritního operátora je umístˇen DSLAM alternativního operátora (takový stav je oznaˇcován jako kolokace zaˇrízení DSLAM), do kterého je smˇerˇ ován provoz vybraných místních smyˇcek. Alternativnímu operátorovi jsou ze strany majoritního úˇctovány jak poplatky za pronajaté místní smyˇcky, tak za umístˇení vlastního DSLAM v ústˇrednˇe. Jako první využil rozhodnutí o LLU Telenor Networks, s. r. o. (dále jen Telenor Networks), a krátce po jeho zveˇrejnˇení zaˇcal nabízet na velkoobchodní bázi ADSL a SHDSL služby. Telenor Networks se neorientuje na koncové zákazníky, o ty bojují jednotliví provideˇri, se kterými spolupracuje. Jedním z takových provideru˚ je i SkyNet, a. s (dále jen SkyNet). Pro úˇcely dalšího textu vymezíme pojmy DSL operátor a provider. Operátorem rozumíme ten subjekt, který má v majetku vlastní DSLAM zaˇrízení, do nˇejž smˇerˇ uje DSL provoz bud’ z jeho vlastní nebo v rámci LLU dohody pronajaté místní smyˇcky. Operátor prodává DSL pˇripojení ve velkoobchodním objemu providerum. ˚ Provider bude ten, kdo nabízí DSL pˇripojení koncovým zákazníkum ˚ za maloobchodní ceny. Obchodní subjekty, které už byly výše zmínˇeny a které budou vystupovat i v dalších cˇ ástech práce, jsou klasifikovány takto: ˇ • Ceský Telecom vystupuje na cˇ eském trhu jak v roli operátora, tak providera. V textu bude ale vystupovat výhradnˇe jako operátor. ˇ • Telenor Networks je alternativním operátorem, pronajímá koncová vedení od Ceského Telecomu. • SkyNet je jedním z provideru, ˚ který nabízí DSL pˇripojení realizované pˇres DSLAM ˇ Ceského Telecomu (pouze ADSL) nebo Telenor Networks (ADSL i SHDSL).

1.3 Komunikace provideru˚ s operátory Je mínˇena taková komunikace mezi providerem a operátorem, která smˇerˇ uje k tomu, aby na konkrétním úˇcastnickém vedení bylo možné provozovat DSL pˇripojení, jehož odbˇeratelem je zákazník providera. Jako první je tˇreba dát operátorovi vˇedˇet, na kterém koncovém vedení (identifikovaném telefonním cˇ íslem, pozdˇeji budeme tato dvˇe oznaˇcní zamˇenovat) ˇ bude taková služba uskuteˇcnována. ˇ Operátor musí potom provˇerˇ it, že na takovém vedení je technicky možné DSL pˇripojení provozovat. Taková provˇerka je známá jako technické šetˇrení. Prvním nutným kritériem je to, že místní smyˇcka musí vést do ústˇredny, ve které je umístˇen DSLAM vybraného operátora. Možnost zˇrízení DSL je dále ovlivnována ˇ délkou místní smyˇcky. Pokud tato pˇresáhne kritickou mez (záleží na kvalitˇe konkrétního metalického vedení, jako bˇežné maximum 8

1. Ú VOD se uvádí 3,5 km), není možné zaruˇcit pˇrenos signálu v takové kvalitˇe, aby poskytl providerem nabízenou pˇrenosovou rychlost: na vodiˇce pusobí ˚ elektromagnetické ruchy okolí a dochází k pˇrirozenému útlumu signálu. Pˇrekážkou zˇrízení DSL pˇripojení muže ˚ být i typ rozhraní ISDN linky. ISDN používá pro pˇrenos signálu cˇ tyˇri vodiˇce, zatímco místní smyˇcka má vodiˇce dva. Zaˇrízení, které dokáže funkˇcnˇe propojit takovou kombinaci vodiˇcu, ˚ se jmenuje NT (Network Termination). Ten výstup, který vede k ISDN zaˇrízením (má tedy cˇ tyˇri vodiˇce), je rozhraní S/T, výstup dvouvodiˇcový je rozhraní U. Ve Spojených státech bývá NT zaˇrízení v majetku koncového uživatele, který má tím pádem právo pˇripojit splitter k U rozhraní. V Evropˇe je NT naopak tradiˇcnˇe ve vlastnictví operátora, provozovatele místní smyˇcky, a koncový uživatel má pˇrístup pouze k S/T rozhraní, ke kterému není možné splitter pˇripojit. Pˇred tím, než je možné zprovoznit na lince DSL, je tˇreba u majitele místní smyˇcky oficiálnˇe požádat o zmˇenu ISDN rozhraní na typ U. Tento úkon spoˇcívá v pˇrevedení NT zaˇrízení do vlastnictví koncového uživatele telefonní linky. Posledním úskalím je možnost, že na telefonní lince je již provozována DSL služba jiného než vybraného operátora. Pak je nutné ukonˇcit tuto službu u provozujícího operátora. Tímto je výˇcet bˇežných možných technických potíží úplný. Poté, co jsou vylouˇceny technické potíže, pˇredá operátor providerovi identifikaci datové sítˇe, do které je smˇerˇ ován DSL provoz na vybraném koncovém vedení. Ná základˇe této informace pˇridˇelí provider koncovému uživateli bud’ veˇrejnou nebo neveˇrejnou IP adresu. Tím konˇcí proces zˇrízení DSL. Pˇrirozenˇe muže ˚ nastat situace, kdy chce zákazník zmˇenit parametry služby, zejména pˇrenosovou rychlost nebo agregaci. Pˇri snížení pˇrenosové rychlosti by nemˇely nastat technické potíže, pˇri zvýšení operátor opˇetovnˇe provádí technické šetˇrení toho, zda je kvalita linky dostaˇcující pro takovou úpravu. Zˇrejmˇe je možné DSL i zrušit, at’ už proto, že koncový zákazník za pˇripojení neplatí, nebo z toho duvodu, ˚ že zvolil z nabídky DSL providera službu, která bude provozována na DSLAM jiného operátora.

1.4 Obsah a cˇ lenˇení dalšího textu První kapitola mˇela za cíl pˇrinést pˇrehled zpusob ˚ u˚ pˇripojení k Internetu využívajících telefonní linky, z nich podrobnˇeji popsat technologii DSL a zmínit situaci na cˇ eském trhu co do existence jejích operátoru, ˚ a nakonec uvést a rozlišit operátory a providera, kteˇrí budou hrát roli v dalších kapitolách. Následující kapitola popíše životní cyklus objednávky DSL od zákazníka smˇerem k providerovi, procesy, které provider koná s cílem tuto objednávku uskuteˇcnit (s du˚ razem na zpusob ˚ komunikace s operátory), a nakonec stanoví ty úkoly, které má za cíl vykonávat systém, který v rámci této práce vznikl a jenž funguje v produkˇcním nasazení. Další kapitola podá podrobný popis rˇ ešení systému od datových struktur až po popis funkcionality kódu vˇcetnˇe zvolených implementaˇcních nástroju. ˚

9

Kapitola 2

Proces objednání DSL V této kapitole bude nejdˇríve popsán postup objednávání DSL služeb tak, jak jej provider SkyNet uskuteˇcnoval ˇ pˇred tím, než došlo k jeho zmˇenám, z nichž jednou je zaˇclenˇení systému, který vznikl jako produkt praktické cˇ ásti této práce, do celého procesu. Pˇri tom budou postupnˇe vyjmenovány systémy a lidé, resp. role lidí, které se odvíjí od jejich pˇríslušnosti k nˇekterému oddˇelení firmy SkyNet, kteˇrí spolu komunikují v procesu objednávání DSL služby. Následuje právˇe vize zmˇen, ke které dospˇel kolektiv pracovníku˚ SkyNetu, vˇcetnˇe autora této práce. V této cˇ ásti bude popsána interakce nového systému s okolím, lze ji proto považovat za podrobné zadání. Závˇer kapitoly shrnuje úkoly, které bude vykonávat novˇe vzniklý systém.

2.1 Vymezení pojmu˚ V následujících sekcích se budou cˇ asto vyskytovat spojení objedání DSL služby a objednání DSL pˇripojení. V této kapitole budeme objednáním DSL služby (nebo také objednávkou k providerovi) rozumˇet komunikaci iniciovanou zákazníkem smˇerem k providerovi, zatímco spojení objednávka DSL pˇripojení (nebo objednávka k operátorovi) budeme používat tam, kde pujde ˚ o komunikaci providera smˇerem k operátorovi, viz. 1.3. Objednávka DSL pˇripojení je tedy nedílnou souˇcástí objednávky DSL služby. Tím je mínˇeno, že provideˇri nenabízejí zpravidla DSL pˇripojení samo o sobˇe, ale doplnují ˇ ho nˇekterými službami (instalace DSL modemu, e-mailová schránka, prostor k umístˇení webové prezentace, registrace a správa domény, apod.) a zbožím (modem). V názvu kapitoly je zámˇernˇe vynecháno upˇresnˇení, zda jde o objednání DSL služby nebo pˇripojení. Bude totiž pojednán celý proces objednání DSL služby, nicménˇe systém, který bude popsán v dalších kapitolách, se zabývá pˇrevážnˇe (nikoliv ale výhradnˇe) objednáváním DSL pˇripojení.

2.2 Výchozí stav Pˇred tím, než zaˇcal SkyNet poskytovat DSL služby prostˇrednictvím operátora Telenor ˇ Networks, nabízel pouze DSL na bázi velkoobchodní nabídky Ceského Telecomu. Existovala webová aplikace dostupná z Internetu, které dovolila potenciálnímu zákazníkovi vybrat kýženou DSL službu z aktuální nabídky. Dále na ni budeme odkazovat jako na zákaznickou aplikaci. Poté, co zákazník zadal všechny údaje potˇrebné k tomu, aby bylo možné rozbˇehnout 10

2. P ROCES

OBJEDNÁNÍ

DSL

na stranˇe providera objednávku DSL služby, zákaznická aplikace odeslala e-mail s tˇemito údaji systému, který oznaˇcíme jako interní objednávkový systém. Interní objednávkový systém uložil údaje o požadované DSL službˇe a zaˇcal zjišt’ovat (v intervalu dní), zda je na vybraném koncovém vedení dosupné DSL, tj. zda v ústˇrednˇe, do které vede místní smyˇcka, je pˇrítomen DSLAM a je tedy pravnˇepodobné, že pˇripojení bude možné zˇrídit. Když to možné bylo, zahájil interní objednávkový systém objedˇ návku DSL pˇripojení. Informace o dostupnosti DSL poskytoval systém Ceského Telecomu, stejnˇe jako pˇrijímal objednávky a doruˇcoval notifikace o jejich prubˇ ˚ ehu. ˇ Casto bylo tˇreba iniciovat objednávku opakovanˇe, a to bud’ z duvod ˚ u˚ chyby v údajích od zákazníka (chybná kombinace telefonního a referenˇcního cˇ ísla) nebo z duvod ˚ u˚ technických, viz. 1.3. V tˇechto pˇrípadech se interní objednávkový systém choval v jistém smyslu agresívnˇe: odesílal dennˇe objednávku DSL pˇripojení bez ohledu na to, zda to má v daný okamžik význam. Pˇríkladem necht’ je situace, kdy je nutná zmˇena ISDN rozhraní, která muže ˚ trvat nˇekolik dní, a tato ještˇe neprobˇehla. Tehdy sice interní objednávkový systém informuje e-mailem zákazníka, že provider cˇ eká na jeho akci (žádost o zmˇenu rozhraní u majitele místní smyˇcky), ale mezitím stále odesílá objednávky operátorovi, pˇrestože jsou odmítány pro výše uvedený nedostatek.

Obrázek 2.1: Puvodní ˚ schéma komunikace lidí a systému˚ pˇri objednávání DSL Interní objednávkový systém mˇel vlastní webové rozhraní, dostupné pouze z vnitˇrní, neveˇrejné sítˇe firmy SkyNet, které používali pracovníci oddˇelení péˇce o zákazníka (dále Customer Care) a technického oddˇelení ke sledování prubˇ ˚ ehu objednávky DSL služby i pˇripojení a k tomu, aby mohli v relevantní okamžik zasáhnout. Customer Care používalo interní objednávkový systém typicky v situacích, kdy zákazník projevil zájem znát aktuální stav své objednávky; nejˇcastˇeji kladl otázku, proˇc není služba dosud funkˇcní. Tehdy mohlo Customer Care na základˇe notifikací evidovaných v interním objednávkovém systému zákazníkovi sdˇelit, v jakém stavu jeho objednávka je, zda úspˇešnˇe pokraˇcuje nebo napˇr. cˇ eká na další postup na stranˇe operátora. Do systému pak mohlo ukládat záznamy o okolnostech, které objednávku ovlivnují. ˇ Napˇríklad to, že na lince zákazníka nelze kvuli ˚ nedostateˇcné kvalitˇe místní smyˇcky zˇrídit 11

2. P ROCES

OBJEDNÁNÍ

DSL

pˇripojení o jím požadované rychlosti. Pak Customer Care po dohodˇe se zákazníkem zmˇenilo objednávku a interní objednávkový systém rozbˇehl novou komunikaci s operátorem. Podobnˇe když systém operátora odmítl objednávku kvuli ˚ špatnˇe kombinaci telefonního a referenˇcního cˇ ísla, interní objednávkový systém o tom Customer Care uvˇedomil, to kontaktovalo zákazníka, zjistilo správné údaje a objednávka k operátorovi mohla být znovu spuštˇena. Technické oddˇelení v interním objednávkovém systému zjišt’ovalo, zda nˇekterá objednávka pˇripojení témˇerˇ dospˇela k úspˇešnému konci (dokonˇcena konfigurace na stranˇe operátora, viz. 3.4), což pro nˇe bylo signálem pro to, aby zákazníkovi dopravili DSL modem a pˇrípadnˇe jej i nainstalovali, a nakonfigurovalo doplnkové ˇ služby (veˇrejná IP, email, aj.), byly-li souˇcástí objednané DSL služby. Zpˇetnˇe do systému uvádˇelo napˇr. informace o technických potížích s ruznými ˚ typy modemu. ˚ V okamžiku, kdy jak na stranˇe operátora tak SkyNetu bylo vše pˇripraveno k tomu, aby zákazník mohl zaˇcít využívat DSL pˇripojení, bylo tˇreba vytvoˇrit na základˇe údaju˚ z objednávky DSL služby a pˇrípadných zmˇen v jejím prubˇ ˚ ehu smlouvu, která právnˇe upravuje vztah zákazníka a SkyNetu coby providera a stanovuje z nˇej plynoucí práva a povinnosti obou stran. Smlouvy jsou ve SkyNetu evidovány v dalším systému v poˇradí, OmniTrackeru. Smlouva je také pˇredpokladem a podkladem k fakturaci služby zákazníkovi. Smlouvy vytváˇrelo Customer Care ruˇcnˇe v OmniTrackeru podle údaju˚ v interním objednávkovém systému. Celý postup komunikace je schematicky znázornˇen na obrázku 2.1. Zákazník Z obsluhuje zákaznickou aplikaci ZA, která informuje o nové objednávce interní objednávkový ˇ systém IOS. Ten oboustranˇe komunikuje se systémem Ceského Telecomu CTC. V pru˚ bˇehu rˇ ešení objednávky muže ˚ IOS informovat zákazníka o nutnosti provést úkon, který podminuje ˇ úspˇešné pokraˇcování objednávky DSL pˇripojení a tedy i DSL služby. IOS informuje Custormer Care i technické oddˇelení o událostech, které mohou a mají rˇ ešit, a eviduje výsledek jejich rˇ ešení.

2.3 Navrhované zmˇeny Systém, který jsme oznaˇcili jako OmniTracker, je komerˇcním systémem1 , jehož funkcionalita pokrývá mj. oblast CRM (Customer Relationship Management, evidence byt’ jen potenciálních zákazníku) ˚ a PBM (Problem and Bug Management, nˇekdy i Issue Tracking, sledování a rˇ ešení úkolu). ˚ V 2.2 bylo uvedeno, že v interním objednávkovém systému jsou evidováni zákazníci a jejich objednávky DSL služeb, a nastanou-li v prubˇ ˚ ehu komunikace s operátorem situace, které vyžadují rˇ ešení ze strany Customer Care nebo technického oddˇelení, interní objednávkový systém pˇríslušné oddˇelení upozorní. Tím se vlastnˇe na jisté úrovni snaží interní objednávkový systém pokrýt funkce, pro které je OmniTracker primárnˇe vytvoˇren, a kvuli ˚ kterým byl zakoupen. To je první a nejzávažnˇejší nedostatek, který byl vytknut dosavadnímu zpusobu ˚ rˇ ešení objednávek DSL služeb. Impulsem pro jeho revizi byl pˇríchod Telenor Networks coby alternativního operátora DSL pˇripojení na trh. Konkurence mezi operátory zpusobila ˚ snížení cen, na které SkyNet 1

Produkt firmy OmniNet, více na http://www.omninet.de/english/id_otpos.html.

12

2. P ROCES

OBJEDNÁNÍ

DSL

jako provider pˇrirozenˇe reagoval tak, že zaˇcal nabízet DSL založené na nabídce nového operátora. Tato událost byla nahlížena jako vhodná pˇríležitost pro použití jiného, pro vnitˇrní úˇcely SkyNetu lepšího zpusobu ˚ rˇ ešení objednávek. Nové rˇ ešení je založeno na OmniTrackeru jako na jediném nástroji, který bude Customer Care, technické oddˇelení a novˇe i produktové oddˇelení (definuje obsah a cenu DSL služeb) pˇri rˇ ešení objednávek používat. Ten bude skrze novˇe vytvoˇrený systém komunikovat se zákaznickou aplikací a jednotlivými operátory, až na jedinou výjimku, kdy bude zákaznická aplikace komunikovat pˇrímo s OmniTrackerem, jak uvedeme dále.

Obrázek 2.2: Schéma komunikace lidí a systému˚ po aplikování navržených zmˇen Na tento nový systém, jehož návrh a implementace je obsahem dalších kapitol, budeme odkazovat jako na BlackBox. Oznaˇcení vyplynulo ze zámˇeru, aby nový systém pracoval automaticky do té doby, než bude tˇreba lidského zásahu. Práce spoˇcívá v odstínˇení OmniTrackeru od problematiky odesílání objednávek systémum ˚ operátoru˚ a pˇríjmu notifikací k nim. Bylo ale dohodnuto, že v první fázi bude BlackBox zajišt’ovat komunikaci jen se systémem Telenor Networks. Až se ukáže, že je jeho provoz a zaˇclenˇení do celého procesu rˇ ešení objednávek DSL služeb dostateˇcnˇe bezchybový, zaˇcne se používat i pro komuniˇ kaci se systémem Ceského Telecomu. Pˇresnˇeji: zprvu bude BlackBox komunikovat oboustrannˇe se systémem Telenor Neˇ tworks (odesílat objednávky i pˇríjmat notifikace) a od systému Ceského Telecomu pouze pˇrijímat notifikace, ty pˇredávat do interního objednávkového systému, s nímž budou nadále pracovat Customer Care i technické oddˇelení. Pozdˇeji BlackBox pˇrevezme i odesíˇ lání objednávek do systému Ceského Telecomu. Interní objednávkový systém bude zcela vylouˇcen z procesu rˇ ešení objednávek DSL služeb. Nové schéma komunikace mezi systémy a lidmi je zachyceno na obrázku 2.2. Znaˇcení je shodné s již použitým na obrázku 2.1, novˇe pˇribylo oznaˇcení BB pro BlackBox. 13

2. P ROCES

OBJEDNÁNÍ

DSL

Pˇrestože se muže ˚ zdát, že BlackBox bude pouze suplovat funkci interního objednávkového systému v komunikaci se systémy operátoru, ˚ jeho hlavní pˇrínos bude v tom, že poskytne OmniTrackeru jednotné rozhraní pro objednávání DSL pˇripojení u operátoru, ˚ jejichž rozhraní se mohou obecnˇe lišit. Poˇcet operátoru˚ muže ˚ na základˇe vývoje poptávky po LLU ještˇe vzrust, ˚ kromˇe Teˇ lenor Networks už tuto možnost využily i Ceské radiokomunikace, a. s., proto je na obrázku 2.2 uveden i další potenciální operátor. BlackBox bude navržen právˇe s ohledem na to, že ke stávajícím dvˇema operátorum, ˚ u nichž SkyNet zˇrizuje pro své zákazníky DSL pˇripojení, muže ˚ pˇribýt další. V tom pˇrípadˇe by mˇelo být tˇreba vynaložit jen malé úsilí k tomu, pˇrizpusobit ˚ BlackBox novým podmínkám. Produktovému oddˇelení bude OmniTracker sloužit jako nástroj k definování DSL služeb (jak je datovˇe popsána DSL služba uvádíme v 3.4.1). OmniTracker jejich popis pˇredá BlackBoxu a ten dále zákaznické aplikaci. Tu použije zákazník nejprve ke kontrole, zda na jeho cˇ ísle je dostupné DSL nˇekterého operátora bezprostˇrednˇe, v blízké budoucnosti, nebo dostupné není. Posloupnost událostí poˇcínaje tímto okamžikem a konˇce odesláním obejdnávky DSL služby do OmniTrackeru mužeme ˚ sledovat na obrázku 2.3, v nˇemž uspoˇrádání cˇ ísel zdu˚ raznuje ˇ cˇ asovou posloupnost jednotlivých kroku. ˚ Je vynechána osoba zákazníka, resp. zákaznická aplikace na obrázku pˇredstavuje manipulaci potenciálního zákazníka se zákaznickou aplikací.

Obrázek 2.3: Posloupnost událostí pˇri zadávání objednávky zákazníkem. Ke kontrole dostupnosti poskytne zákaznické aplikaci BlackBox službu, která se bude tázat funkcí systému˚ operátoru, ˚ které jsou schopny poskytnout odpovˇed’. Ty však vrací data ruzná ˚ jak ve struktuˇre, tak ve významu. BlackBox tato data transformuje na spoleˇcnou strukturu, s níž bude zákaznická aplikace pracovat. Jaké výstupy dávají funkce systému˚ operátoru˚ urˇcené k ovˇerˇ ení dostupnosti DSL, a jaké spoleˇcné údaje z nich BlackBox odvozuje, zminuje ˇ 3.5.1. Podle toho, co vrátí systémy operátoru˚ prostˇrednictvím BlackBoxu zákaznické aplikaci, dovolí nebo nedovolí tato vybrat a objednat DSL službu. Systémy operátoru˚ mohou o konkrétním telefonním cˇ ísle kromˇe toho, že je na nˇem 14

2. P ROCES

OBJEDNÁNÍ

DSL

DSL dostupné ihned, prohlásit ještˇe dvˇe skuteˇcnosti: pˇripojení bude možné zˇrídit v krátkém cˇ asovém horizontu (ˇrádovˇe týdny) a systém operátora poskytne pˇredpokládané datum, nebo pˇripojení zˇrídit nelze (což znamená, že operátor zatím nemá v plánu danou lokalitu pokrýt DSLAM, resp. doba do pokrytí pˇresahuje nˇekolik mˇesícu). ˚ V posledním pˇrípadˇe nedovolí zákaznická aplikace zadat objednávku. Ovˇerˇ ení dostupnosti DSL ještˇe pˇred zadáním objednávky tak zamezí kupení objednávek, které nebude možné vyˇrídit ke spokojenosti zákazníka. V okamžiku, kdy zákazník dokonˇcí výbˇer DSL služby, zákaznická aplikace oznámí novou objednávku OmniTrackeru. To je právˇe ona výjimka, kdy komunikace OmniTrackeru s jiným systémem neprobíhá prostˇrednictvám BlackBoxu, ale pˇrímo. Jakmile OmniTracker novou objednávku zaeviduje, oznámí to Customer Care (PBM funkcionalita OmniTrackeru), které kontaktuje zákazníka (zpravidla telefonicky), aby ovˇerˇ ilo, že to byl právˇe on, kdo zadal srze zákaznickou aplikaci objednávku DSL služby. Pakliže je tomu skuteˇcnˇe tak, Customer Care novou objednávku autorizuje, tedy potvrdí, že má být zapoˇcato objednávání DSL pˇripojení u operátora. Poté, co je objednávka DSL služby autorizována, OmniTracker oznámí tuto skuteˇcnost BlackBoxu. Ten znovu ovˇerˇ uje dostupnost DSL na vybraném cˇ ísle, ale jen u operátora, který je urˇcen definicí DSL služby, viz. 3.4.1. Takto cˇ iní ze dvou duvod ˚ u: ˚ prvním z nich je ten, že ne všechny objednávky musí nutnˇe vzniknout v OmniTrackeru na základˇe informace od zákaznické aplikace, která prvotnˇe dostupnost DSL kontroluje, nˇekteré mohou být vytvoˇreny Customer Care ruˇcnˇe pˇri osobním nebo telefonickém objednání DSL služby zákazníkem. Druhý duvod ˚ plyne z vlastnosti zákaznické aplikace, která dovolí zadat objednávku DSL služby i pˇresto, že na koncovém vedení, jenž chce zákazník využít pro DSL pˇripojení, není DSL dostupné ihned, ale v blízké budoucnosti. Dozví-li se BlackBox, že DSL bude dostupné v budoucnosti, oznámí zpˇet OmniTrackeru pˇredpokládané datum, které operátor poskytl jako souˇcást odpovˇedi. Zárovenˇ zacˇ ne pravidelnˇe (napˇr. jednou za den) kontrolovat dostupnost DSL na vybraném cˇ ísle, protože datum pˇredpokládané dostupnosti DSL je v interních materiálech operátoru˚ [2] a [3] oznaˇceno jako nezávazné (zmˇenit se muže ˚ v obou smˇerech). Datum se muže ˚ zmˇenit i nˇekolikrát po sobˇe, pˇri pravidelné kontrole bude tyto zmˇeny oznamovat BlackBox OmniTrackeru. Pravidelná kontrola dostupnosti muže ˚ skonˇcit jak úspˇechem (DSL je ihned dostupné), tak neúspˇechem (DSL není dostupné). Obojí hlásí BlackBox opˇet OmniTrackeru. V okamžiku, kdy se OmniTracker u objednávky, u které eviduje cˇ ekání na dostupnost DSL na vybraném cˇ ísle, dozví, že je DSL dostpné ihned, upozorní Customer Care. To znovu kontaktuje zákazníka, tentokrát proto, aby si od nˇej nechalo potvrdit, že zájem o DSL službu stále trvá. Jestliže ano, pak reviduje objednávku DSL služby v OmniTrackeru. Ten znovu vyšle požadavek BlackBoxu, aby zahájil objednání DSL pˇripojení u operátora. Pˇredpokládejme, že operátor uvádí, že pˇripojení je ihned dostupné. Pak BlackBox zahájí objednávku. Objednávku muže ˚ operátor nˇekolikrát odmítnout nebo ukonˇcit, aniž by zˇrídil DSL pˇripojení, duvody ˚ byly uvedeny v 1.3. Další postup mužeme ˚ sledovat na obrázku 2.4, cˇ asová posloupnost je opˇet vyjádˇrena uspoˇrádáním cˇ ísel. Systém pˇríslušného operátora informuje providera o prubˇ ˚ ehu objednávky v notifika-

15

2. P ROCES

OBJEDNÁNÍ

DSL

cích. Ty obsahují identifikaci objednávky odeslané operátorovi a popis stavu, do kterého objednádka DSL pˇripojení dospˇela. Popisy stavu˚ jsou souˇcástí [2] a [3]. Notifikace mohou mít stejnˇe jako odpovˇedi systému˚ operátoru˚ na dotaz o dostupnosti DSL ruznou ˚ strukturu (viz. výše v sekci) i význam. Proto jsou také notifikace transformovány na jednotnou strukturu, která je ve formˇe stavových hlášek pˇredávána do OmniTrackeru. ˇ Zatímco v pˇrípadˇe Ceského Telecomu nejsou objednávky (v tomto stadiu vlastnˇe jen pokusy o objendávky) pˇripojení providerum ˚ zpoplatnovány, ˇ Telenor Networks si za jejich zpracování úˇctuje nezanedbatelnou cˇ ástku. Snad proto, že on sám musí v rámci svých ˇ interních procesu˚ komunikovat s Ceským Telecomem o zpˇrístupnˇení pˇríslušné místní ˇ smyˇcky, a tato komunikace je spoleˇcnosti Telenor Networks ze strany Ceského Telecomu úˇctována. Je zˇrejmé, že SkyNet se bude chtít takovým zbyteˇcným výdajum ˚ vyhnout, tedy bude chtít minimalizovat poˇcet pokusu˚ o objednávku, a není možné, aby se BlackBox choval stejnˇe agresivnˇe jako interní objednávkový systém, viz. 2.2.

Obrázek 2.4: Posloupnost komunikace Proto, když BlackBox pˇrijme od operátora notifikaci, která znamená, že objednávku není možné úspˇešnˇe dokonˇcit, oznámí to OmniTrackeru a nepokraˇcuje v pokusech o objednání DSL pˇripojení do té doby, než Customer Care znovu nereviduje objednávku DSL služby. Než tak uˇciní, podle duvodu ˚ neúspˇechu, který operátor uvedl v notifikaci, kontaktuje bud’ zákazníka nebo operátora, aby zjistilo, co je tˇreba vykonat pro to, aby mohla být znovu odeslána objednávka k operátorovi. Takový kolobˇeh se muže ˚ nˇekolikrát opakovat. Tím bude dosaženo neagresivního chování v protikladu k tomu, co bylo popsáno v 2.2. Právˇe agresivita pˇri odesílání objednávek operátorovi byla oznaˇcena jako druhý nejzávažnˇejší problém, jemuž se snaží nový zpusob ˚ rˇ ešení DSL objednávek vyhnout. Pˇredpokládejme, že objednávka DSL pˇripojení dospˇela do stavu, kdy jsou tyto obtíže pˇrekonány, a míˇrí k úspˇešnému konci, fungujícímu DSL pˇripojení. Nˇekterá z posledních notifikací od operátora obsahuje konfiguraˇcní údaje (identifikace pˇrístupového bodu do 16

2. P ROCES

OBJEDNÁNÍ

DSL

ATM sítˇe operátora), které technické oddˇelení použije pˇri konfiguraci IP adresy již brzy funkˇcního pˇripojení. Když se OmniTracker dozví od BlackBoxu, že objednávka dospˇela do této fáze, informuje technické oddˇelení, to má za úkol vyˇrídit záležitosti ohlednˇe dodání a instalace DSL modemu. Notifikace, která definitivnˇe dokonˇcí objednávku na stranˇe operátora, je, stejnˇe jako všechny pˇredchozí, transformována BlackBoxem do podoby srozumitelné OmniTrackeru. Když OmniTracker obdrží takovou stavovou hlášku, a jsou-li splnˇeny další podmínky (Customer Care potvrdilo, že zákazník je schopen se pˇripojit k Internetu pˇres novˇe funkˇcní DSL), OmniTracker automaticky vygeneruje podklady pro smlouvy a fakturaci DSL služby zákazníkovi. V tom okamžiku mluvíme o bˇežící DSL službˇe. Nabídka DSL služeb se bude v cˇ ase jistˇe vyvíjet. Zejména cena a dostupnost (resp. vyšší rychlost v dané lokalitˇe) DSL pˇripojení se bude ze strany operátoru˚ mˇenit, na to bude SkyNet zˇrejmˇe reagovat úpravou vlastního portfolia. Zákazník bude mít možnost – bud’ znovu skrze zákaznickou aplikaci nebo kontaktováním pˇrímo Customer Care – zmˇenit již bˇežící DSL službu nebo tuto zrušit. Z pohledu zákazníka pujde ˚ jen o zmˇenu služby, jak ji nabízí SkyNet. Za touto zmˇenou se však skrývá otázka, zda se nové pˇripojení bude dít u stejného operátora jako již bˇežící služba, nebo u jiného. Pˇri zmˇenˇe, kterou Customer v OmniTrackeru opˇet autorizuje, dostane BlackBox zprávu, stejnˇe jako pˇri prvotní objednávce pˇripojení. V pˇrípadˇe, že operátor zustává ˚ stejný, BlackBox s ním zapoˇcne komunikaci, která se svým prubˇ ˚ ehem podobá komunikaci pˇri pˇredchozí úspešné objednávce. Znovu platí, že BlackBox o všech pˇrípadných problémech se zmˇenou informuje OmniTracker, a Customer Care vždy musí požadavek na odeslání objednávky k operátorovi revidovat. Když má dojít ke zmˇenˇe, která znamená zmˇenu operátora, BlackBox nejdˇríve ukonˇcí fungující pˇripojení k jednomu operátorovi a následnˇe objedná pˇripojení u novˇe zvoleného. Mezi tˇemito úkony je na stranˇe operátoru˚ závislost; ta nedovoluje jednomu operátorovi zaˇcít zˇrizovat pˇripojení na lince, na které je provozováno DSL jiného operátora. Bylo stanoveno, že cˇ asovou návaznost, která z toho plyne, bude sledovat OmniTracker. Pro nˇej bude taková zmˇena pˇripojení znamenat zmˇenu celé DSL služby (vytvoˇrení nové) a tedy i potˇrebu vytvoˇrit novou smlouvu.

2.4 Shrnutí úkolu˚ nového systému V pˇredchozí sekci byla popsána postupná vzájemná komunikace OmniTrackeru, BlackBoxu a systému˚ operátoru, ˚ stejnˇe jako možné interakce Customer Care, technického a produktového oddˇelení s OmniTrackerem, tak, jak budou po aplikování navržených zmˇen probíhat. Nyní jen vybereme a shrneme ty úkoly, které má obstarávat BlackBox: • Bude od OmniTrackeru pˇrebírat aktuální nabídku DSL služeb, jak ji nadefinovalo produktové oddˇelení, a pˇredávat ji zákaznické aplikaci. • Bude poskytovat službu, která transformuje významovˇe ruzné ˚ odpovˇedi funkcí systému˚ operátoru˚ sloužících k ovˇerˇ ování dostupnosti DSL na vybraném koncovém vedení, na spoleˇcný výstup.

17

2. P ROCES

OBJEDNÁNÍ

DSL

• Na základˇe požadavku, ˚ pˇricházejících z OmniTrackeru, bude iniciovat komunikaci k operátorovi, jejímž cílem je zˇrízení, zmˇena nebo zrušení DSL pˇripojení u nˇej. • Bude pˇríjmat notifikace operátoru˚ o prubˇ ˚ ehu objednávek na zˇrízení, zmˇenu a zrušení DSL pˇripojení, tyto párovat k odeslaným objednávkám, jejich obsah transformovat do podoby srozumitelné OmniTrackeru, která jej odstíní od významových rozdílu˚ v notifikacích pocházejících od ruzných ˚ operátoru, ˚ a v této podobˇe mu je pˇredávat.

18

Kapitola 3

Návrh a implementace Tato kapitola popisuje rˇ ešení jednotlivých úkolu, ˚ které má BlackBox plnit, a které byly vytyˇceny v závˇeru pˇredcházející kapitoly. Dˇríve než pˇristoupíme k samotnému rˇ ešení, uvedeme a podrobnˇeji popíšeme systémy, se kterými BlackBox komunikuje, celkovou strukturu samotného BlackBoxu, spoleˇcné rysy a postupy aplikované v rˇ ešení a použité nástroje.

3.1 Okolní systémy Jak už víme z 2.3, BlackBox bude plnit roli prostˇredníka v komunikaci mezi ostatními systémy. Proto znovu zopakujeme, o které se jedná, navíc uvedeme jejich pˇrístupové body a zpusoby, ˚ jakými samotná komunikace probíhá. 3.1.1 OmniTracker Programovatelný systém typu klient/server, serverová cˇ ást pracuje nad databázovým strojem MS SQL Server. Do databáze lze pˇristupovat skrze API ODBC. Objeví-li se dále formulace pˇreˇcteme data z OmniTrackeru, bude to znamenat cˇ tení z databáze, nad kterou OmniTracker pracuje. OmniTracker dokáže komunikovat s okolím prostˇrednictvím e-mailu. ˚ Odesílá je na základˇe výskytu stanovené události (autorizace nebo revize objednávky DSL služby). Pˇrijaté e-maily zpracovává podle definovaných pravidel a podle údaju˚ v nich obsažených provádí urˇcené operace. Schránku, do níž BlackBox smˇerˇ uje stavové hlášky, a jejíž obsah takto OmniTracker interpretuje, oznaˇcme bb2ot. ˇ 3.1.2 Systémy Ceského Telecomu a Telenor Networks Oba systémy poskytují veskrze stejnou funkcionalitu: • Dokáží odpovˇedˇet na otázku, zda na vybraném telefonním cˇ ísle je ihned, není, nebo v blízké budoucnosti teprve bude dostupné DSL. U obou operátoru˚ je tato ˇ funkce realizována jako webová služba 1 , v systému Ceského Telecomu se jmenuje ADSLcheck, v systému Telenor Networks checkDSLAMnew. Pˇrestože obˇe funkce slouží ke stejnému úˇcelu, každá z nich poskytuje jiný výstup, uvidíme dále v 3.5.1.

1

Podle W3C: http://www.w3.org/TR/ws-arch/.

19

3. N ÁVRH

A IMPLEMENTACE

• Pˇrijímají objednávky na zˇrízení, zmˇenu nebo zrušení DSL pˇripojení na vybraném telefonním cˇ ísle. Mˇenit a rušit lze jen taková již fungující DSL pˇripojení, která byla dˇríve zˇrízena u stejného operátora. I tato funkce existuje u obou operátoru˚ v podobˇe webové služby, dokonce má v obou pˇrípadech tentýž název sendOrder. • K zadané objednávce na zˇrízení, zmˇenu cˇ i zrušení DSL pˇripojení dodávají notifikace, které popisují jejich prubˇ ˚ eh. Telenor Networks posílá notifikace ve formˇe eˇ mailu˚ na adresy pˇredem dohodnuté s providery. Ceský Telecom pˇredává notifikace voláním webové služby na stranˇe providera; tedy zatímco pˇredchozí funkce jsou v pozici serveru, protože jsou na nˇe kladeny požadavky aplikacemi provideru, ˚ tato vystupuje v roli klienta. Musí být pojmenována receiveNotif. Webové služby na stranˇe operátoru˚ jsou dostupné pomocí protokolu SOAP, jež pracuje ˇ nad pˇrenosovým protokolem HTTP. V pˇrípadˇe funkce systému Ceského Telecomu urcˇ ené pro pˇredávání notifikací se totéž oˇcekává od webové služby na stranˇe providera.

3.2 Celkový náhled na systém BlackBox Na obrázku 3.1 je schéma zachycující duležité ˚ komponenty systému BlackBox, na které budeme odkazovat pˇri podrobném popisu jeho fungování.

= > A = ? @ 4 B 5 9 < 6 6 3 4 4 8 : ; 4 7 D F > E E E 6 C ? 4 4 B D F > E E E 6 C ? 4 8 B

M 9 D < > A 6 ? 3 ? 8 : ; 4 D A 6 : ; 3 G I L H E > 6 ? ? K ; ? @ K J

Obrázek 3.1: Schéma systému BlackBox Na obrázku jsou ukázány dva stroje, pˇredstavující fyzicky ruzné ˚ poˇcítaˇce. Na tom, který je oznaˇcen jako poštovní, jsou uloženy mailboxy ot2bb a tn2bb, do nichž smˇerˇ ují e-maily po rˇ adˇe z OmniTrackeru (požadavky na odeslání objednávky operátorovi) a ze systému Telenor Networks (notifikace k objednávkám, které smˇerˇ ovaly do systému Telenor Networks). Na aplikaˇcním stroji je umístˇena databáze Oracle a jsou na nˇem provádˇeny skripty pokrývající dˇríve stanovenou funkcionalitu. Na stroji bˇeží distribuce Fedora Core operaˇcního systému Linux, z toho se odvíjí použité nástroje a techniky.

20

3. N ÁVRH

A IMPLEMENTACE

3.3 Spoleˇcný pˇrístup k rˇešení úkolu˚ Konkrétní úkoly vyžadují samozˇrejmˇe ruzná ˚ rˇ ešení, pˇresto však lze najít a vyjmenovat spoleˇcné rysy, které prostupují systémem BlackBox jako celkem. 3.3.1 Do one thing and do it well BlackBox je tvoˇren souborem nˇekolika pˇrevážnˇe dávkových aplikací. Pro naše úˇcely budeme dávkovou rozumˇet takovou aplikaci, jejíž souˇcástí není žádná forma UI (user interface), které by dovolovalo interaktivnˇe zasahovat do plnˇení úkolu. ˚ Naopak, dávková aplikace pouze naˇcte vstupní data (dávku) a ty zpracuje bez možnosti ovlivnˇení jejího chování uživatelem v dobˇe jejího bˇehu. Takové rˇ ešení bylo zvoleno proto, že dovolí rozdˇelit jeden úkol (napˇr. odesílání objednávek DSL pˇripojení operátorum) ˚ na více menších kroku˚ (dávkových aplikací) a ty pak rˇ ešit samostatnˇe. První dávka v rˇ adˇe zpracuje vstupní data úkolu, ta transformuje tak, aby byla použitelná pro další dávku v rˇ adˇe. Výstupní data poslední dávky jsou výstupem úkolu jako celku. Tato myšlenka je jednou z charakteristik un*ixových systému˚ a je struˇcnˇe vystižena napˇr. v [1] slovy: Write programs that do one thing and do it well. Write programs to work together. Typickou praktickou aplikací této filozofie jsou uni*xové roury (un*x pipes). Ty však pˇredpokládají, že jednotlivé kroky se vykonávají bezprostˇrednˇe po sobˇe, totiž, že pokud jeden program okamžitˇe nezpracuje výstupní data pˇredchozího programu, budou tato ztracena. BlackBox tuto nˇekdy nepˇríjemnou vlastnost potlaˇcuje tak, že jako úložištˇe dat, která si mezi sebou jednotlivé dávky pˇredávají, používá tabulky v databázi. Rozdˇelení vˇetšího celku na nˇekolik menších je pˇrínosné ve fázích zavádˇení systému do ostrého provozu. V pˇrípadˇe, že se vyskytne logická chyba v kódu, mužeme ˚ ji mnohem snáze lokalizovat a opravit. Menší celky kódu se také zˇrejmˇe lépe udržují. 3.3.2 Spuštˇení dávek naneˇcisto To, že dávky pracují nad daty v databázi, má tu pˇríjemnou vlastnost, že mužeme ˚ využít jejích transakˇcních schopností. Spustíme-li dávku, v jejímž prubˇ ˚ ehu nedojde k potvrzení v databázi provedených zmˇen (transaction commit), mužeme ˚ to opakovat nˇekolikrát po sobˇe. Dávka bude stále pracovat nad daty, která vyprodukovala pˇredchozí dávka, a zárovenˇ sama negeneruje (a nepotvrzuje jejich uložení v databázi) data, která by mohla pˇrevzít dávka následující. V kódu to znamená dát tomu, kdo dávku zá úˇcelem testování spouští, na terminálu podrobný pˇrehled toho, co dávka právˇe vykonává, podle cˇ eho a jak se rozhoduje, atd. Na základˇe tˇechto informací se muže ˚ uživatel rozhodnout, zda zmˇení chování dávky nebo ji spustí s pˇríznakem, že je to v rámci ostrého provozu. Jedinou výjimku tvoˇrí ty situace, kdy dávka pˇrímo interaguje s okolními systémy, a kdy nelze transakˇcnost zaruˇcit kvuli ˚ samotné povaze komunikaˇcních protokolu, ˚ tj. jednou odchozí komunikaci nelze vzít zpˇet. Nyní pouze uvedeme, že se jedná o pˇrípady 21

3. N ÁVRH

A IMPLEMENTACE

odesílání e-mailu˚ o stavu objednávky DSL pˇripojení do OmniTrackeru a komunikaci protokolem SOAP pˇri zadávání objednávky pˇripojení operátorovi. Jak uvidíme dále, tyto výjimky se budeme snažit rˇ ešit zavedením front, z nichž každá bude shromažd’ovat elementy komunikace (e-maily a SOAP požadavky) zvoleného protokolu. I tyto fronty jsou realizovány jako objekty v databázi. Tyto elementy budou skuteˇcnˇe použity pro komunikaci (e-mail bude odeslán, SOAP požadavek bude vykonán) jen v pˇrípadˇe, že dávka, která je vygenerovala, potvrdí jejich setrvání v databázi, tzn. bude spuštˇena v rámci ostrého provozu. 3.3.3 Použité nástroje Dávky a veškerý ostatní kód jsou napsány v jazyce Perl. Perl je skriptovací jazyk pu˚ vodnˇe urˇcený ke zpracování velkých objemu˚ textu. Postupem cˇ asu se z nˇej vyvinul nástroj, který je používán pro mnoho ruzných ˚ úkolu, ˚ od správy systému˚ až po internetové aplikace. Pˇrestože jde o interpretovaný jazyk, je co do rychlosti srovnatelný s jazyky kompilovanými. Pˇrímým dusledkem ˚ tˇechto vlastností je efektivní kolobˇeh kódování, testování, nasazení. Perl je výteˇcný pro rychlé prototypování a jeho výsledky lze použít i v ostrém provozu. Možnost nasazení Perlu v mnoha odvˇetvích je se odvíjí od existence archivu modulu, ˚ které nabízí funkcionalitu potˇrebnou právˇe pro danou oblast problému, pojmenovaného CPAN (Comprehensive Perl Archive Network). Z mnoha modulu˚ na CPAN dostupných používá BlackBox tyto mj. tyto vybrané: • DBI Obecné API pro práci s databází (navázání spojení, vykonávání SQL pˇríkazu˚ a dotazu, ˚ pˇrístup k jejich výsledkum), ˚ používá se v kombinaci s ovladaˇcem pro konkrétní databázový systém (napˇr. DBD::Oracle). Podrobná dokumentace je dostupná v [5]. • MIME::Parser a MIME::Entity Dokáží analyzovat a naopak syntetizovat e-mailové zprávy a pracovat s nimi jako se strukturami jazyka Perl, viz. [6] a [7]. • SOAP::Lite Díky nˇemu lze velmi snadno vytvoˇrit klientskou i serverovou SOAP aplikaci, která muže ˚ pracovat na ruzných ˚ pˇrenosových protokolech (nejbˇežnˇejší je HTTP, ale lze použít i pˇrímo TCP), bližší informace poskytne [8]. Jako databázový stroj je používán produkt firmy Oracle. Svuj ˚ databázový systém vyvíjí více než dvacet let, díky tomu patˇrí ve svém oboru ke svˇetové špiˇcce. Používá pro vývojáˇre velmi vstˇrícnou licenˇcní politiku, která se dá shrnout takto: do té doby, než bude aplikace, jejíž souˇcástí je databázový systém Oracle, nasazena v produkˇcním provozu, mužete ˚ ji používat zdarma (je dostupná na internetových stránkách firmy Oracle). Tak muže ˚ vývojáˇr vytvoˇrit a otestovat svou aplikaci, aniž by musel investovat peníze do koupˇe databázového systému. Zdarma je také k dispozici rozsáhlá a podrobná dokumentace. K tomu je databázový systém Oracle již ve firmˇe SkyNet používán v jiných projektech než BlackBox a bylo nasnadˇe jej využít i pro tento úˇcel. 22

3. N ÁVRH

A IMPLEMENTACE

Souˇcástí instalace databázového serveru Oracle je sada knihoven funkcí (balíku) ˚ jazyka PL/SQL. Jedním z nich je balík dbms_pipe. Nabízí prostˇredky pro komunikaci dvou ruzných ˚ aplikací, které jsou pˇripojeny k databázi. Komunikace probíhá za pomoci front. Nikoliv však takových, které jsou reprezentovány tabulkami, jak jsme vidˇeli v 3.3.1. Fronty jsou udržovány ve sdílené pamˇeti procesu˚ databázového serveru2 . Manipulaci s frontami (vytváˇrení, rušení, pˇrístup do nich) je možná právˇe díky funkcím balíku dbms_pipe, viz. [9]. ˇ 3.3.4 Rešení bˇehových chyb Pˇri tvorbˇe softwaru se muže ˚ stát, že jeho autor zanese do kódu nˇekolik druhu˚ chyb. Logické chyby, tzn. takové, které znamenají významovˇe jiné výstupy, než autor nebo zadavatel oˇcekával, pominme. ˇ Syntaktické chyby odhalí snadno kompilátor nebo interpret programovacího jazyka, ve kterém je vytváˇrený kód psán. Zbývají chyby, které mohou nastat za bˇehu programu. Typickou bˇehovou chybou je dˇelení nulou. Pˇri práci s databází muže ˚ být její pˇríˇcinou špatnˇe formulovaný (invalidní) SQL dotaz, který klademe databázi. Pˇríklad bˇehové chyby pˇri práci s databází použijeme v dalších odstavcích. Modul DBI dokáže reagovat na chyby, které mu vrací databázový stroj, nˇekolika zpu˚ soby. Nastane-li chyba pˇri práci s databází, muže ˚ zprávu o jejím výskytu pouze vypsat na terminál a nastavit pˇríznaky, testováním kterých muže ˚ aplikace chybu ošetˇrit. Tak se ale muže ˚ stát, že programátor opomene zasadit do kódu rutinu, která chybu na pˇríslušném místˇe v aplikaci ošetˇrí. Ve skriptech, které jsou souˇcástí BlackBoxu, je použit jiný zpusob. ˚ Oznámí-li databázový server chybu, modul DBI zpusobí ˚ vyvolání výjimky (funkcí die jazyka Perl) a aplikace bude násilnˇe ukonˇcena. Není však žádoucí, aby aplikace konˇcila svuj ˚ bˇeh takto násilnˇe. Vyjimky lze zachycovat obalením fragmentu˚ kódu do konstrukce eval{}. Pˇri výskytu výjimky je nastavena jistá interní promˇenná jazyka Perl, testováním které je možné zjistit výskyt výjimky a tuto ošetˇrit. Kdykoliv k takové chybˇe dojde, je odeslán e-mail nˇekomu, oznaˇcme jej jako správce BlackBoxu, který by mˇel být schopen chybu nalézt a odstranit. Nemá význam o takových událostech informovat OmniTracker, protože bˇehové chyby nesouvisí s procesem rˇ ešení objednávek DSL služeb. E-maily jsou správci posílány pˇrímo, narozdíl od 3.11.1, tedy bez indirekce v podobˇe tabulky, poštovní fronty.

3.4 Distribuce cˇ íselníku˚ Prvním úkolem BlackBoxu je distribuce cˇ íselníku˚ z OmniTrackeru k zákaznické aplikaci. Nejdˇríve musíme uvést, které cˇ íselníky jsou používány a jaký je jejich význam.

2

Z toho plyne, že jejich obsah bude ztracen, budou-li procesy serveru ukonˇceny, protože bude uvolnˇena jimi sdílená pamˇet.

23

3. N ÁVRH

A IMPLEMENTACE

3.4.1 Pˇrehled cˇ íselníku˚ Jak jsme uvedli dˇríve, produktové oddˇelení používá OmniTracker pro definování DSL služeb, jejich aktuální nabídku zveˇrejnuje ˇ zákaznická aplikace. Pro popis DSL služby, resp. tˇech jejích aspektu, ˚ které souvisejí s DSL pˇripojením, byly zvoleny tyto atributy: • Pˇri zˇrizování DSL pˇripojení musíme vˇedˇet, kterého operátora chceme využít, tzn. DSLAM kterého operátora bude oddˇelovat provoz v nadhovorovém pásmu telefonní linky a ten interpretovat jako pˇripojení k Internetu. • Každý operátor nabízí nˇekolik tarifu, ˚ které se liší na základˇe toho, zda je poskytováno asymetrické cˇ i symetrické DSL pˇripojení a s jakou agregací. Tarify jsou identifikovány kódem a jménem, které zvolil pˇríslušný operátor. Provider si zˇrejmˇe volí vlastní obchodní oznaˇcení tarifu, ˚ které nabízí, byt’ jde o mapování na tarify operátora. • Prvkem, bez kterého nelze DSL pˇripojení používat, je DSL modem. Ten muže ˚ nabízet operátor jako souˇcást svého tarifu (volitelnˇe i s instalací), nebo provider v rámci své nabídky. • Zákazník má na výbˇer, zda chce DSL modem koupit, cˇ i si jej od operátora nebo providera pouze pronajmout. Mluvíme o službˇe nad modemem. • Zákazníci si mohou vybrat z nˇekolika druhu˚ instalace DSL modemu podle úrovnˇe své technické kompetence, která je potˇrebná k zaˇclenˇení modemu do operaˇcního systému. Pˇri definic pˇetic, které popisují DSL službu, musí produktové oddˇelení dbát na to, aby kombinace hodnot atributu˚ byly smysluplné. Uved’me nˇekteré protipˇríklady: • Identifikace tarifu nekoresponduje s operátorem. • Provider nabízí jako souˇcást svého tarifu modem a ten je zárovˇenˇ souˇcástí tarifu operátora. • Zvláštní hodnotou v cˇ íselníku modemu˚ je ta, která vystihuje, že zákazník má vlastní modem, a proto nemá zájem, aby byl tento souˇcástí DSL služby. Tu hodnotu tedy nemá smysl kombinovat s koupí ani pronájmem coby služby nad modemem. • Nemá smysl nabízet instalaci modemu, je-li tato souˇcástí tarifu operátora. 3.4.2 Zpusob ˚ pˇredávání ˇ Císelníky uchovává OmniTracker v tabulkách v databázi, s níž pracuje. Pro distribuci cˇ íselníku˚ je duležitá ˚ událost, která znamená zmˇenu v nˇekterém z nich. OmniTracker uchovává historii zmˇen v cˇ íselnících, ale jen tak, že nedovolí fyzicky smazat položky v cˇ íselníku, jen jim nastavuje pˇríznak, který znamená, že není možné jej použít v definici nové DSL služby. Zejména tedy neeviduje cˇ asové údaje o tom, odkdy a dokdy byla ta která položka cˇ íselníku použitelná v definicích DSL služeb. 24

3. N ÁVRH

A IMPLEMENTACE

Protože cˇ asový údaj o konci platnosti položky cˇ íselníku muže ˚ být užiteˇcný (byt’ jen pro úˇcely produktového oddˇelení), BlackBox jej pˇri zmˇenách cˇ íselníku˚ urˇcuje a uchovává podle obsahu cˇ íselníku˚ v OmniTrackeru a podle jejich kopie ve vlastní databázi. OmniTracker oznamuje BlackBoxu zmˇenu v nˇekterém z výše uvedených cˇ íselníku˚ emailem smˇerovaným do mailboxu ot2bb na poštovním stroji, viz. 3.2. Obsah mailboxu vybírá skript bin/save_ot_request.pl, který je spouštˇen programem fetchmail v roli MDA (Mail Delivery Agent) na aplikaˇcním stroji. Tento skript uloží novˇe pˇríchozí e-mail do tabulky buffer, podobnˇe viz. 3.7. Na aplikaˇcním stroji probíhá veškeré další zpracování požadavku˚ na aktualizaci cˇ íselníku˚ zákaznické aplikace. Tabulka buffer bude ještˇe nˇekolikrát zmínˇena, a to pˇri popisu implementace dalších úkolu, ˚ pro nás jsou v tomto okamžiku duležité ˚ atributy: • type Rozlišuje, který druh vstupních dat ubsahuje atribut data, a tedy, jak mají být tato data interpretována; pro e-maily pˇricházející z OmniTrackeru byla zvolena hodnota mail request from ot. • status Znaˇcí, zda byl pˇríslušný záznam již zpracován nˇekterou další dávkou, a jak s ním bylo naloženo. V okamžiku, kdy MDA uloží e-mail z OmniTrackeru do tabulky buffer, bude obsahovat hodnotu not processed. • data Samotná data – hlaviˇcky a tˇelo e-mailu. Z tabulky buffer vybírá dosud nezpracované záznamy skript bin/process_ot_ request.pl. Nejprve rozliší, zda jde skuteˇcnˇe o požadavek na akutalizaci cˇ íselníku. ˚ Do stejného mailboxu totiž OmniTracker odesílá i požadavky na odeslání objednávky operátorovi, viz. 3.7. V e-mailu, který znamená aktualizaci cˇ íselníku, ˚ je obsažen název tabulky v databázi OmniTrackeru, která obsahuje data cˇ ísleníku. Sám skript bin/process_ot_request. pl neprovádí samotnou aktualizaci cˇ íselníku˚ ani v databázi BlackBoxu, ani v zákaznické aplikaci. Jen naplní frontu, která shromažd’uje požadavky na aktualizaci, s tou pak pracuje další dávka. Tabulka byla pojmenována update_queue, její atributy jsou: • table_name Jméno cˇ íselníku, který se má podle údaju˚ z OmniTrackeru aktualizovat v databázi BlackBoxu i v zákaznické aplikaci. Muže ˚ nabývat hodnot operator, tarif, modem, instalace, modem_sluzba a sluzba. Jejich význam je dle 3.4.1 zˇrejmý. Tyto hodnoty jsou zárovenˇ názvy tabulek, ve kterých jsou uloženy pˇríslušné cˇ íselníky v databázi BlackBoxu. • status Popisuje, v jakém stadiu zpracování požadavek na aktualizaci cˇ íselníku je. Pˇrípustné hodnoty jsou Q (pˇri zaˇrazení do fronty), P (požadavek je právˇe zpracováván), S (zákaznická aplikace byla úspˇešnˇe upozornˇena na nový obsah cˇ íselníku) a U (pˇri upozornování ˇ zákaznické aplikace na nová data v cˇ íselníku došlo k chybˇe). 25

3. N ÁVRH

A IMPLEMENTACE

• response Tˇelo HTTP odpovˇedi té cˇ ásti zákaznické aplikace, která pˇrebírá obsah cˇ íselníku. V nˇem je pro vizuální kontrolu uvedeno, kolik záznamu˚ z cˇ íselníku zákaznická aplikace pˇreˇcetla. OmniTracker posílá do BlackBoxu tolik požadavku˚ na aktualizaci vybraného cˇ íselníku, kolik zmˇen v nˇem bylo provedeno3 . Zákaznické aplikaci je ale zˇrejmˇe tˇreba pˇredat jeho nový obsah pouze jednou. Proto skript bin/process_ot_request.pl ukládá do fronty update_queue pro každý cˇ íselník nejvýše jeden požadavek na jeho aktualizaci. Posledním cˇ lánkem v rˇ etezu je daemon daemon/dsl_update.pl, který vybírá novˇe zaˇrazené záznamy (status je roven Q) z tabulky update_queue. O takových novˇe vložených záznamech se dozví díky opakovanému cˇ tení z fronty dsl_update vytvoˇrené pomocí funkcí balíku dbms_pipe systému Oracle, viz. 3.3.3. Zprávy vkládá do fronty dsl_update trigger definovaný na tabulce update_queue pokaždé, když je do tabulky update_queue vložen nový záznam. Není duležitý ˚ obsah zprávy, jen její pˇrítomnost ve frontˇe dsl_update. Díky ní daemon pozná to, že do fronty update_queue pˇribyl nový záznam, a on má zaˇcít pracovat. První, co daemon udˇelá, je, že zpracovávanému záznamu nastaví status na P. Pak volá skript bin/cache/.pl, kde je hodnota atributu table_name, tj. oznaˇcení cˇ íselníku, ve kterém došlo ke zmˇenˇe. Z toho plyne, že pro každý cˇ íselník existuje jeden skript, který cˇ te nový obsah cˇ íselníku z OmniTrackeru a ukládá jej do databáze BlackBoxu. Pak daemon vykoná HTTP požadavek na neveˇrejnou funkci zákaznické aplikace. Nepˇredává pˇri nˇem nový obsah cˇ íselníku˚ zákaznické aplikaci, jen ji vyzve, aby sama nová data pˇreˇcetla. Z parametru URL, na který daemon smˇerˇ oval požadavek, zákaznická apliˇ kace pozná cˇ íselníky, jejichž obsah má pˇreˇcíst. Ctení uskuteˇcnuje ˇ zákaznická aplikace HTTP požadavkem zpˇet do BlackBoxu, konkrétnˇe na jeden ze skriptu˚ www/services/ .mpl. opˇet urˇcuje název cˇ íslníku. Tyto skripty vrací v podobˇe XML jednotlivˇe obsah pˇríslušného cˇ íselníku. Odpovˇed’ zákaznické aplikace na HTTP požadavek daemona uloží tento do sloupce response. Tím zpracování záznamu z fronty update_queue konˇcí, daemon nastaví status na S (volání zákaznické aplikace probˇehlo bez chyb) nebo U. Na závˇer zbývá podrobnˇeji popsat skripty bin/cache/.pl, které aktualizují cˇ íselníky v databázi BlackBoxu. Aktualizování ruzných ˚ cˇ íselníku˚ se vzájemnˇe neliší, vždy se mˇení jen název tabulky v databázi OmniTrackeru, jejíž obsah se porovnává s obsahem pˇríslušné kopie v BlackBoxu, a jejich primární klíˇce. Sekvenˇcnˇe jsou procházeny zárovenˇ cˇ íselník v OmniTrackeru a jeho kopie v BlackBoxu podle uspoˇrádání primárních klíˇcu. ˚ Pˇri takovém pruchodu ˚ mohou nastat tˇri situace: primární klíˇce se shodují, pak je tˇreba zkontrolovat, zda se ostatní atributy záznamu˚ shodují a pˇrípadnˇe aktualizovat záznam v BlackBoxu. Nebo je primární klíˇc záznamu v OmniTrackeru vyšší než klíˇc záznamu v BlackBoxu, to znamená, že v OmniTrackeru existuje záznam, který není v BlackBoxu. Pak je tento vložen do cˇ íselníku v BlackBoxu. Tˇretí pˇrípad je opakem pˇredchozího, tedy 3

Když produktové oddˇelení definuje deset nových DSL služeb, OmniTracker odešle deset e-mailu˚ s upozornˇením na zmˇenu cˇ íselníku DSL služeb.

26

3. N ÁVRH

A IMPLEMENTACE

v kopii cˇ íselníku v BlackBoxu je záznam, který není v OmniTrackeru. To je ale prohˇrešek proti dohodˇe, že v cˇ íselnících v OmniTrackeru se nebudou záznamy mazat, nýbrž jen zneplatnovat ˇ nastavením nˇejakého pˇríznaku. Aby nebylo potˇreba psát velmi podobný kód, který by se lišil jen v takových drobnostech, byl vytvoˇren modul perllib/ADSL/Cache.pm. Obsahuje funkci, která obecnˇe provádí takový sekvenˇcní pruchod ˚ pˇríslušných dvojic cˇ íselníku˚ v OmniTrackeru a BlackBoxu. Parametry lze rˇ íct, který cˇ íselník konkrétnˇe má být v BlackBoxu aktualizován.

3.5 Zjišt’ování dostupnosti DSL Systémy operátoru˚ disponují funkcí, která odpovídá na otázku, zda je na telefonní lince dostupné DSL pˇripojení, viz. 3.1.2. Pˇripomenme, ˇ že služby obou operátoru˚ vrací ve svém obsahu i struktuˇre jiná data. Zákaznická aplikace na základˇe údaju˚ o dostupnosti dovolí cˇ i nedovolí DSL službu vu˚ bec objednat a není žádoucí, aby ona sama interpretovala ruzné ˚ výstupy operátoru, ˚ protože její úˇcel je pouze prezentaˇcní. BlackBox proto odvozuje z rozdílných informací jejich spoleˇcný významový základ. 3.5.1 Výstupy služeb operátoru˚ Služby obou operátoru˚ vrací data ve formátu XML. U obou následuje pˇríklad obsahující pouze prázdné elementy, jejichž význam bude vysvˇetlen. Sekci uzavˇre XML, které vrací BlackBox zákaznické aplikaci. Jako první uvedeme službu checkDSLAMnew operátora Telenor Networks, její výstup je ukázán na výpisu 3.1. Pˇrípustné hodnoty elementu CodeDSLAM a jejich význam ˇ je v tabulce 3.1. Výpis 3.2 ukazuje výstup služby ADSLcheck Ceského Telecomu, význam jednotlivých elementu˚ popisuje tabulka 3.2. Z pˇredchozího pak byla odvozena struktura ve výpise 3.3, která je vracena zákaznické aplikaci. Výpis 3.1: Výstup služby checkDSLAMnew Výpis 3.2: Výstup služby ADSLcheck <MaxSpeed/> 27

3. N ÁVRH CodeDSLAM NACTV NODSL PSAVP ISAVP NOLSN PSAVL ISAVL ERROR QUOTA

A IMPLEMENTACE

význam Telefonní cˇ íslo není aktivním cˇ íslem úˇcastníka v síti ˇ Ceského Telecomu. Telefonní cˇ íslo není v dosahu kolokace. Telefonní cˇ íslo v PSTN síti zatím není v dosahu kolokace, v dosahu bude od data uvedeného v DateDSLAM. Telefonní cˇ íslo v ISDN síti zatím není v dosahu kolokace, v dosahu bude od data uvedeného v DateDSLAM. Zadané telefonní cˇ íslo není hlavním cˇ íslem ISDN linky. Telefonní cˇ íslo v PSTN síti je v dosahu kolokace. Telefonní cˇ íslo v ISDN síti je v dosahu kolokace. Pˇri zpracování požadavku došlo k chybˇe. Poˇcet dotazu˚ za cˇ asovou jednotku pˇresáhl stanovený limit.

Tabulka 3.1: Hodnoty elementu CodeDSLAM na výstupu služby checkDSLAMnew.

Výpis 3.3: Výstup skriptu check_dslam.mpl <status/> Elementy obsažené ve výpisu 3.3 vysvˇetluje tabulka 3.3. Hodnoty elementu˚ allow_ order, lsn, line_type a date se odvozují z odpovˇedí operátoru˚ podle následujícího pˇredpisu: • Vrací-li služba checkDSLAMnew v elementu CodeDSLAM hodnotu NOACTV, nebo vrací-li služba ADSLcheck v elementu Owner hodnotu OTHER, pak element allow_order bude obsahovat hodnotu no a dslam_message_id ˇ bude odkazovat na text, jenž rˇ íká, že dané cˇ íslo není aktivním cˇ íslem v síti Ceského Telecomu. 28

3. N ÁVRH element ADSLresult

DSLAMavailability

DSLAMdate

MaxSpeed

CompatibilityProblem

Owner

LSN

LineType

A IMPLEMENTACE

popis elementu a pˇrípustné hodnoty Parametr, který obsahuje souhrnnou odpovˇed’ na otázku, zda lze na daném cˇ ísle objednat ADSL. Vyplývá z logického souˇcinu hodnot ve sloupci &. Výsledek 1 implikuje YES, 0 zˇrejmˇe NO. Jediný povinný element. YES DSL lze pro dané cˇ íslo objednat. NO DSL nelze pro dané cˇ íslo objednat. ERROR Chyba pˇri zpracování požadavku. TIMEOUT Interní systémy neodpovˇedˇely v limitu. QUOTA Byla pˇrekroˇcena kvóta požadavku˚ za cˇ asovou jednotku. Dostupnost DSLAM pro dané cˇ íslo. 1 DSLAM je disponibilní. 2 DSLAM má vyˇcerpanou kapacitu, dostavba plánována do dne viz. DSLAMdate. 3 DSLAM není disponibilní, ale bude ode dne viz. DSLAMdate. 4 DSLAM není disponibilní. Obsahuje datum pro hodnoty 2 a 3 elementu DSLAMavailability. datum Datum ve formátu dd.mm.rrrr. ˇ Retˇezec popisující maximální rychlost ADSL, které je možné na dané lince dosáhnout. 1024/256 512/128 256/64 0 Na dané lince nelze provozovat ADSL. UNKNOWN Maximální rychlost se nepodaˇrilo zjistit. Sluˇcitelnost s jinými službami na tomto cˇ ísle. YES NO Vlastník telefonního cˇ ísla. CTC OTHER Obsahuje hlavní cˇ íslo ISDN linky, byl-li dotaz položen na vedlejší cˇ íslo linky. tel. cˇ íslo Hlavní cˇ íslo ISDN linky. Informativní údaj o typu linky. PSTN Vybrané cˇ íslo je PSTN cˇ íslo. ISDN Vybrané cˇ íslo je ISDN cˇ íslo.

&

1

1 1 0

1

1 1 1 0 1 1 0 1 0

0 1 1

Tabulka 3.2: Popis elementu˚ výstupu služby ADSLcheck.

29

3. N ÁVRH

A IMPLEMENTACE

• Vrací-li služba checkDSLAMnew v elementu CodeDSLAM hodnotu NODSL, nebo vrací-li služba ADSLcheck v elementu DSLAMavailability hodnotu 4, pak element allow_order bude obsahovat hodnotu no a dslam_message_id bude odkazovat na text, jenž rˇ íká, že pro dané cˇ íslo není disponibilní DSLAM. • Vrací-li služba checkDSLAMnew v elementu CodeDSLAM hodnotu NOLSN, nebo vrací-li služba ADSLcheck neprázdný element LSN, pak element allow_order bude obsahovat hodnotu no a dslam_message_id bude odkazovat na text, jenž rˇ íká, že vybrané cˇ íslo není hlavní cˇ íslo ISDN linky. V pˇríˇ padˇe Ceského Telecomu bude element lsn obsahovat hodnotu elementu LSN. • Vrací-li služba checkDSLAMnew v elementu CodeDSLAM jednu z hodnot ISAVP nebo PSAVP, nebo vrací-li služba ADSLcheck v elementu DSLAMavailability hodnotu 2 cˇ i 3 a v elementu ADSLresult hodnotu YES, pak element allow_order bude obsahovat hodnotu yes, element date hodnotu elementu DateDSLAM resp. DSLAMdate, element line_type hodnotu isdn resp. pstn a dslam_message_id bude odkazovat na text, jenž rˇ íká, že na daném cˇ ísle bude DSL dostupné teprve k uvedenému datu, ale vaši objednávku pˇrijmeme již ted’. • Vrací-li služba checkDSLAMnew v elementu CodeDSLAM jednu z hodnot ISAVL a PSAVL, nebo vrací-li služba ADSLcheck v elementu ADSLresult hodnotu 1 a v elementu ADSLresult hodnotu YES, pak element allow_order bude obsahovat hodnotu yes, element line_type hodnotu isdn resp. pstn a dslam_message_id bude odkazovat na text, jenž rˇ íká, že na daném cˇ ísle lze zˇrídit DSL již nyní. • Vrací-li služba checkDSLAMnew v elementu CodeDSLAM jednu z hodnot ERROR a QUOTA, nebo vrací-li služba ADSLresult nˇekterou z hodnot ERROR, QUOTA a TIMEOUT, pak element allow_order bude obsahovat hodnotu no a dslam_message_id bude odkazovat na text, jenž rˇ íká, že systém operátora není schopen vrátit odpovˇed’, zkuste pozdˇeji. • Vrací-li služby checkDSLAMnew nebo ADSLcheck jiné kombinace hodnot pˇríslušných elementu, ˚ pak element allow_order bude obsahovat hodnotu no a dslam_message_id bude odkazovat na text, jenž rˇ íká, že na daném cˇ ísle není možné zˇrídit DSL. • O tom, kdy a cˇ ím se plní element status, pojednává sekce 3.5.2.

3.5.2 Dotazování na dostupnost DSL Na skript www/services/check_dslam.mpl pokládá zákaznická aplikace HTTP dotaz metodou GET s jediným parametrem cli udávájícím telefonní cˇ íslo, na nˇemž chce 30

3. N ÁVRH element cli operator operator_req allow_order line_type lsn date status dslam_message_id

A IMPLEMENTACE

význam a hodnoty Telefonní cˇ íslo, na které zákaznická aplikace pokládá dotaz. Obaluje elementy dále uvedené. Má násobný výskyt, poˇcet odpovídá poˇctu operátoru. ˚ ˇ Císelný identifikátor operátora, odkaz na primární klíˇc v cˇ íselníku operátoru. ˚ Rozlišení, zda chceme dát zákazníkovi možnost objednat. Muže ˚ nabývat hodnot yes a no. Typ linky v pˇrípadˇe, že jej lze odvodit z odpovˇedi operátora. Hlavní cˇ íslo ISDN linky, pokud je obsaženo v odpovˇedi operátora. Datum pˇredpokládané dostupnosti DSL. Pˇríznak, že zatím nezná odpovˇed’ operátora, ale pracuje na tom, aby ji získal, viz. 3.5.2. Odkaz na primární klíˇc tabulky, která obsahuje vysvˇetlující texty o dostupnosti DSL na vybraném cˇ ísle. Tyto texty zobrazuje zákaznická aplikace.

Tabulka 3.3: Popis atributu˚ spoleˇcné struktury popisující dostupnost DSL.

zjistit dostupnost DSL. Triviální rˇ ešení check_dslam.mpl by bylo takové, že by skript položil dotaz na pˇríslušnou funkci v systému obou operátoru, ˚ jejich odpovˇedi by transformoval na spoleˇcný výstup a ten by pˇredal nazpˇet zákaznické aplikaci. Takové rˇ ešení není vyhovující hned ze dvou duvod ˚ u. ˚ V pˇrípadˇe, že odezva systému˚ operátoru˚ bude nezanedbatelná4 , bude dlouho cˇ ekat zákaznická aplikace a tedy i zákazník. Doba cˇ ekání bude tím delší, že dotazy jsou pokládány sekvenˇcnˇe. Zákazník po tu dobu nemá zpˇetnou vazbu o tom, zda dotazování probíhá, nebo jestli nastala chyba. Jediné, co mu webový prohlížeˇc oznámí, je timeout dotazu na zákaznickou aplikaci. Takové chování muže ˚ zákazníka odradit a ten muže ˚ opustit zákaznickou aplikaci, aniž by zadal objednávku. Zpˇetnou vazbu zajišt’uje zákaznická aplikace tak, že nedostane-li na svuj ˚ dotaz v krátkém cˇ ase (do tˇrí vteˇrin) odpovˇed’, pak dotaz zopakuje a zárovenˇ dá zákazníkovi znát, že pracuje. Takový kolobˇeh zopakuje nejvýše desetkrát. Nepodaˇrí-li se jí získat odpovˇed’ ani po deseti pokusech, oznámí to zákazníkovi s poznámkou, aby to zkusil pozdˇeji. Takový postup sice rˇ eší zpˇetnou odezvu zákazníkovi, ale pˇrináší s sebou nˇekteré komplikace. Když zákaznická aplikace položí deset krátce po sobˇe následujících dotazu, ˚ muže ˚ to v nejhorším pˇrípadˇe znamenat deset zárovenˇ bˇežících procesu˚ na aplikaˇcním stroji. To proto, že protokol HTTP je ve své podstatˇe bezstavový, neudržuje návaznost mezi jednotlivými dotazy na server, a každý nový dotaz znamená nový proces5 . Poˇcet 4 5

Bˇežná odezva je v rˇ ádech jednotek až desítek milisekund, muže ˚ ale dosáhnout až desítek sekund. Konkrétnˇe je použit HTTP server Apache, který funguje bˇežnˇe tak, že existuje jeden proces, který poslouchá na portu 80 bežném pro službu WWW. Sám HTTP dotazy nevyˇrizuje, pˇredá je pouze ke zpracování

31

3. N ÁVRH

A IMPLEMENTACE

bˇežících procesu˚ je tˇreba ještˇe znásobit poˇctem zákazníku, ˚ kterí souˇcasnˇe používají zákaznickou aplikaci. Tak bude docházet k neúnosnému zatížení aplikaˇcního stroje, ale i systému˚ operátoru, ˚ jichž se bude www/services/check_dslam.mpl tázat. Zkušenost ukázala, že toto zatížení muže ˚ být natolik fatální, že aplikaˇcní stroj nebude schopen vyˇrizovat jakékoliv další HTTP požadavky. Kupení bˇežících procesu˚ skriptu www/services/check_dslam.mpl nezabráníme. Mužeme ˚ ale zabránit tomu, aby se kupily neúnosnˇe dlouhou dobu. Pˇresnˇeji, pokud operátor neodpoví v rozumnˇe krátké dobˇe, rˇ eknˇeme do deseti vteˇrin, pak proces ukonˇcíme. Také lze eliminovat pˇrípad, kdy se zákaznická aplikace ptá desetkrát na to stejné telefonní cˇ íslo, což by v naivním rˇ ešení www/services/check_dslam.mpl znamenalo deset dotazu˚ na systémy operátoru. ˚ Provedeme to tak, že jakmile získáme odpovˇed’ operátora na dotaz o dostupnosti DSL na vybraném cˇ ísle, uložíme ji do keše. Bude-li se pak zákaznická aplikace ptát na takové cˇ íslo a budou-li data v keši dostateˇcnˇe cˇ erstvá, rˇ eknˇeme ne starší než nˇekolik hodin, budeme vracet údaje z keše. Budou-li starší, pak nezbývá, než znovu provést dotaz na systém operátora. Jak je uvedeno v 3.5.1, oba operátoˇri vrací jiná data, proto musíme zˇrídit dvˇe ruzné ˚ keše, jejichž obsah budeme transformovat na spoleˇcný výstup. Pro Telenor Networks ˇ je to tabulka dslam_cache_tn, pro Ceský Telecom dslam_cache_ctc. Jejich sloupce odpovídají elementum ˚ vyjma koˇrenového z odpovídajících XML struktur. Protože jsme výše rˇ ekli, že skript, kterého se ptá zákaznická aplikace, nevyhnutelnˇe po deseti vetˇrinách ukonˇcíme, muže ˚ se stát, že pˇri sekvenˇcním tázání systému˚ operátoru˚ bychom získali odpovˇed’ od jednoho operátora, ale už bychom nestihli získat odpovˇed’ druhého operátora. Nabízí se rˇ ešení pokládat dotazy na systémy operátoru˚ paralelnˇe. To provedeme tak, že spustíme na pozadí jiný skript, konkrétnˇe bin/dslam_cache_dispatch.pl. Teprve ten se bude dotazovat operátora a výsledky pˇredá volajícímu skriptu, resp. uloží je do keše, odkud je tento vyzvedne. Zákaznická aplikace tedy provede nejvýše desetkrát dotaz na bin/check_dslam.mpl, který bud’ vrátí data z keše, nebo v odpovˇedi vrátí pˇríznak, že skript dˇríve spuštˇený na pozadí pracuje na jejich získání od operátora. Nastavením pˇríznaku myslíme naplnˇení elementu status hodnotou waiting, viz. tabulka 3.3. Vždy pobˇeží nejvýše dva procesy skriptu bin/dslam_cache_dispatch.pl6 . Každý z nich bude zjišt’ovat údaje o dosupnosti u jednoho z operátoru. ˚ Toho dosáhneme tak, že pˇri každém spuštˇení skriptu bin/dslam_cache_dispatch.pl bude tento zjišt’ovat, zda již nebˇeží jiná jeho instance. To zjistí z tabulky dslam_cache_dispatch. V té bude uložen PID procesu, dˇríve spuštˇené instance skriptu bin/dslam_cache_ dispatch.pl a identifikátor operátora, na kterého tento proces pokládá nebo pokládal dotaz. Aby skript bin/dslam_cache_dispatch.pl vˇedˇel, na která telefonní cˇ ísla se má zeptat kterého operátora, skript www/services/check_dslam.mpl uloží tyto údaje do tabulky dslam_cache_request. Práci skriptu www/services/check_dslam.mpl ukážeme na následujícím pˇred-

6

nˇekterému z potomku, ˚ jejichž množinu udržuje. Resp. tolik, s kolika operátory v celém procesu objednávání DSL služeb poˇcítáme.

32

3. N ÁVRH

A IMPLEMENTACE

pise. Bez újmy na obecnosti budeme pˇredpokládat, že dotazy budou pokládány jen na jednoho operátora. • Zákaznická aplikace položí skriptu www/check_dslam.mpl dotaz na vybrané telefonní cˇ íslo. Ten nejdˇríve hledá v keši cˇ erstvé údaje o takovém cˇ ísle. Najde-li je, vrátí je zákaznické aplikaci. • Nejsou-li v keši cˇ erstvá data, pak www/check_dslam.mpl zjišt’uje, zda fronta požadavku˚ na dotaz k operátorovi dslam_cache_request obsahuje záznam s vybraným telefonním cˇ íslem. V pˇrípadˇe, že tomu tak není, vloží telefonní cˇ íslo do fronty. • Skript www/check_dslam.mpl dále zjistí, zda bˇeží instance skriptu bin/dslam_ cache_dispatch.pl. Jestliže ne, spustí jej. • V cyklu kontroluje, zda už se v keši cˇ erstvá data objevila, ale nejvýše po deseti vteˇrinách skonˇcí. Byla-li mezitím cˇ erstvá data vložena do keše na pozadí bˇežícím procesem bin/dslam_cache_dispatch.pl, pak je vrátí zákaznické aplikaci. V opaˇcném pˇrípadˇe nastaví element status na hodnotu waiting a zákaznické aplikaci vrátí tento výsledek. Na pozadí spouštˇený skript bin/dslam_cache_dispatch.pl provádí postupnˇe níže uvedené kroky: • Na samém poˇcátku nahlédne do tabulky dslam_cache_dispatch a zjistí, zda podle záznamu v ní již bˇeží jiná instance jeho samého. Jestli ano, pak novˇe spouštˇený proces skonˇcí, v opaˇcném pˇrípadˇe do ní vloží vlastní PID. • Pak cˇ te postupnˇe z fronty dslam_cache_request požadavky na zjištˇení dostupnosti DSL na telefonním cˇ ísle uvedeném v pˇríslušném záznamu. Na vybrané cˇ íslo se dotáže operátora (voláním odpovídající webové služby operátora), výsledek uloží do keše a zpracovávaný požadavek smaže z fronty dslam_cache_request. • Jestli je fronta požadavku˚ prázdná, smaže záznam z tabulky dslam_cache_dispatch, kde hodnota PID odpovídá jemu samotnému a skonˇcí. V dobˇe, kdy bˇeží skript bin/dslam_cache_dispatch.pl mohou do fronty dslam_ cache_request prubˇ ˚ ežnˇe pˇribývat nové požadavky tak, jak je do ní vkládají instance skriptu www/services/check_dslam.mpl na základˇe volání zákaznické aplikace.

3.6 Evidence komunikace s operátorem Než v dalších sekcích pˇrejdeme k popisu, kterak BlackBox odesílá objednávky na DSL pˇripojení operátorum ˚ a pˇríjmá na nˇe navazující notifikace, je tˇreba uvést datové struktury, které k evidenci této komunikace používá. Pro pˇrehlednost jsou níže zmínˇené tabulky a vazby mezi nimi znázornˇeny na obrázku 3.2.

33

3. N ÁVRH

A IMPLEMENTACE

Obrázek 3.2: Vztah tabulek service, operation a conversation. 3.6.1 Tabulka service Tabulka service pˇredstavuje souhrn veškeré komunikace s operátorem v rámci procesu objednávání DSL pˇripojení z pohledu providera, tedy nejménˇe jednu objednávku z pohledu operátora a k ní pˇríslušející notifikace. Významné atributy jsou: • id Jedineˇcný identifikátor záznamu. • zazaznik_req Identifikátor objednávky DSL služby v OmniTrackeru. • last_operation_id Vazba na atribut id v tabulce operation. Odkazuje na poslední objednávku, která byla odeslána operátorovi; na obrázku 3.2 je znázornˇena teˇckovanou cˇ arou. 3.6.2 Tabulka operation Tato tabulka reprezentuje komunikaci s operátorem v rámci jedné konkrétní objednávky, která k nˇemu byla odeslána. Duležité ˚ jsou zejména atributy: • id Jedineˇcný identifikátor záznamu. • service_id Odkaz na atribut id v tabulce service; na obrázku 3.2 je znázornˇen plnou cˇ arou. • type Typ objednávky smˇerem k operátorovi. Oba operátoˇri pˇríjmají tˇri základní typy objednávek: na zˇrízení nového DSL pˇripojení (objednávka typu order), zmˇenu 34

3. N ÁVRH

A IMPLEMENTACE

tarifu stávajícího pˇripojení (objednávka change) a jeho pˇrípadné zrušení (objednávka cease). Zvlášním pˇrípadem je hodnota check dslam, viz.3.7. • status Pˇríznak, který rˇ íká, že objednávka k operátorovi bˇeží (hodnota R), cˇ eká na oživení (hodnota W) nebo byla úspˇešnˇe cˇ i neúspˇešnˇe ze strany operátora dokonˇcena (po rˇ adˇe hodnoty S a U). Úspˇech znamená, že na zvoleném cˇ ísle lze používat novˇe zˇrízené nebo cˇ erstvˇe zmˇenˇené DSL pˇripojení, nebo bylo pˇripojení úspˇešnˇe zrušeno. Neúspˇech znaˇcí, že bud’ z duvod ˚ u˚ formálních (špatná kombinace telefonního a referenˇcního cˇ ísla) cˇ i technických (na lince provozuje DSL pˇripojení jiný operátor, apod.) skonˇcila objednávka k operátorovi jinak než úspˇešnˇe. • last_conversation_id Vazba na sloupec id v tabulce conversation, která ukazuje na poslední fragment komunikace s operátorem, tj. bud’ odchozí objednávku, nebo pˇríchozí notifikaci; na obrázku 3.2 je znázornˇena teˇckovanou cˇ arou. 3.6.3 Tabulka conversation Jak je zmínˇeno výše, obsahem tabulky conversation jsou již koneˇcnˇe samotná data, která si operátor a provider vymˇenují. ˇ • id Jedineˇcný identifikátor záznamu. • operation_id Vazba do tabulky operation; na obrázku 3.2 je znázornˇena plnou cˇ arou. • type Pˇríznak, zda jde o odchozí objednávku k operátorovi (hodnota order), nebo o pˇríchozí notifikaci (hodnota notification), nebo výsledek dotazu na dostupnost DSL na pˇríslušném cˇ ísle (hodnota result). • data Data, která oba operátoˇri reprezentují ve tvaru XML.

3.7 Fronta požadavku˚ na objednávky k operátorovi E-maily, které posílá OmniTracker do mailboxu ot2bb, znamenají požadavek na odeslání objednávky k operátorovi. Není v nich uveden konkrétní druh objednávky (zˇrízení, zmˇena nebo zrušení), nýbrž jen identifikátor objednávky DSL služby v databázi OmniTrackeru. Obsah schránky ot2bb uloží skript bin/save_ot_request.pl, který je spouštˇen v roli MDA programem fetchmail, do tabulky buffer. Z ní cˇ te dosud nezpracované záznamy skript bin/process_ot_request.pl. Ten ve smyslu toho, co je napsáno v 3.3.1, neodesílá objednávky k operátorovi bezprostˇrednˇe, nýbrž jen naplánuje, jaké objednávky mají být pro dané objednávky DSL služby v OmniTrackeru odeslány operátorovi. 35

3. N ÁVRH

A IMPLEMENTACE

Skript bin/process_ot_request.pl dohledá podle indentifikátoru objednávky DSL služby zakaznik_req pˇredchozí komunikaci s operátorem, která se již v rámci této objednávky uskuteˇcnila. Podle toho, zda takovou nalezne a jakou, nebo taková dosud nebyla provedena, rozhodne, jaký druh objednávky je tˇreba odeslat operátorovi. Druhy objednávek, které mají odejít k operátorovi, ukládá do fronty request_queue. Ta má následující atributy: • id Jedineˇcný identifikátor záznamu. • service_id Vazba na sloupec id v tabulce service, díky níž se muže ˚ skript, který dále zpracovává obsah této fronty, dostat k údajum ˚ v tabulce zakaznik, jenž jsou souˇcástí objednávky k operátorovi. • task Druh objednávky k operátorovi, který je tˇreba odeslat. Možné hodnoty a podle cˇ eho jsou tyto odvozeny je popsáno níže. • operation_id Vazba na sloupec id v tabulce operation. Pˇri vytvoˇrení záznamu ve frontˇe není zpravidla nastavena. Výjimku tvoˇrí požadavky na oživení u operátora cˇ ekající objednávky, toto bude rovnˇež popsáno níže. • status Stav objednávky. Pˇri vytvoˇrení záznamu ve frontˇe je nastaven na hodnotu Q (zaˇrazeno do fronty a dosud nezpracováno). • wait_for_request_queue_id Vazba na sloupec id v tabulce request_queue. Ta spolu se stavem dokáže zaruˇcit posloupnost odeslání objednávek k operátorovi v pˇrípadech, které jsou uvedeny níže. Druhy objednávek k odeslání operátorovi se odvozují podle tˇechto pravidel: • Jestli podle identifikátoru v pˇríchozím e-mailu zjistíme, že v tabulce zakaznik nemáme uloženu kopii údaju˚ z OmniTrackeru, pak jde o první požadavek na odeslání objednávky k operátorovi. To znamená, že DSL pˇripojení v rámci objednávky DSL služby dosud není zˇrízeno. Potom jsou do fronty request_queue pˇridány dva požadavky na odeslání objednávky operátorovi: – check dslam Nejde vlastnˇe o objednávku, jen o opˇetovný dotaz na dostupnost DSL na vybraném cˇ ísle. Prvotní kontrolu mˇela provést již zákaznická aplikace a ve vˇetšinˇe pˇrípadu˚ také provedla, ale v OmniTrackeru mohou výjimeˇcnˇe vzniknout objednávky DSL služby i ruˇcnˇe, zadají-li je pracovníci CustomerCare. Podle 3.5.1 navíc dovolujeme zákaznické aplikaci zadat objednávku DSL služby na telefonní cˇ íslo, na kterém není DSL dostupné ihned. Protože takové pˇrípady 36

3. N ÁVRH

A IMPLEMENTACE

vyžadují zvlášní rˇ ešení, je potˇreba je odhalit a dále s nimi zacházet odlišnˇe, jak je popsáno v 3.9. – send order Požadavek na samotné zˇrízení DSL pˇripojení. Objednávka bude odeslána k operátorovi jen v pˇrípadˇe, kdy odpovˇed’ na pˇredcházející dotaz bude znamenat okamžitou dostupnost DSL. Tady je využita vazba wait_for_request_ queue_id. • Když v tabulce zakaznik již existuje kopie údaju˚ z OmniTrackeru, jde o jiný než první požadavek na odeslání objednávky operátorovi. Pak mohou být do fronty pˇridány tyto požadavky: – send order Bude vložen tehdy, když k operátorovi dosud nebyla odeslána objednávka na zˇrízení DSL, nebo dˇríve taková skonˇcila neúspˇechem. Duvodem ˚ prvního je cˇ ekání na dostupnost DSL na vybraném cˇ ísle, v druhém pˇrípadˇe byla pˇredchozí objednávka odmítnuta (z duvodu ˚ udání nesprávné kombinace telefonního a referenˇcního cˇ ísla v objednávce) nebo technické šetˇrení, které operátor na základˇe pˇredchozí objednávky provedl, bylo negativní (na cˇ ísle je provozováno DSL jiného operátora apod.). – send resume Pˇredchozí objednávka na zˇrízení byla na stranˇe operátora pˇrepnuta do stavu, ve kterém cˇ eká na jistý úkon ze strany zákazníka, bez nˇehož nemuže ˚ operátor pokraˇcovat ve zˇrizování DSL na vybraném cˇ ísle (typicky zmˇena ISDN rozhraní na typ U a pˇri variantˇe SHDSL pˇrevod linky plnˇe pod kontrolu vybraného operátora, tedy ne jen pronájem). V pˇrípadˇe požadavku na tuto objednávku je již pˇri jeho vložení do fronty request_queue nastavena vazba do tabulky operation na ten záznam, který odpovídá právˇe zmrazené objednávce. Muže ˚ se stát, že takovou objednávku bude tˇreba odeslat v rámci zˇrizování DSL nˇekolikrát (zákazník tvrdí, že požadovaný úkon provedl, ale operátor to nemusel zaregistrovat, a proto objednávku znovu pozastavil). – send change Dˇríve odeslaná objednávka na zˇrízení skonˇcila úspˇechem, byt’ mohla být nˇekolikrát oživována, každopádnˇe na vybraném telefonním cˇ ísle už je DSL v provozu. Požadavek send change lze použít jen tehdy, když se objednávka DSL služby v OmniTrackeru odkazuje na takový záznam v cˇ íselníku DSL služeb, v jehož definici je uveden stejný operátor, u kterého je DSL pˇripojení aktuálnˇe zˇrízeno. V opaˇcném pˇrípadˇe je tˇreba použít požadavkek send cease, ze kterého vzejde objednávka k puvodnímu ˚ operátorovi, a na nˇem skrze vazbu wait_for_request_queue_id závislý požadavek send order, jenž bude znamenat objednávku na zˇrízení u novˇe zvoleného operátora. – send cease Samotný požadavek zrušení DSL pˇripojení bude odvozen z toho, že DSL pˇripojení bylo dˇríve zˇrízeno a volitelnˇe i u stejného operátora zmˇenˇeno, ale zákazník již nemá zájem DSL službu využívat. 37

3. N ÁVRH

A IMPLEMENTACE

Jak zmíníme i dále, pˇri dalším zpracování záznamu˚ z fronty požadavku˚ na objednávky operátorovi se vytváˇrí v tabulce operation vytváˇrejí nové záznamy, které jsou pˇriˇrazeny vazbou service_id k záznamu v tabulce service, a na tento nový záznam jsou naopak navˇešovány záznamy v tabulce conversation. Pˇritom jsou ve frontˇe požadavku˚ vytváˇreny vazby právˇe na záznamy v tabulce operation, ze kterých se odvozuje hodnota atributu status fronty požadavku. ˚ Nové záznamy v tabulce operation se vytvárˇ ejí i v pˇrípadˇe požadavku check dslam (protože evidujeme veškerou komunikaci s operátorem), výjimku tvoˇrí požadavek send resume, pro který musí takový záznam již existovat.

3.8 Odesílání objednávek operátorovi Objednávky k operátorovi, které vzejdou z požadavku˚ na takové objednávky ve frontˇe request_queue, procházejí dvojím odesláním. Jaký mezi jednotlivými druhy odesílání, uvedeme dále. Musíme teprve vytvoˇrit, nebo lépe složit objednávku, kterou chceme operátorovi odeslat, z údaju˚ v tabulce zakaznik a v nˇekterých cˇ íselnících, v nˇekterých pˇrípadech i z dosavadní komunikace s operátorem. Výpis 3.4: Obecná struktura objednávky k operátorovi <WsAdslOrder> <SendDate/> <SendTime/> <SalesChannel/> <MobileNumber/> <Surname/>

38

3. N ÁVRH

A IMPLEMENTACE

Ve výpisu 3.4 je uvedena obecná struktura objednávky ve tvaru XML s prázdnými elementy, jejichž význam, i to, kterými hodnotami je tˇreba je naplnit, následuje. • SendDate, SendTime Datum (ve tvaru RRRRMMDD, kde RRRR je rok, MM mˇesíc, DD den) a cˇ as (ve tvaru HH24MISS, kde HH24 je poˇcet hodin ve cˇ tyˇriadvacetihodinovém schématu, MI minuty, SS sekundy) skuteˇcného odeslání objednávky operátorovi, viz. 3.8.2. Operátor nepˇrijme objednávku, v níž se cˇ asové údaje obsažené v tˇechto elementech liší více než o dvˇe hodiny oproti cˇ asu, který on považuje za správný. Povinné elementy. • ISP Podle obsahu tohoto elementu operátor rozliší, který ISP zadává objednávku na DSL pˇripojení. Pro providera SkyNet je hodnota elementu SKY. Povinný element. • Operation Zˇrejmˇe rozlišení druhu objednávky, jejíž splnˇení oˇcekává provider ze strany operátora. BlackBox odesílá tyto druhy objednávek: ORDER, RESUME, CHANGE a CEASE; jejich význam je v kontextu dˇríve uvedeného jasný. Povinný element. • AdslPhoneNumber, ReferenceNumber Hodnotou elementu AdslPhoneNumber je telefonní cˇ íslo, na kterém chce zákazník používat DSL pˇripojení. ReferenceNumber obsahuje tzv. referenˇcní cˇ íslo linky, které u operátora, jenž je majitelem (a v rámci LLU také pronajímatelem vuˇ ˚ ci jinému operátorovi) dané místní smyˇcky, identifikuje jejího koncového pronajímatele (nikoliv operátora, ale koncového uživatele). Pˇri objednávce typu ORDER povinné elementy. • AdslService Oznaˇcení tarifu operátora. Hodnotu lze získat z cˇ íselníku tarifu, ˚ na pˇríslušný záznam vede vazba z cˇ íselníku služeb, do nˇej ukazuje záznam v tabulce zakaznik, viz. pˇríloha. Pˇri objednávce typu ORDER a CHANGE povinný element. • AdslModem Kód modemu, který bude zákazník používat pˇri DSL pˇripojení. Souˇcástí tarifu˚ Telenor Networks DSL modemy nejsou (tento element se pˇri komunikaci s ním vubec ˚ ˇ neuvádí), Ceský Telecom tuto možnost pˇripouští a na takových tarifech jsou postaveny nˇekteré DSL služby povidera SkyNet. Element má vyhrazenu hodnotu, jež znamená, že DSL modem nedodá operátor, ale nˇekdo jiný (bud’ provider, nebo sám zákazník). Povinný element pˇri druhu objednávky ORDER a v nˇekterých pˇrípadech ˇ objednávky CHANGE do Ceského Telecomu. • SalesChannel Element vyhrazený pro vnitˇrní úˇcely providera. Systém operátora vrací v notifikacích k pˇríslušné objednávce jeho nezmˇenˇený obsah. Dále uvidíme, že je plnˇen hodnotami, kterými se odkazujeme do tabulky operation. Tím docílíme toho, že objednávku a k ní odpovídající notifikace, které oboje jednotlivˇe ukládáme do tabulky 39

3. N ÁVRH

A IMPLEMENTACE

conversation, mužeme ˚ mít navázány na jediný záznam v tabulce operation, viz. vazba na obrázku 3.2. Povinný element. • PhoneNumber, MobileNumber, FaxNumber, Firstname, Surname Elementy obsahují po rˇ adˇe kontaktní telefonní cˇ íslo, cˇ íslo mobilního telefonu, faxové cˇ íslo a dvojici jména a pˇríjmení kontaktní osoby. Plní se hodnotami atributu˚ z tabulky zakaznik. Pouze poslení dva elementy jsou povinné. 3.8.1 Fiktivní odeslání Z fronty request_queue cˇ te skript bin/handle_request_queue.pl takové záznamy, které dosud nezpracoval. To pozná podle hodnoty Q atributu status. Narazí-li na požadavek check dslam, bez další indirekce (myšleno použití další fronty, jejíž obsah bude dále zpracovávat další skript) provede dotaz na dostupnost DSL na daném cˇ ísle u toho operátora, jehož tarif je souˇcástí DSL služby. To znamená, že použije schopnost modulu SOAP::Lite volat webové služby tak, jako by byly pˇrímo soucˇ ástí kódu, který se právˇe vykonává, pˇrestože jsou provádˇeny na vzdáleném stroji. Jestli bylo volání webové služby úspˇešné, tzn. na SOAP požadavek zapouzdˇrený v protokolu HTTP byla týmž zpusobem ˚ vrácena korektní odpovˇed’ a bylo možné získat XML, které služby operátoru˚ vracejí viz. 3.5.1, pak provede tyto kroky: • Vytvoˇrí nový záznam v tabulce operation s hodnotou check dslam atributu type. Zárovenˇ nastaví vazbu last_operation_id v tabulce service tak, aby ukazovala právˇe na tento novˇe pˇridaný záznam. • Vytvoˇrí nový záznam v tabulce conversation s hodnotou result atributu type. Sloupec data bude obsahovat XML, které vrátila služba pˇríslušného operátora. Ten vazbou operation_id naváže na výše vytvoˇrený záznam v tabulce operation, sloupec last_conversation_id v tabulce operation smˇerˇ uje na nový záznam v tabulce conversation. • Podle obsahu XML v odpovˇedi webové služby operátora nastaví atribut status fronty request_queue na hodnotu S (DSL je dostupné ihned), U (DSL není dostupné) nebo D (DSL bude dostupné k uvedenému datu). • Pro výše popsané hodnoty U a D vyhledá ten záznam ve frontˇe s požadavkem check dslam, který je vazbou wait_for_request_id navázán na právˇe zpracovávaný požadavek. Tomu nastaví status na F. To zpusobí, ˚ že tento požadavek nebude uskuteˇcnˇen, protože odeslat objednávku nemá v takových pˇrípadech význam. • Hodnotu D navíc vloží nový záznam do fronty dslam_queue, ve které jsou shromažd’ovány DSL objednávky cˇ ekající na dostupné DSL na vybrané lince, více viz. 3.9. Pro požadavka send order, send resume, send change a send cease provadí tyto kroky: 40

3. N ÁVRH

A IMPLEMENTACE

• S výjimkou požadavku send resume vytvoˇrí nový záznam v tabulce operation a obdobnˇe jako u požadavku check dslam naváže na tabulku service a opaˇcným smˇerem, atribut type bude mít hodnotu, kterou dostaneme odˇríznutím pˇredpony send z typu požadavku. V pˇrípadˇe požadavku send resume již záznam v tabulce operation existuje, ukazuje na nˇej již nastavený atribut operation_id fronty request_queue, viz. 3.7. • Vygeneruje XML podle vzoru 3.4 a jeho elementy naplní podle pˇredpisu. Hodnota elementu SalesChannel bude mít hodnotu identifikárou novˇe vytvoˇreného resp. již existujícího záznamu v tabulce operation. • Vygenerované XML uloží do nového záznamu v tabulce conversation s hodnotou order (odchozí objednávka) sloupce type a nastaví vazby tabulek operation a conversation jak bylo uvedeno výše. • Pomocí funkcí modulu SOAP::Lite vloží vygenerované XML do SOAP obálky. Takto utvoˇrená data uloží do tabulky buffer, jak už víme první místo, kam do BlackBoxu pˇricházejí vstupní data, a poslední, odkud odcházení výstupní. Pro takové záznamy v tabulce buffer (odchozí SOAP požadavek) je nastavena vazba na dˇríve vytvoˇrený záznam v tabulce conversation. Zárovenˇ jsou tyto nové záznamy uloženy též do fronty soap_queue, tentokrát již bez jakékoliv vazby na dˇríve uložená data. Uložení do této v rˇ adˇe již poslední fronty pˇri odesílání objednávek operátorovi znamená fiktivní odeslání objednávky k operátorovi. • Ve chvíli, kdy k takovému fiktivnímu odeslání dochází, je odeslána stavová hláška, viz. 3.11.1. Znovu musíme odkázat na 3.3.2. Pokud je dávka bin/handle_request_queue.pl spuštˇena naneˇcisto, tj. tak, že ten, kdo ji spouští chce podle výstupu˚ prubˇ ˚ ežnˇe vypisovaných na terminál zjistit, zda se chová oˇcekávaným zpusobem, ˚ aniž by skuteˇcnˇe došlo ke komunikaci at’ už se systémy operátoru˚ (viz. 3.8.2) nebo OmniTrackerem (byl odeslán e-mail, viz. 3.11.1), pak v samém závˇeru svého bˇehu vezme zpˇet všechny zmˇeny, které ve svém prubˇ ˚ ehu provedla v databázi, rollback. Po skonˇcení tedy bude fronta request_queue ve stejném stavu jako pˇred spuštˇením a záznamy ve všech dalších zmínˇených tabulkách nebudou existovat, zejména v tabulce soap_queue viz. 3.8.2. 3.8.2 Skuteˇcné odeslání Podobnˇe jako v 3.4.2 je na tabulku soap_queue navˇešen trigger, který s každým novým záznamem v této tabulce pˇridá zprávu do fronty vytvoˇrené prostˇredky balíku dbms_pipe, viz. 3.3.3, oznaˇcme ji jako interní. Na takovou zprávu cˇ eká daemon daemon/dsl_soap.pl. Pokud zjistí novou zprávu v interní frontˇe, snaží se cˇ íst nezpracované záznamy v tabulce soap_queue, SOAP požadavky, a ty odeslat pˇríslušném operátorovi. Tento akt je teprve skuteˇcným odesláním.

41

3. N ÁVRH

A IMPLEMENTACE

Když je dávka bin/handle_request_queue.pl, která – jak víme – do tabulky soap_queue vkládá, spuštˇena naneˇcisto, pak rollback provedený v jejím závˇeru zpu˚ sobí, že daemon nebude mít co odeslat. Pro nˇej totiž nejsou novˇe vložené, ale operací commit nepotvrzené záznamy viditelné. Objednávka je operátorovi pˇredána metodou POST protokolu HTTP, v tˇele dotazu je dˇríve vygenerovaná SOAP obálka. To se rovná volání webové služby. HTTP požadavku samozˇrejmˇe následuje HTTP odpovˇed’. Když pˇrijímá systém operátora SOAP požadavek, ihned kontroluje, zda XML v nˇem obsažené je dobˇre utvoˇrené, a toto ještˇe zvaliduje podle pˇríslušné DTD. Nakonec porovná cˇ asový údaj v XML uvedený (elementy SendDate a SendTime), ten se nesmí od skuteˇcného cˇ asu lišit o více než dvˇe hodiny. Pokud pˇredchozí kontroly nebyly úspˇešné, vrátí v odpovˇedi rˇ etezec ERROR. Potom daemon postupuje jako u výše popsaných chyb. Webová služba operátora vrací OK, když objednávka splnuje ˇ zadané podmínky.

3.9 Fronta objednávek cˇ ekajících na dostupné DSL Pokud pˇri zpracování požadavku check dslam ve frontˇe request_queue podle 3.8.1 dostaneme odpovˇed’, která znamená, že DSL bude dostupné na vybraném cˇ ísle v budoucnosti, jsou vytvoˇreny záznamy ve frontˇe dslam_queue. Ta vypadá takto: • request_queue_id Vazba na záznam ve frontˇe request_queue, která dovolí dohledat pˇríslušný záznam v tabulce service a tedy i zakaznik. • status Stav záznamu ve frontˇe cˇ ísel cˇ ekajících na dostupnost DSL. Pˇri vložení má hodnotu Q (dosud nezpracováno). • dslam_date Datum, od kterého bude podle tvrzení operátora na cˇ ísle dostupné DSL. Tuto frontu obsluhuje skript bin/handle_dslam_queue.pl. Je spouštˇen systémovým daemonem cron pravidelnˇe v intervalu dní. Pˇri prvním zpracování nastaví status na W (ˇcekající). Dojde-li ke zmˇenˇe dostupnosti DSL, promítne ji do pˇríslušného záznamu ve frontˇe. Je-li k urˇcenému datu DSL bud’ dostupné nebo nedostupné, pošle skript do OmniTrackeru odpovídající stavovou hlášku. Zárovenˇ nastaví status na S (DSL je nakonec dostupné) nebo U (DSL není dostupné) a podle stejného pˇredpisu zmˇení i atribut status záznamu tabulky request_queue, na který se odkazuje vazba request_queue_id.

3.10 Pˇríjem notifikací o prubˇ ˚ ehu objednávky BlackBox pˇrijímá notifikace na operátorum ˚ odeslané objednávky, které podle 3.1.2 dorucˇ ují oba operátoˇri ruznˇ ˚ e. Notifikace Telenor Networks pˇricházejí ve formˇe e-mailu˚ do mailboxu tn2bb na poštovní stroj. Stejnˇe jako v ostatních pˇrípadech dˇríve uvedených jsou z nˇej odebírány programem fetchmail a ukládány tentokrát MDA bin/save_tn_notif.pl opˇet do tabulky buffer. 42

3. N ÁVRH

A IMPLEMENTACE

ˇ Ceský Telecom doruˇcuje notifikace dotazem na webovou službu, jejíž provozování od providera oˇcekává. Webovou službu realizuje skript www/soap/ctc_notify.mpl, pˇríchozí notifikace ukládá dle pˇredpokladu do tabulky buffer. ˇ Notifikace od Ceského Telecomu a Telenor Networks z tabulky buffer cˇ tou a zpracovávají po rˇ adˇe skripty bin/process_ctc_notif.pl a bin/process_tn_notif.pl. 3.10.1 Vzorová notifikace Notifikace mají stejnˇe jako objednávky podobu XML dokumentu. Výpis 3.5 uvádí na XML s práznými elementy jejich pˇrehled. Výpis 3.5: Obecná struktura notifikace od operátora <WsAdslEmail> <Status/> <SalesChannel/> <ServiceNumber/> <Error/> Význam elementu˚ je následující: • Customer Jméno a pˇríjmení plátce linky, na níž je zˇrizováno DSL, BlackBox jej nevyužívá. • Operation Druh objednávky, která byla odeslána operátorovi a o jejímž prubˇ ˚ ehu informuje notifikace. Výjimkou je objednávka typu RESUME, k ní pˇríchozí notifikace mají v tomto elementu uvedenu hodnotu ORDER nebo CHANGE podle toho, jaký druh objednávky oživuje objednávka RESUME. • AdslPhoneNumber, AdslService V tˇechto elementech jsou zopakovány po rˇ adˇe telefonní cˇ íslo, na kterém je zˇrizováno (resp. na kterém jsou mˇenˇeny parametry) DSL, a kód tarifu operátora. • Status ˇ Císelná identifikace stavu, ve kterém se objednávka u operátora nachází. Významy stavu˚ jsou podrobnˇe popsány v dokumentaci operátoru˚ [2] a [3], zevrubnˇe jsou podány 3.4 spolu s mapováním na stavové hlášky jdoucí do OmniTrackeru. 43

3. N ÁVRH

A IMPLEMENTACE

• SalesChannel Obsah elementu SalesChannel v objednávce. Je použit pro navázání záznamu v tabulce conversation, který obsahuje XML notifikace, k záznamu v tabulce operation. • ServiceNumber ˇ ezec, který identifikuje u operátora zprovoznˇené DSL (samozˇrejmˇe jen tehdy, Retˇ když bylo úspˇešnˇe zˇrízeno). Tento rˇ etezec je potˇrebný pˇri zadávání objednávek typu CHANGE a CEASE. Po celou dobu od pˇríchodu první notifikace k objednávce ORDER, pˇres nˇekolik možných zmˇen objednávkami CHANGE, až do poslední notifikace k objednávce CEASE, se nemˇení. • OrderNumber ˇ ezec identifikující u operátora k nˇemu odeslanou objednávku. Retˇ • AddressPool, AddressArea ˇ Konfiguraˇcní údaje Ceského Telecomu. • InterconnectPoint, VPI, VCI Konfiguraˇcní údaje Telenor Networks. • Error, CustMessage ˇ V elementu Error udává Ceský Telecom duvod, ˚ proˇc byla objednávka odmítnuta, viz. 1.3. V elementu CustMessage uvádˇejí oba operátoˇri duvod ˚ záporného technického šetˇrení, Telenor Networks rovnˇež duvod ˚ odmítnutí objednávky. 3.10.2 Mapování stavu˚ notifikací na stavové hlášky Stavové diagramy, které popisují vývoj objednávky u operátora, se u obou operátoru˚ velmi podobají. Pˇresto jsou ve svém významu i posloupnosti nˇekterých stavu˚ ruzné. ˚ Podobnˇe jako v 3.5.1 musíme nalézt to, co mají spoleˇcného. V každém stavu, kterého objednávka u operátora dosáhne, odesílá tento notifikaci. BlackBox posílá stavové hlášky jen ve vybraných stavech notifikace. Na obrázcích 3.3 a 3.4 jsou znázornˇeny stavové diagramy objednávky ORDER. V tabulce 3.4 jsou ve sloupcích postupnˇe uvedeny uvedeny stavy notifikací pˇricházejících ˇ z Ceského Telcomu a Telenor Networks, jejich význam a pˇrípadnˇe i obsah stavové hlášky, která je v tomto stavu odesílána do OmniTrackeru, a hodnota, na kterou je zmˇenˇen atribut status záznamu v tabulce operation, jehož id se shoduje s obsahem elementu SalesChannel v notifikaci. Stavové hlášky mají podobu e-mailu. ˚ V jejich tˇele jsou obsaženy tyto údaje: • Identifikátor objednávky DSL služby v OmniTrackeru (hodnota zakaznik_req v tabulce service). • Telefonní cˇ íslo, na kterém je v rámci objednávky zˇrizováno, mˇenˇeno nebo rušeno DSL pˇripojení. Slouží pro vizuální kontrolu v OmniTrackeru. • Text, který popisuje význam stavové hlášky. 44

3. N ÁVRH

A IMPLEMENTACE

ˇ Obrázek 3.3: Stavový diagram objednávky ORDER k operátorovi Ceský Telecom. • V pˇrípadˇe, že stavová hláška vyjadˇruje nˇekterý z možných problému˚ (odmítnutí, záporný výsledek technického šetˇrení), pak je tento uveden (pˇrepis obsahu elementu Error nebo CustMessage, viz. 3.10.1). • Oznamuje-li notifikace ukonˇcení konfigurace pˇripojení u operátora, jsou uvedeny jím poskytnuté konfiguraˇcní údaje, viz. stavy 12 v notifikacích obou operátoru˚ v tabulce 3.4. Stavové diagramy, které operátoˇri uvádˇejí v [2] a [3], se ukázaly být jen ideálním prubˇ ˚ ehem stavu˚ pˇri rˇ ešení objednávky DSL pˇripojení na stranˇe operátora. V praxi cˇ asto operátoˇri nedodržují ve stavových diagramech stanovené posloupnosti stavu. ˚ V pˇrípadˇe Telenor Networks je to zpusobeno ˚ mj. samotným zpusobem ˚ pˇredávání notifikací: e-mailová komunikace neposkytuje prostˇredky, které by zaruˇcily, že poˇradí notifikací odeslaných operátorem bude dodrženo i pˇri jejich pˇrijetí na stranˇe providera. ˇ Casto ale systémy operátoru˚ udˇelají chybu, a doruˇcí takovou notifikaci, jejíž stav podle stavového diagramu neodpovídá stavu notifikace naposledy providerem pˇrijaté. ˇ Objednávky DSL pˇripojení u Ceského Telecomu odesílá doˇcasnˇe interní objednávkový systém, viz. 2.3, který nepoužívá element SalesChannel v XML objednávky. Proto není možné, aby skript bin/process_ctc_notif.pl pároval nový záznam v tabulce conversation, který vznikne z pˇríchozí notifikace, na základˇe hodnoty tohoto elementu, jak jsme uvedli v 3.10.2. Podle stavu notifikace budeme hledat záznam v tabulce operation, který má nastaven status na R (bežící objednávka). Ten musí být zárovenˇ svázán pomocí atributu service_id se záznamem v tabulce service, který se pojí s objednávkou DSL služby na telefonním cˇ ísle uvedeném v notifikaci. Nenajdeme-li v tabulce operation takový záznam, jde o první notifikaci k objednávce, jejíž cílem je zˇrízení, zmˇena nebo zrušení DSL pˇripojení na telefonním cˇ ísle obsaženém v notifikaci. To, zda stav pˇríchozí notifikace zapadá s ohledem na stave notifikace jí pˇredcházející do stavového diagramu, nekontroluje kód skriptu˚ sám. Stavová diagram lze totiž snadno reprezentovat tabulkou, v našem pˇrípadˇe status_diagram. Ta obsahuje identifikátor 45

3. N ÁVRH

ˇ CTc 1

TN

2

2

4

4

10

8

7

8

7

3 12

3 12

6

6

A IMPLEMENTACE

popis V tomto stavu posíláme do OmniTrackeru hlášku, která znamená ˇ operátor pˇrijal objednávku, ale jen v pˇrípadˇe Ceského Telecomu. Ten bud’ objednávku pˇrijme (1) nebo odmítne (2), zatímco Telenor Networks ji muže ˚ pˇrijmout a hned vzápˇetí odmítnout. Stavová hláška operátor objednávku odmítl. Pˇrípad špatné kombinace telefonního a referenˇcního cˇ ísla. Záporný výsledek technického šetˇrení znamená, že není možné z ruzných ˚ duvod ˚ u˚ DSL zˇrídit. Popis duvodu ˚ je souˇcástí notifikace. Posíláme rovnˇež záporný výsledek technického šetˇrení, pˇrestože stav 10 znamená fakticky jen zdržení pˇri nˇem, chceme v OmniTrackeru ale evidovat veškeré možné duvody ˚ pˇrípadného neúspˇechu. Stav u operátora znamená, že je tˇreba zásahu ze strany zákazníka, aby mohla objednávka pokraˇcovat, typicky pˇrípad nutné zmˇeny ISDN rozhraní na typ U. U operátora je objednávka odložena, do bˇehu ji muže ˚ uvést objednávka RESUME od providera. Odchází hláška záporný výsledek technického šetˇrení. Provider vˇcas (do 30 dnu˚ od notifikace se stavem 8) neposlal objednávku RESUME, objednávka byla ukonˇcena. Stavová hláška kladný výsledek technického šetˇrení. V notifikaci pˇricházejí konfiguraˇcní údaje, se kterými pracuje technické oddˇelení, a které jsou souˇcástí stavové hlášky dokonˇcena konfigurace. Objednávka byla úspˇešnˇe dokonˇcena, DSL bylo zˇrízeno, zmˇenˇeno nebo zrušeno, odchází stavová hláška zrealizováno.

O

R U U

R

W U R R S

Tabulka 3.4: Význam stavových hlášek a stavy, ze kterých pocházejí.

46

3. N ÁVRH

A IMPLEMENTACE

Obrázek 3.4: Stavový diagram objednávky ORDER k operátorovi Telenor Networks. operátora, stav naposledy pˇrijaté notifikace a stav notifikace právˇe zpracovávané. Poˇcáteˇcní stavy nemají zˇrejmˇe vyplnˇen atribut popisující stav naposledy pˇrijaté notifikace. Stejnˇe tak lze podle údaju˚ v tabulce rozhodovat, zda bude tˇreba, podle stavu aktuální notifikace, odeslat stavovou hlášku do OmniTrackeru, a jakou. V takové tabulce je opˇet tˇreba identifikátor operátora, dále stav právˇe zpracovávané notifikace a druh stavové hlášky, který má být odeslána do OmniTrackeru. V BlackBoxu se tabulka jmenuje ot_status_mail. Jako poslední uvedeme tabulku conversation_status. Podle té se skripty bin/ process_tn_notif.pl a bin/process_ctc_notif.pl rozhodují, jakou hodnotu nastavit atributu status záznamu v tabulce operation, ke kterému byla jimi pˇriˇrazena novˇe zpracovávaná notifikace, viz. sloupec O v tabulce 3.4.

3.11 Upozornování ˇ na dlouho bˇežící objednávky u operátora SkyNet slibuje zákazníkum ˚ vyˇrešit objednávku DSL služby do 21 dní ode dne, kdy je podle pˇríslušného operátora na vybraném telefonním cˇ ísle dostupné DSL, viz. 3.5. Nejvˇetší cˇ ást této lhuty ˚ vyplnuje ˇ vyˇrizování zˇrízení cˇ i zmˇeny DSL pˇripojení, viz. 3.8 a 3.10. Stává se, že operátoˇri v prubˇ ˚ ehu svých interních procesu˚ zapomenou na nˇekterou objednávku od providera. To se projevuje tím, že k nˇejaké objednávce již delší dobu (víc jak pˇet dní) nepˇrišla notifikace. Takovou objednávku chceme najít a poslat o ní stavovou hlášku operátor dlouho neposlal notifikaci k objednávce do OmniTrackeru. Ta je signálem pro Customer Care, aby kontaktovalo operátora a zjistilo, co je duvodem ˚ prodlevy. Skript bin/check_notif_timeout.pl pravidelnˇe zjišt’uje, které bˇežící objednávky (atribut status v tabulce operation má hodnotu R) vykazují tyto pˇríznaky. To zjistí tak, že k záznamu v tabulce operation, který splnuje ˇ výše uvedené podmínky, nalezne pˇríslušný záznam v tabulce conversation (podle vazby operation_id, viz. 3.6.3) ta47

3. N ÁVRH

A IMPLEMENTACE

kový, který reprezentuje poslední notifikaci pˇrijatou k odeslané objednávce (podle vazby last_converation_id, viz. 3.6.2). Zvlášní pˇrípad je ten, kdy nebyla k odeslané objednávce pˇrijata dosud žádná notifikace. Pak stavová hláška do OmniTrackeru vyjadˇruje, že operátor objednávku vubec ˚ nepˇrijal. 3.11.1 Odesílání stavových hlášek Na nˇekolika místech (3.8, 3.9, 3.10.2, 3.11) jsme zmínili, že BlackBox v jistých situacích odesílá stavové hlášky do OmniTrackeru. Tˇemi ho informuje o tom, jaká situace nastala pˇri rˇ ešení požadavku na odeslání objednávky DSL pˇripojení operátorovi, který on inicioval. Zopakujme, které situace to jsou: • Pˇri kontrole dostupnosti DSL na vybraném cˇ ísle, viz. 3.7, v pˇrípadˇe, že DSL není dostupné ihned, anebo vubec. ˚ • Pˇri odeslání objednávky operátorovi, at’ už na zˇrízení, zmˇenu nebo zˇrízení DSL pˇripojení. • V nˇekterých stavech notifikací pˇri jejich zpracování. • V okamžiku, kdy BlackBox zjistí, že k bˇežící objednávce DSL pˇripojení dlouho nepˇrišla notifikace. Protože stavové hlášky spouští v OmniTrackeru vykonávání definovaných operací, jsou tyto odesílány jen tehdy, je-li dávka, která rˇ eší výše uvedené situace, spuštˇena v ostrém provozu, viz. 3.3.2. Podobnˇe je rˇ ešeno i odesílání objednávek operátorovi, viz. 3.8.2, protože i ty iniciují nˇejaké procesy, tentokrát na stranˇe operátora. Stavové hlášky, které je tˇreba odeslat, uloží nedˇríve dávka do tabulky buffer. V záznamu, který reprezentuje stavovou hlášku, bude type nastaven na status mail to ot. V závˇeru bˇehu dávky jsou takové záznamy zkopírovány do tabulky mail_queue. Tento akt reprezentuje je obdobný 3.8.1. Byla-li dávka spuštˇena v ostrém provozu, tak, jak už víme, potvrdí zmˇeny provedené v databázi. Na tabulce mail_queue je definován trigger, který je spouštˇen pokaždé, je-li do ní vložen nový záznam. V tom okamžiku vloží zprávu do fronty dsl_mail vytvoˇrené funkcemi baíku dbms_pipe, viz. 3.3.3. Obsah fronty dsl_mail soustavnˇe kontroluje daemon daemon/dsl_mail.pl (podobnˇe jako v 3.4.2 a 3.8.2). Ten pošle e-mail pomocí programu sendmail.

48

Kapitola 4

Závˇer Systém pracuje v produkˇcním nasazení (v 2.3 pˇredpokládaná varianta odesílání objednávek jen operátorovi Telenor Networks) od podzimu roku 2004. Tato práce popisuje stav, ve kterém se systém nacházel na konci bˇrezna roku 2005. Od té doby staˇcilo dojít ke zmˇenám, které jinak chápou a evidují zmˇeny již existujících a bˇežících DSL služeb. Systém se ukázal být snadno pˇrizpusobitelný ˚ zmˇenám v jednotlivých fázích objednávání DSL pˇripojení: jiné pojetí DSL služeb a jejich zmˇen v OmniTrackeru znamenají pouze zmˇenu kódu, který plánuje, které objednávky odešle operátorovi, konkrétnˇe bin/process_ot_request.pl. Zmˇení-li se zpusob ˚ odesílání objednávek k operátorum, ˚ bude tˇreba zmˇenit jen ten skript, který obsluhuje tuto cˇ ást procesu, tj. bin/handle_request_queue.pl. Nakonec, v pˇrípadˇe, že operátoˇri zmˇení dosavadní zpusob ˚ doruˇcování notifikací, budou upraveny jen ty skripy, které je zpracovávají a vˇclenují ˇ do struktur, které komunikaci providera a operátora evidují. Bylo vykoušeno, že celý proces, kterým prochází požadavek na odeslání objednávky ˇ operátorovi vycházející z OmniTrackeru, funguje i pˇri oboustrané komunikaci s Ceským Telecomem, zejména tedy odesílání objednávek. Do konce kvˇetna 2005 je plánováno pˇrejít plnˇe z doˇcasné koexistence BlackBoxu a interního objednávkového systému plnˇe na provoz skrze BlackBox.

49

Literatura [1] Salus, Peter H. A Quarter-Century of Unix., Adison-Wesley, 1994, ISBN-0-201-54777-5. ˇ [2] Ceský Telecom, a. s., Využití aplikace ADSL Service Provisioning z aplikace ISP, verze 3.0, 2005, dokumentace rozhraní objednávkového systému pro providery. [3] Telenor Networks, s. r. o., Praha, XML ISP Self Provisioning System, verze 1.12, 2005, dokumentace rozhraní objednávkového systému pro providery. [4] Wall, Larry, Christiansen, Tom, Orwant, Jon, Programming Perl, O’Reilly, 2000, ISBN0-596-00027-8. [5] Bunce, Tim, aj., DBI – Database independent interface for Perl, version 1.48, dokumentace modulu DBI jazyka Perl, dokument je dostupný na URL http://search.cpan. org/~timb/DBI-1.48/DBI.pm (kvˇeten 2005). [6] Skoll, David F., MIME::Entity – class for parsed-and-decoded MIME message, dokumentace modulu MIME::Entity jazyka Perl, dokument je dostupný na URL http://search.cpan.org/~dskoll/MIME-tools-5.417/lib/MIME/ Entity.pm (kvˇeten 2005). [7] Skoll, David F., MIME::Parser - experimental class for parsing MIME streams, dokumentace modulu MIME::Parser jazyka Perl, dokument je dostupný na URL http://search.cpan.org/~dskoll/MIME-tools-5.417/lib/MIME/ Parser.pm (kvˇeten 2005). [8] Kulchenko, Paul, Reese, Byrne, SOAP::Lite - Client and server side SOAP implementation, dokumentace modulu SOAP::Lite jazyka Perl, dokument je dostupný na URL http://search.cpan.org/~byrne/SOAP-Lite-0.60a/lib/SOAP/ Lite.pm (kvˇeten 2005). [9] PL/SQL Packages and Types Reference: DBMS_PIPE, dokument dostupný na URL http://download-west.oracle.com/docs/cd/B14117_01/appdev. 101/b10802/d_pipe.htm (kvˇeten 2005)

50

Pˇrílohy Datový model Na níže uvedeném obrázku je zobrazen datový model BlackBoxu. Po nˇem následuje popis významu jednotlivých tabulek, pˇriˇcemž u každé uvedeme její duležité ˚ atributy.

• operator, tarif, modem, instalace, modem_sluzba ˇ Císelníky po rˇ adˇe operátoru, ˚ tarifu, ˚ modemu, ˚ typu˚ instalací a služeb nad modemem. Všechny mají primární klíˇc (dále jen PK) request a atribut popis. Tabulky 51

ˇ P RÍLOHY

operator a tarif mají atribut kod, který se podle 3.8 uvádí v elementech po rˇ adˇe AdslService a AdslModem v XML objednávky DSL pˇripojení. Tabulka tarif má atributy zrizovaci a cena, ve kterých jsou uvádˇeny po rˇ adˇe zˇrizovací a paušální poplatek tarifu. Tabulka modem má atributy koupe a pronajem, ve kterých jsou uvádˇeny po rˇ adˇe cena DSL modemu pˇri jeho koupi v rámci DSL služby a cena jeho pronájmu. Tabulka instalace obsahuje atribut cena, ve kterém je uvádˇena cena instalace DSL modemu v rámci DSL služby. Podle tˇech atributu, ˚ které v cˇ íselnících vyjadˇrují cenu (at’ už služby, nebo zboží), poˇcítá zákaznická aplikace výslednou cenu DSL služby. Všechny tabulky mají atribut platne_do, ve kterém je uvedeno datum konce platnosti položky v pˇríslušné tabulce, viz. 3.4.2. • sluzba ˇ Císelník definic DSL služeb. Má atribut request (PK) a atributy _req (cizí klíˇce, dále FK), kde je název tabulky výše uvedených cˇ íselníku, ˚ které se odkazují na atribut request odkazované tabulky. Poslední je atribut platne_do, jehož význam je stejný jako u výše uvedených cˇ íselníku. ˚ • stav ˇ Císelník stavu˚ objednávky DSL služby v OmniTrackeru, resp. cˇ íselník stavových hlášek, které BlackBox do OmniTrackeru odesílá. Obsahuje atributy request (PK) a popis. • zakaznik Kopie údaju, ˚ které OmniTracker uchovává u objednávky DSL služby, a které jsou duležité ˚ pˇri tvorbˇe XML objednávky DSL pˇripojení, viz. 3.8. Významné atributy jsou: request (PK, identifikace objednávky DSL služby v OmniTrackeru), sluzba_ req (FK, odkaz do cˇ íselníku sluzba), dvojice cli a ref_cislo (telefonní cˇ íslo, na kterém má být DSL pˇripojení zˇrízeno, zmˇenˇeno, nebo zrušeno, a k nˇemu odpovídající referenˇcní cˇ íslo). • service, operation, conversation Tabulky byly popsány postupnˇe v 3.6.1, 3.6.2 a 3.6.3. • operation_type ˇ Císelník pˇrípustných hodnot atributu type tabulky operation s jediným atributem type (PK). Pˇrípustné hodnoty jsou: order, change a cease. • conversation_type ˇ Císelník pˇrípustných hodnot atributu type tabulky conversation. Má jediný atribut type (PK). Pˇrípustné hodnoty jsou order (objednávka odeslaná operátorovi), notification (notifikace pˇrijatá k objednávce k operátorovi) a result (výsledek volání funkce systému operátora na zjišt’ování dostupnosti DSL pˇripojení na vybraném cˇ ísle). • conversation_status Tabulka, podle níž se urˇcuje hodnota atributu status tabulky operation. Atributy: operator_req (FK do tabulky operator), operation_type (FK do stej52

ˇ P RÍLOHY

nojmenné tabulky), status (hodnota elementu Status v notifikaci) a operation_ status. Zmínˇené atributy tvoˇrí složený PK. • ot_status_mail Tabulka, podle níž se rozhoduje, jestli bude na základˇe notifikace odeslána stavová hláška do OmniTrackeru, a jaká. Atributy: operator_req (FK do tabulky operator), stav_req (FK do tabulky stav) a status (hodnota elementu Status v notifikaci). Zmínˇené atributy tvoˇrí složený PK. • request_queue Tabulka byla popsána v 3.7. • request_queue_task ˇ Císelník hodnot, kterých muže ˚ nabývat atribut task tabulky request_queue, s jediným atributem task (PK). Pˇrípustné hodnoty: check dslam, send order, send change, send resume a send cease. • request_queue_status ˇ Císelník hodnot, kterých muže ˚ nabývat atribut status tabulky request_queue. Má dva atributy, které spolu tvoˇrí PK: task (FK, odkazuje atribut task v tabulce request_queue_task), status (hodnota, jíž muže ˚ nabývat atribut status v tabulce request_queue). • dslam_queue Tabulka byla popsána v 3.9. • buffer Tabulka, do které je smˇerˇ ována veškerá pˇríchozí (e-maily s požadavky na odeslání objednávky oprátorovi, notifikace obou operátoru) ˚ i odchozí (SOAP požadavky k odeslání operátorovi, e-maily se stavovými hláškami do OmniTrackeru) komunikace. Atributy: id (PK), type a status (složený FK do tabulky buffer_status) a data. • buffer_type ˇ Císelník pˇrípustných hodnot atributu type v tabulce buffer a zárovenˇ buffer_ status. Obsahuje jediný atribut type (PK). Pˇríklad: mail request from ot (požadavek na odeslání objednávky operátorovi), mail notif from tn (notifikace od Telenor Networks), soap order to ctc (objednávka DSL pˇripojení ˇ smˇerˇ ovaná do Ceského Telecomu). • buffer_status ˇ Císelník pˇrípustných hodnot atributu status tabulky buffer s atributy type (FK do tabulky buffer_type) a status, které tvoˇrí složený PK. Kombinace hodnot atributu˚ po rˇ adˇe, jak jsme je uvedli, jsou napˇr. mail request from ot a passed to request queue (požadavek na odeslání objednávky operátorovi byl rozpoznán a do tabulky request_queue byl pˇridán odpovídající záznam, viz. 3.7). • update_queue, soap_queue, mail_queue Tabulky byly po rˇ adˇe popsány v 3.4.2, 3.8.2 a 3.11.1. 53

ˇ P RÍLOHY

Obsah pˇriloženého CD bin/save_ot_request.pl bin/save_tn_notif.pl bin/handle_request_queue.pl bin/handle_dslam_queue.pl bin/process_tn_notif.pl bin/process_ctc_notif.pl bin/process_ot_request.pl bin/dslam_cache_dispatch.pl bin/freshen_queue.pl bin/check_notif_timeout.pl bin/cache/stav.pl bin/cache/operator.pl bin/cache/tarif.pl bin/cache/modem.pl bin/cache/sluzba.pl bin/cache/instalace.pl bin/cache/modem_sluzba.pl bin/cache/promo.mpl daemon/dsl_update.pl daemon/dsl_mail.pl daemon/dsl_soap.pl perllib/ADSL/Input.pm perllib/ADSL/SkyWS.pm perllib/ADSL/DSLAM.pm perllib/ADSL/Const.pm perllib/ADSL/Cache.pm perllib/ADSL/DBI.pm perllib/ADSL/Mail.pm perllib/ADSL/CheckDSLAM.pm perllib/ADSL/SOAP.pm perllib/ADSL/XML.pm perllib/ADSL/FindInXML.pm www/soap/ctc_notify.dsd www/soap/ctc_notify.mpl www/admin/zakaznik.dsd www/admin/index.mpl www/admin/index.dsd www/admin/index.xsl www/admin/zakaznik.xsl www/admin/zakaznik.mpl www/services/check_dslam.mpl www/services/operator.mpl

54

ˇ P RÍLOHY

www/services/instalace.dsd www/services/instalace.mpl www/services/modem.dsd www/services/modem.mpl www/services/modem_sluzba.dsd www/services/modem_sluzba.mpl www/services/operator.dsd www/services/sluzba.dsd www/services/sluzba.mpl www/services/tarif.dsd www/services/tarif.mpl www/services/check_dslam.dsd www/services/dslam_message.mpl www/services/dslam_message.dsd www/services/promo.dsd www/services/promo.mpl

55