BACHELOR'S THESIS. Python Scripting for Network Management PyMIP - TeMIP made simple. Mats Andersson Robert Wedin. Luleå University of Technology

Transkript

1 BACHELOR'S THESIS 2006:043 HIP Python Scripting for Network Management PyMIP - TeMIP made simple Mats Andersson Robert Wedin Luleå University of Technology BSc Programmes in Engineering Computer Engineering Department of Skellefteå Campus Division of Mobile Networking and Computing 2006:043 HIP - ISSN: ISRN: LTU-HIP-EX--06/043--SE

2 Python scripting for network management PyMIP - Visual TeMIP made simple Mats Andersson Robert Wedin 31 oktober 2006

3 Förord Syfte med rapporten Syftet med denna rapport är att ge en beskrivning av det examensarbete vi har utfört åt Data Ductus. Den är även tänkt att ge utförlig information om vad PyMIP är, hur det fungerar samt hur det kan användas. Erkännanden Under tiden med examensarbetet har vi fått stöd och hjälp av många människor vilka vi vill tacka här: Alla på Data Ductus För den hjälp, det stöd och det kamratskap de har gett oss. De har verkligen fått oss att trivas under den här tiden. Urban Lundmark För att han gav oss chansen att göra examensarbetet här på Data Ductus. Ulrik Forsgren, Tord Andersson, Stefan Wallin och André Jonsson programmeringshjälp, de synpunkter och alla tips vi fått. För den Staffan Nilsson Examinator på LTU. Edward Domeij och Fredrik Ahlbäck Som alltid fanns till hands och hjälpte till med designfrågor, smarta lösningar och allmänt stöd. Utan alla er hade PyMIP aldrig varit möjligt! 1

4 Abstract This project was performed by the authors during 10 weeks in the spring of The primary goal was to produce a python-library as an interface for Visual TeMIP. Visual TeMIP is a C++-API used to develop applications and modules for interfacing with the alarmhandlingsystem, OpenView TeMIP. A secondary goal was to produce a light-weight webserver and webclient to be used by customers that has no need for the full-blown TeMIP-client. The webserver was written entirely in Python, using the PyMIP-library, and the webclient was written in DHTML, using AJAX. An ASCII-based alarmlist written in Python was also made for use by developers and technicians, and to test the functionality of the PyMIP-library. The main purpose of PyMIP is to decrease the time it takes to develop new applications and modules for TeMIP. Since Python is a fast and reliable scripting-language, it has no compilation-time. Also, it s simplicity and straight-forwardness when it comes to wrapping C++-classes makes it a natural choice for this kind of project. 2

5 Sammanfattning Det huvudsakliga målet var att skapa ett python-bibliotek som fungerar som ett interface till Visual TeMIP. Visual TeMIP är ett C++-API som används till att utveckla applikationer och moduler för alarmhanteringssystemet OpenView TeMIP. Ett sekundärt mål var att skapa en lättvikts-webbserver och en webbklient för de mindre kunder som inte har behov av den fullfjädrade TeMIP-klienten. Webbservern skrevs helt i Python och använde sig av PyMIPbiblioteket, webbklienten skrev i DHTML och AJAX. En ASCII-baserad larmlista skriven i Python gjordes också för att användas av utvecklare och tekniker, samt för att testa funktionaliteten i PyMIP. Huvudsyftet med PyMIP var att minska ned på utvecklingstiderna när man skapar applikationer och moduler för TeMIP. Eftersom Python är ett snabbt och tillförlitligt skriptspråk så har det ingen kompileringstid. Dessutom gör dess enkelhet och rättframhet när det gäller att wrappa C++-klasser den till ett naturligt val för denna typ av projekt. 3

6 Förklaringar och begrepp Vissa ord och uttryck som används i rapporten upprepade gånger förklaras ytterligare här. wrappa - Att kapsla in ett objekt så man kan ge det ett nytt interface, till exempel mellan olika språk. IDE - Integerated Development Enviroment. wxwidgets - Windows and X widgets är en open-source, plattformsoberoende verktyg för att skapa grafiska applikationer. Python-tolk - Ett program som tolkar python-kod och exekverar den. Makefil - En fil som beskriver för en kompilator hur ett objekt ska byggas. man - Unix-kommando för att söka hjälp om funktioner och liknande. Metaprogrammering - Metaprogrammering är skrivandet av program som skriver eller manipulerar andra program (eller sig själva). TeMIP PM - Programmodul som ligger i det översta skiktet av TeMIP. OC - Ett Operation Context är en entitet i TeMIP som anger ett intresseområde av larm. TeMIP:s dictionary - En databas som används för att slå upp information om olika entiteter i TeMIP. ncurses - Ett bibliotek för att utveckla pseudo-grafiska användarinterface i konsolmiljö. AJAX - Asynchronous JavaScript And XML. Collection - En samling av ett eller flera OC:s. 4

7 Innehåll Förord 1 Syfte med rapporten Erkännanden Innehållsförteckning 5 1 Introduktion Bakgrund och syfte Genomförande Initialt arbete Python TeMIP HP-UX och kompilatorer Wrappning SWIG Boost.Python Utveckling och tester PyMIP Lib C-to-Python Textlarmlista Webblarmlista Korrigeringsfilter Resultat 15 4 Diskussion 15 5 Referenser 17 Bilagor 18 A Visual TeMIP vs. PyMIP 18 B HTML-mallar 21 C Loopaloop 22 D Uppdragsbeskrivning 25 E TeMIP 30 5

8 1 Introduktion 1.1 Bakgrund och syfte Önskemålet från Data Ductus var att skapa ett bibliotek, PyMIP, skrivet i Python, för att använda till utveckling av applikationer och moduler till TeMIP. Anledningen till valet av just Python var att det är ett snabbt och robust skriptspråk vilket helt eliminerar kompileringstider jämfört med traditionell programmering i t.ex. C++. En andra anledning var dess enkelhet när det gäller att wrappa färdiga C++-klasser till fungerande Python-klasser. Se uppdragsbeskrivningen i bilaga D. Fördelen med Python och PyMIP jämfört med Visual TeMIP är att utvecklingstiderna minskas då man slipper kompileringstider. Detta sparar både tid och pengar för företaget, mycket för att man kan sitta ute hos kunden och genomföra tester, korrigera fel i existerande kod etc utan att behöva kompilera om hela systemet. Ett enkelt exempel som visar hur C++-kod skriven för Visual TeMIP samt Python-kod skriven för PyMIP finns att se i bilaga A. Anledningen till att vi valde detta examensarbete var för att det verkade mycket intressant och utvecklande. Ingen av oss hade tidigare programmerat i Python men vi var mycket intresserade av att lära oss ett så pass robust skriptspråk. Utmaningen att kunna tillgängliggöra ett interface från en klass i ett språk, till en annan klass i ett annat språk kändes utvecklande för oss som programmerare. 6

9 2 Genomförande 2.1 Initialt arbete Python Eftersom Python var okänt territorium krävdes det till en början en del inläsning och experimenterande för att få kunskap om hur Python fungerar och alla dess fördelar. Pythons hemsida 1 användes som startpunkt för studier och förståelse av Pythonspråket. Där fanns klara beskrivningar av det medföljande standardbiblioteket, grundläggande funktionalitet samt programmeringstips. Det första vi gjorde var att ladda hem och installera Python samt prova på språket i den interaktiva kommandotolken. Vi insåg ganska snabbt att den inte dög till att utveckla något användbart i, utan att det var dags att leta efter något form av IDE. Utvecklingsmiljön som följde med pythoninstallationen för windows var i princip bara en glorifierad texteditor utan funktionaliteter som automatisk kodkomplettering och någon större möjlighet att organisera ett projekt. Vi tittade på Boa Constructor samt Wing IDE. Boa Constructor hade fått ganska dåliga recensioner och Wing föll på det faktum att det var en kommersiell produkt. Vi ville helst komma igång så snabbt som möjligt utan att vara tvungna att betala för ett IDE. Till slut hittade vi SPE 2 som var ett gratis verktyg som byggde på wxwidgets och hade funktioner som automatisk kodkomplettering och bra möjligheter för att strukturera projekt. Det blev det slutgiltiga valet och den utvecklingsmiljö som vi arbetade i när det gällde Python för resten av projektet. Python gick fort att lära sig eftersom det är mycket intuitivt och går snabbt att prova sig fram i tack vare den interaktiva Python-tolken. En av de få svårigheter som vi stötte på var att vänja sig vid att Python är typeless, dvs man deklarerar inte variabler av en viss typ, eftersom typen av variabeln bestäms vid tilldelning TeMIP För att sätta sig in i TeMIP läste vi dokumentationen för utvecklare samt dokumentationen för TeMIP klienten. Sedan var även referensguiden till Visual TeMIP till stor hjälp när det gällde att förstå hur alla klasser hängde ihop och hur hela systemet fungerade. För att sammanfatta TeMIP: TeMIP är ett system för att hantera alarm från olika typer av enheter, såsom basstationer, routrar, mobilmaster och liknande. Dessa enheter tar själva hand om att skicka larm till TeMIP när något fel har uppstått. Larmen hanteras av TeMIP systemet och kan visas för en larmoperatör med hjälp av TeMIP klienten. Operatören hanterar larmen och väljer passande åtgärder som till exempel skicka ut en tekniker för att laga felet. För mer djupgående information om TeMIP samt TeMIP klienten, se bilaga E HP-UX och kompilatorer Det operativsystem som skulle användas för att utveckla och testa PyMIP på var HP-UX. En proprietär Unix-variant som Hewlett Packard utvecklat. Det är ett stabilt operativsystem, dock med Stanis Python Editor 7

10 vissa kompatibilitets problem som var tvungna att hanteras. Anledningen till att HP-UX skulle användas var främst för att det fanns en existerande TeMIP-installation på det systemet. Under HP-UX var det acc som gällde som kompilator för att kompilera de wrappade C++klasserna till python-klasser. Att använda sig av makefiler och konsolbaserade kompilerare var något helt nytt vilket innebar en hel del huvudbry till en början. Inlärningskurvan var ganska brant då tidigare utveckling endast skett i IDE:s i Windowsmiljö. Tack vare man, hjälp från medarbetare och trial-and-error gick alla problem att lösa. 2.2 Wrappning Till en början gick det åt ett par dagar till att läsa och förstå hur man skulle gå till väga för att skriva Python klasser i C/C++. var här till stor hjälp för där fanns en beskrivning på hela C API:t samt exempel på hur strukturen av modulerna skulle se ut. Det första sättet vi testade var att följa Python-klasser-i-C exemplet som hittades på nämnda sida. Det fungerade som det skulle men kändes lite klumpigt eftersom det krävdes ganska mycket kodskrivande till och med för små klasser. Detta ledde till att vi gjorde efterforskningar för alternativa metoder. De två tillvägagångssätt som vi hittade var SWIG och Boost.Python SWIG SWIG står för Simplified Wrapper and Interface Generator. Det är ett verktyg som används för att generera wrappningskod för att t.ex. kunna komma åt ett C++ interface från andra språk som t.ex. Python, Perl, Ruby etc. Men det stödjer även språk som inte är skriptbaserade som t.ex. C#. Tanken med det hela är att man ska kunna ta redan utvecklade kodbibliotek och göra dem tillgängliga i t.ex. ett skriptspråk för att få snabbare utveckling med hjälp av minskade kompileringstider. Det verkade som att det passade perfekt för detta projekt. Till en början såg det ut som att det nästan skulle göra allt jobb eftersom det enda som behövdes för att ställa in SWIG var ett form av mallskript som beskrev hur den skulle generera kod för det skriptspråk man valt. Detta testades på HP-UX och det tog oss inte särskilt lång tid att förstå hur det hela fungerade. SWIG generade utifrån mallskriptet ett C++ bibliotek och en ren Pythonklass som använde sig av C++ biblioteket. Detta gav att man fick använda den C++ klass / bibliotek man valt att wrappa på samma sätt i Python som man skulle gjort i C++, med vissa språkliga skillnader givetvis. Det såg till en början riktigt bra ut och testades med ett par testklasser som skrevs i C++. Eftersom det fungerade som det borde gjordes vidare tester med Visual TeMIP klasser. Här var resultaten inte lika goda eftersom att det inte fanns stöd i SWIG för att hantera arv och mallar. Det blev även problem med att importera pythonklasserna ifall C++ klassen man valt att wrappa använde sig av vissa standardbibliotek. För att inte spilla allt för mycket tid på detta letade vi efter en alternativ metod för att underlätta wrappningen Boost.Python Efter lite mer letande på nätet och läsande av recensioner insåg vi att alla tecken pekade mot Boost.Python. Boost är ett open source C++ bibliotek som innehåller olika moduler som ökar C++:s funktionalitet, t ex färdiga bibliotek för datumhantering, Regex m.m. Här fanns även en 8

11 modul som hanterade wrappning av C++ klasser till Python på ett smidigt sätt genom metaprogrammering. Se följande exempel: En vanlig C++-funktion som denna: 1 char const g r e e t ( unsigned x ) 2 { 3 s t a t i c char const const msgs [ ] = { h e l l o, 4 Boost. Python, 5 world! } ; 6 7 i f ( x > 2) 8 throw std : : r a n g e e r r o r ( g r e e t : index out of range ) ; 9 10 return msgs [ x ] ; 11 } kan enkelt wrappas till Python med Boost.Python genom: 1 # include <boost/python. hpp> 2 using namespace boost : : python ; 3 BOOST PYTHON MODULE( h e l l o ) 4 { 5 def ( g r e e t, greet, 6 return one of 3 p a rts of a g r e e t i n g ) ; 7 } Jämförelsevis kan man se följande kod som ett exempel på hur man skulle wrappa samma funktion med hjälp av Pythons C-API: 1 // a l l Python i n t e r a c t i o n s use C linkage 2 // and c a l l i n g convention 3 extern C 4 { 5 // Wrapper to handle argument/ r e s u l t 6 // conversion and checking 7 PyObject greet wrap ( PyObject args, 8 PyObject keywords ) 9 { 10 i n t x ; 11 // e x t r a c t /check arguments 12 i f ( PyArg ParseTuple ( args, i, &x ) ) 13 { 14 // invoke wrapped function 15 char const r e s u l t = g r e e t ( x ) ; 16 // convert r e s u l t to Python 17 return PyString FromString ( r e s u l t ) ; 18 } 19 // e r r o r occurred 20 return 0 ; 21 } 22 9

12 23 // Table of wrapped f u n c t i o n s to be 24 // exposed by t h e module 25 s t a t i c PyMethodDef methods [ ] = { 26 { g r e e t, greet wrap, METH VARARGS, 27 return one of 3 p a rts of a g r e e t i n g } 28, { NULL, NULL, 0, NULL } // s e n t i n e l 29 } ; // module i n i t i a l i z a t i o n function 32 DL EXPORT i n i t h e l l o ( ) 33 { 34 // add the methods to the module 35 ( void ) Py InitModule ( h e l l o, methods ) ; 36 } 37 } Detta sätt att wrappa C++ på krävde lite mer jobb än vad SWIG gjorde men hade dock stöd för t.ex. arv och gav stor kontroll på vad man ville ta med om inte hela C++ klassens funktionalitet skulle tillgängliggöras. Boost.Python testades med stor framgång i windowsmiljö och det var enkelt att få klasser skrivna i C++ tillgängliga i Python med bara ett fåtal rader kod. En annan fördel med det hela var att biblioteket, i detta fall en.dll, som kompilerades var det enda som behövdes för att få tillgång till sitt pythonobjekt, dvs det krävdes ingen pythonkod som kapslade in det hela innan man kunde använda det i Python. När denna metod skulle testas på TeMIPklasserna i HP-UX miljö stötte vi på problem. Boost gick till stora delar bra att kompilera, men just Pythonmodulen vägrade att fungera. Vi sökte på nätet och fann att många andra hade haft liknade problem med just detta operativsystem. Någon konkret lösning på det hela hittades dock inte trots ihärdiga försök och vi insåg att det började bli slöseri med tid. Slutligen SWIG fungerade inte riktigt som väntat, och Boost gick tyvärr inte att kompilera med acc under HP-UX. Därför valdes Pythons C API som wrappningsmetod. Det blev en hel del jobb, mer än om man hade använt sig av SWIG eller Boost, men å andra sidan bidrog C API:t till en bättre kontroll över wrappningen, samt möjlighet att senare kunna lägga in stöd för arv mellan klasser. Det kändes då enklare att sätta sig in i C API:t då djupare förståelse för Python och hur dess objekt är uppbyggda hade uppnåtts. 2.3 Utveckling och tester Det första vi gjorde var att skapa en TeMIP PM vilken fungerade som en python-tolk som var integrerad med TeMIP. Detta krävs för att anropen till TeMIP skall fungera. Sedan wrappades några av de klasser som skulle behövas i PyMIP. För att kunna testa dessa PyMIP-klasser så gjordes en del mindre skript som testade funktionalitet i ett tidigt stadium. Det första testet som gjordes var att porta ett enkelt Visual TeMIP-program till Python. Allt detta gjorde var att visa information i konsolen om larm som hämtades från ett OC. Testet fungerade och gav en kvittens på att allt var gjort rätt, att PyMIP fungerade och det blev en första milstolpe. Härefter fortsatte utvecklingen ganska systematiskt efter den klassmall som designats. Fortlöpande tester gjordes allt eftersom nya klasser utvecklats för att kunna testa ytterligare 10

13 funktionalitet. Under utvecklingens gång skapades även flera mindre skript som kunde utföra diverse funktioner som till exempel att skicka larm med jämna mellanrum, lyssna efter nya larm samt slå upp information från TeMIP:s dictionary. Dessa skript användes bland annat för att se vilken minnesanvändning varje objekt hade, samt för att upptäcka och spåra minnesläckor. För att enkelt kunna skapa dokumentation för de wrappade C++-klasserna så skrevs ett skript som automatiskt genererade ett antal HTML-filer. Dessa skapades från kommentarerna, som skulle följa ett visst format, i varje C++-klass header-fil PyMIP Lib Tidigt insåg vi att flera TeMIP-objekt såsom AlarmObject, OperationContext och liknande behövdes som klasser i de olika skripten. Dessa fanns inte som klasser i Visual TeMIP utan krävde ett extra lager abstraktion. Därför gjordes ett nytt bibliotek, helt skrivet i Python, av de vanligaste objekten för att enkelgöra vidare utveckling C-to-Python För att de wrappade klasserna från TeMIP skulle kunna interagera mellan varandra som vanliga TeMIP-klasser krävdes att man skapade en C++-funktion som varje klass använde sig av för att enkelt kunna konvertera returvärden till rätt typ. Funktionen fick heta C-to-Python och blev en enkel och självbeskrivande funktion som var mycket lätt att bygga ut allt eftersom nya klasser tillkom Textlarmlista Ett önskemål från Data Ductus var att det skulle skrivas en ASCII-baserad larmlista för att enkelt kunna bevaka OC:s och hantera larm i en enkel och textbaserad miljö. Tanken var först att den skulle utvecklas med hjälp av ncurses, men det gick tyvärr inte på grund av kompabilitetsproblem med HP-UX. Tanken från början var att skapa ett enkelt skript som använde sig av trådade funktioner för att lyssna efter larm, samt ett enkelt textbaserat menysystem. Det visade sig också att vi var inne på rätt spår med dessa tankar som resulterade i en enkel och användbar larmlista, med begränsad funktionalitet. Ett av de första misstagen som gjordes under utvecklingen av textlarmlistan var att det knappt gjordes någon design över programmet alls innan programmerandet började. Detta innebar en hel del extrajobb och omskrivningar innan man kunde få alla delar att fungera tillsammans. När den första versionen var färdigställd tog det inte lång tid innan vi upptäckte att upplägget behövde snyggas till. Därför gjorde vi en ny version. Den här gången började vi med att designa upp en klasstruktur som kändes modulär och stabil. Detta gjorde att utvecklingen framskred mycket smidigare och en slutgiltig version var snart klar. Slutresultatet blev en larmlista som startade upp trådar för att lyssna och hålla koll på larm inom det OC:n man valt, samt ett enkelt menysystem som presenterade användaren för ett antal olika alternativ. 11

14 Inkommande, nya larm visades direkt i konsolen så man fick en visuell notifiering om att det hänt något i nåt av OC:na. Alternativen i menyn inkluderade bland annat att kunna ändra vilka OC:s man ville bevaka, flagga alarm som terminated 3 eller acknowledged 4, tömma ett helt OC på sina larm med mera. Figur 1: En visning av larmen i den textbaserade larmlistan såg ut såhär 3 Ett alarm som är hanterat och avslutat 4 Ett larm som är uppmärksammat och under hantering 12

15 2.3.4 Webblarmlista Ett annat önskemål som fanns var att skapa en webbaserad larmlista som alternativ till TeMIPklienten. Eftersom det redan fanns en alarmlista som kunde hantera larm i realtid samt hade ett grundläggande klassbibliotek klart var det steget inte så stort att ta. Inledande arbete bestod i att undersöka vilka möjligheter Python hade för att enkelt skapa en stabil webbserver. Snabbt upptäcktes en standardmodul i Python, BaseHTTPServer, som uppfyllde alla önskemål vid den tidpunkten. PyMIP lib användes till stor del i webbservern, men kompletterades löpande för att möta de nya krav som hela tiden ställdes. Version 1 Syftet med den första versionen av webblarmlistan var till stor del ett experiment för att testa våra kunskaper och Pythons webbservermodul, samt för att sätta PyMIP-biblioteket på prov. I denna version sköttes allting i servern. Den svarade på vanliga HTTP-förfrågningar och skapade HTML-sidor utifrån de larm som fanns i servern. Ett skript för att generera HTML av larm skrevs och baserades på HTML-mallar som innehåll nyckelord som byttes ut mot riktig larminformation. Genereringsskriptet hade även stöd för upprepande sektioner i mallarna. Valet att använda sig av mallar grundade sig på att vi ville lämna design av larmvisningen utanför själva webbservern så att de som använde den själva skulle kunna konfigurera utseende samt vilken information som skulle visas med hjälp av nämnda nyckelord och sektioner. Ett exempel på HTML-mallar finns att se i bilaga B. Resultatet blev blandat. Pythons webbservermodul fungerade som förväntats. Men HTML-genereringen var alldeles för långsam och svår att vidareutveckla för att det skulle vara något att fortsätta på. Eftersom servern skapade HTML-sidorna vid en ny förfrågan kunde man aldrig se i realtid att nya larm kommit in, och detta var en stor nackdel eftersom användaren då var tvungen att manuellt uppdatera sidan för att få se förändringar. Version 2 När det var dags för version 2 av webblarmlistan lades fokus lite mer på att få fram en webbserver som skulle vara användbar och smidig, även för icke-tekniska användare. Vi fick tipset om att kolla upp AJAX vilket vi fann intressant och mycket användbart direkt. Själva webbservern blev en hybrid av den gamla teknologin med mallar och AJAX. Mallarna användes bara för att presentera mer eller mindre statisk information, såsom vilka OC:s man bevakade med mera. AJAX användes för att skicka en förfrågan till webbservern som då svarade med nya larm om sådana fanns. I och med AJAX växte det fram en mindre webbklient som bestod av HTMLfiler, HTML-mallar och JavaScript. Denna webbklient gjorde även att sidan blev interaktiv, användaren kunde välja att visa ytterligare information om ett larm, flagga larm som terminated eller acknowledged samt sortera hela listan med ett enkelt musklick. Det första man fick se i tidiga versioner innan man gick in på larmlistan var en lista med collections som fanns att tillgå, där man antingen fick välja en existerande collection, eller skapa en ny och lägga till OC:s i denna. Vi insåg ganska snart att detta var ett felaktigt sätt att använda sig av collections. TeMIP jobbar på så sätt att endast ett system kan lyssna på en specifik collection i taget, så första sidan ändrades till att istället skapa en ny collection varje gång, och man fick direkt ange de OC:s man ville bevaka. 13

16 Efter det att man gjort detta val skickades man vidare in till själva larmlistan där man presenterades med information om det OC man valt, statistik över de larm som servern hade läst in från TeMIP samt en lista över alla dessa larm. För att kunna visa de larm som stämde in på vissa kriterier kunde man klicka fram ett dialogfönster och ställa in filter. En stor begränsning på filter i detta stadium var dock att man endast kunde filtrera på numeriska värden där man angav en undre och en övre gräns. En fördel med att använda AJAX var att nu kunde man visa larm som kom in till servern i realtid för användaren vilket gjorde webbklienten mycket mer användbar. Det vill säga, man var inte längre tvungen att manuellt uppdatera sidan för att få se nya larm utan det skedde semiautomatiskt. Skriptet skickade en förfråga till servern med jämna mellanrum och uppdaterade larmlistan för användaren vid behov. Figur 2: Larmlistan fick följande utseende och det som visas här är själva larmlistan efter att man valt vilka OC:s man vill bevaka Det slutliga resultatet blev ganska tillfredsställande. Denna version blev betydligt snabbare och mer dynamisk än version 1, mycket tack vare användandet av AJAX. Att användaren fick möjlighet att kontrollera vad som visades och att kunna påverka larm var ett stort steg närmare en fullfjädrad, lättanvänlig, webbaserad larmlista. Nackdelar med webbservern var dock att den endast hade stöd för en enda användare. Den kunde hantera förfrågningar från olika håll, men de ändringar som gjordes i sortering, filter och likande sparades på ett enda ställe i servern vilket resulterade i att alla användare fick se de ändringar som en användare utförde. Sedan var användandet av mallar lite för tungt för servern. Allting borde 14

17 hellre skötas med AJAX så att servern kunde få fokusera på sin huvudsakliga uppgift vilket var att bevaka OC:s och hantera larm Korrigeringsfilter Ett sidospår vi gick in på under utvecklingen av webservern var något som kallades korrigeringsfilter. Detta var i vanliga fall en modul skriven i C++ som användes för att kunna filtrera och ändra larm baserat på vilka parametrar de innehöll. T ex att ändra ett larms allvarlighetsgrad eller lägga till/ta bort text som skickades med. Det var en önskan att kunna skriva dessa korrigeringsfilter i Python med hjälp av PyMIP. Mycket för att kunna dra nytta av att Pythonmoduler enkelt går att ladda om dynamiskt vilket gör att man kan ändra och testa nämnda korrigeringsfilter i realtid. Efter lite tester togs en C++ modul fram. Modulens uppgift var att agera som ett riktigt korrigeringsfilter, men istället för att själv sköta korrigeringen läste den in ett Pythonskript och skickade vidare den information den hade till skriptet. Därefter sköttes all logik för att hantera larmet i Python. Detta gjorde att man aldrig behövde läsa om C++ modulen, men kunde ändå ändra hur korrigeringsfiltret betedde sig och låta C++ modulen läsa om den när filen ändrats. Trots den korta tid som lades ned på korrigeringsfilterna och den relativt lilla mängd kod som producerades blev resultatet oerhört bra och lade en stabil grund för fortsatt utveckling och användning. 3 Resultat Tanken att använda Python som skriptspråk för att utveckla mot TeMIP har visat sig vara en mycket bra och enkelt genomförbar metod. Beroende på vilken plattform man ska jobba mot är själva processen med att wrappa Visual TeMIP:s klasser något varierande i komplexitet och tidsåtgång. Dock är det mesta fullt möjligt och man tjänar snabbt in den tid man lagt ned på att bygga grunden. PyMIP-biblioteket innehöll i slutet 26 stycken wrappade C++-klasser. Det har visat sig att det går mycket snabbt att wrappa nya klasser, samt att utöka de redan existerande klasserna. Användandet av biblioteket är smidigt och enkelt, vilket gör att utveckling av nya moduler till TeMIP, skrivna i Python, kan snabbt bli fullt realiserade. Biblioteket lämpar sig även till mindre skript. Exempelvis kan man göra ett skript för att simulera inkommande larm och samtidigt simulera en operatör som hanterar larmen, på några få rader kod. Se bilaga C för ett enkelt exempel skrivet i PyMIP. Webbservern och webbklienten som utvecklades har man fortsatt att jobba på mot en kommersiellt gångbar produkt. En nyare version av webbklienten där mer sköts med hjälp av AJAX och ett helt nytt grafiskt interface har blivit skriven, samt även en ny version av webbservern som nu stödjer multipla, simultana klienter. 4 Diskussion I arbetsuppgiften fanns även ett önskemål att kunna dynamiskt generera nya Python-moduler från objekt som registrerades i TeMIP. Detta fanns det dock ingen tid till att undersöka närmare då vikten lades mer på att få fram en webbserver med tillräcklig funktionalitet. Endast en ytlig undersökning har genomförts och uppfattningen är att det skulle kunna vara klart genomförbart. 15

18 Figur 3: Den nyaste versionen av webblarmlistan Nya objekt registreras i TeMIP:s dictionary, vilket gör det fullt möjligt att kunna utläsa de funktioner och parametrar som objektet kan behöva. Någon vidare undersökning kommer inte att utföras under detta examensarbete. 16

19 5 Referenser - Pythons officiella hemsida ( ) - SWIG ( ) - Boost.Python ( ) 17

20 Bilagor A Visual TeMIP vs. PyMIP En kodsnutt skriven i C++ för Visual TeMIP 1 // 2 // Visual TeMIP Include F i l e s 3 // 4 # include <tfc framework. hxx> 5 # include <t e m i p a h f m s r v c i f. h> 6 # include <tfc wp mt log. hxx> 7 # include <temip mt log report. hxx> 8 # include <t f c s p c a t a l o g. hxx> 9 # include <n l t y p e s. h> 10 # include <iostream > // 13 // Example Include F i l e s 14 // 15 # include s w i t c h a p p l i. hxx // 18 // Implementation of the TeMIP Application 19 // 20 IMPLEMENT TEMIP APPLICATION( s w i t c h a p p l i ) # define TRACE SWITCH APPLI MCC T CVR MApplicationswitch appli : : OnExecute ( i n t argc, 26 char argv [ ] ) 27 { MCC T CVR r e s u l t = MCC S NORMAL; // Create the OC e n t i t y 32 MFullName ocname( argv [ 1 ] ) ; 33 MClientEntitySpec alarmentity ; 34 alarmentity. AddClassInstance ( 35 MCC K CLASS OPERATION CONTEXT, ocname ) ; 36 alarmentity. AddWildInstance (MCC K CLASS ALARM OBJECT ) ; // Get a d i c t i o n a r y o b j e c t 39 MDictClass c l assdef ( alarmentity ) ; // Create the c a l l 42 MCallShow showcall ( alarmentity, MCC K PRT CHAR ) ; // Loop f o r e v e r 45 do 46 { 47 // Make the c a l l 18