Betalsystem för Inteli3 GSM roaming plattform

Transkript

1 School of Mathematics and Systems Engineering Reports from MSI - Rapporter från MSI Betalsystem för Inteli3 GSM roaming plattform Faruk Sehovic Martin Åberg Sep 2007 MSI Report Växjö University ISSN SE VÄXJÖ ISRN VXU/MSI/EL/E/ /--SE

2 Abstract Our assignment is to create a product that addresses the so called Roaming costs that are added to the phone bill when a telephone call has to travel or roam through the networks of different telecom providers. To deal with this problem a company called the CallKey Group Ltd came up with a solution called CallKeyOne which is a GSM SIM Card based service. CallKeyOne will greatly reduce the roaming costs for outgoing calls and can provide free incoming calls while roaming in most countries. This often means a reduced cost for outgoing international calls through cell phones by up to 70 %. The problem presented to the writers in this thesis was to integrate the CallKey API with an online payment service known as PayNova. The finished product would be a fully functional online payment service allowing the customers to refill his or her SIM Card with prepaid credits for international calls. The assignment also consists of creating a database for storage of customer information and transaction information. The Customer will be paying by the use of a credit card and the money will then be transferred to the agent company. The assignment has been carried out with the assistance of the company ByAir AB that provided us with this problem. ByAir AB is a Swedish company based in Gothenburg and has the license to use the CallKeyOne technology in Sweden. Sammanfattning Vår uppgift är att sammansätta en produkt som skall sänka de så kallade Roaming avgifterna som uppkommer då ett telefonsamtal måste resa eller roama genom flera olika operatörers mobilnät. För att sänka denna kostnad har ett företag vid namn CallKey Group Ltd tagit fram en produkt, CallKeyOne som är en lösning baserat på GSM SIM-kort. CallKeyOne kommer att reducera kostnaden för utgående samtal radikalt och att motta samtal blir gratis i de flesta länder. Detta leder ofta till en reducerad kostnad med upp till 70 %. Uppgiften för författarna av denna rapport var att integrera CallKey: s API med en webbaserad betalsida vid namn PayNova. Den färdiga produkten ska bli en fullt fungerande produkt som tillåter kunderna att fylla på sitt SIM-kort med förbetald kredit för internationella samtal. Till uppgiften hör även att skapa en databas där information om överföringar och kunder skall lagras. Kunden ska kunna betala via kreditkort och pengarna ska sedan överföras till uppdragsgivarna. Uppgiften har utförts med hjälp av ByAir AB som är ett svenskt företag med kontor i Göteborg som har licensen för CallKeyOne i Sverige.

3 Inehållsförteckning Abstract 2 Sammanfattning 3 1. Inledning Bakgrund Syfte Definitioner Avgränsningar 7 2. Tillvägagångssätt Analys och Design Use Cases Kommunikation mellan webbplatserna Flödesbeskrivning Implementering Databasen Planering Skapande av tabeller Tabeller Uppbyggnad Webbapplikationen Säkerhet och felhantering Översikt över systemet FirstPage Registrering Registration Sucsess MainPage Activation ChangeCustomerInfo BuyCredit OrderComplete ErrorPage Slutsats Referenser 30 Bilaga A källkod för Inteli3 Roaming Plattform 31 MainPage.aspx.cs 31 FirstPage.aspx.cs 34 BuyCredit.aspx.cs 36 ChangeCustomerInformation.aspx.cs 45 Registration.aspx.cs 54 PaynovaSessionRequest.aspx.cs 60 PaynovaIframe.aspx.cs 65 PaymentStatusNotify.aspx.cs 67 OrderComplete.aspx.cs 70 OrderCanceled.aspx.cs 75 ErrorPage.aspx.cs 78

4 1. Inledning Denna rapport är en del av ett examensarbete för programmet Högskoleingenjör i datateknik, vilket är ett program omfattande 120 poäng på Växjö universitet. Examensarbetet har utförts under vårterminen 2007 av Martin Åberg och Faruk Sehovic. Handledare har varit Tobias Wernergren och examinatorn har varit Anders Haggren. Examensarbetet är utfört i samarbete med ett telekomföretag vid namn ByAir AB. Detta företag har i sin tur blivit anlitade av företaget AFSIK - Active Flexible Systems i Kalmar AB för att ta fram en produkt. 1.1 Bakgrund ByAir är ett företag som arbetar med terminering av utlandssamtal från olika delar av världen till Europa. Idag består företaget av två avdelningar, en avdelning som arbetar med teknikutveckling och en som arbetar med försäljning och marknadsföring. På tekniksidan arbetar de främst med utveckling av softswitchar samt som konsulter för större telekomföretag. En softswitch är en mjukvarubaserad switch för telekomtrafik med multiprotokollstöd och som klarar höga belastningar. Några exempel på vilka företag som ByAir samarbetar med är Vodafone/Telenor, Belgacom och Korean Telecom. ByAir har nyligen inlett ett samarbete med ett brittiskt företag vid namn Inteli3 vilket arbetar med att pressa de så kallade roamingavgifterna. Roamingavgifter uppstår när en person ringer med sin mobiltelefon utanför sin operatörs lokala täckningsarea. Detta eftersom samtalet då måste passera genom flera olika operatörers nät på vägen till sitt mål. Således kallas det att samtalet roamar igenom dessa nät och processen gör att det ofta blir väldigt dyrt både för den individ som ringer och den tar emot samtalet. Inteli3 använder sig av ett protokoll som kallas CallKey. CallKey Group LTD är ett brittiskt företag vars företagsidé är att förse andra företag och privatpersoner med en lösning som reducerar dessa kostnader betydligt. Teknologin fungerar på så sätt att istället för att samtalet kopplas upp direkt mellan avsändare och mottagare så går processen via en HUB. Den person som ringer samtalet kopplas först up mot hubben där signalen anger vem syftet är att ringa till. Hubben kopplar sedan ner samtalet en liten stund och ringer upp den andra personen. När personen i fråga svarar så ringer sedan hubben upp avsändaren igen och kopplar samman de två samtalen. På detta sätt kan man undvika en del av de kostnader som annars hade uppstått då samtalet gått hela vägen direkt till mottagaren.

5 1.2 Syfte I dagsläget så finns ett färdigt fungerande system för fakturakunder. Det som nu skall implementeras är ett system för betalning som skall göra det möjligt för kunder att betala in pengar på ett SIM-kort över Internet. En av anledningarna till detta är att ByAir idag har ett flertal kunder i resebyråbranschen som vill kunna erbjuda sina resenärer ett Inteli3 SIM-kort vid utlandsresor. Det som nu behöver utvecklas är ett system som integrerar Inteli3: s API med flera olika betalsystem som t.ex. PayNova. Vår arbetsuppgift kommer att, förutom att bygga själva systemet, även innefatta att jobba tillsammans med en designer och copywriter från ByAir för att på detta sätt bygga en färdig produkt. Språket som implementeringen skall göras i är C# och utvecklingsmiljön är. NET. Databasen skall ligga på en på en Microsoft Server 2003 med Microsoft sql 2000 installerat. Denna server användas under utvecklingen för testning och implementering. Då systemet kommer ta hand om transaktionen är det väldigt viktigt hur informationen som finns till hands hanteras. PayNova är ett företag som erbjuder en internationell kontobaserad betaltjänst via Internet PayNova erbjuder ett ggt betalsätt men det är upp till oss att garantera att kunden kommer få den order som han betalat för. Därför är det väldigt viktigt att konstruera en databas där behöriga ska kunna leta upp en transaktion och se hur långt den kommit innan ett fel uppstod. Syftet är att vi innan den 7 juni 2007, då presentationen av rapporten ska göras, ska ha en klar produkt som då ska testas och godkännas av företaget ByAir. Produkten ska vara så pass klar så att en simulerad betalning och laddning till telefonkortet ska kunna göras vid presentationen. 1.3 Definitioner API XML Står för Application Programming Interface och är ett källkodgränssnitt som används av utomstående program när dessa ska anropa olika tjänster som finns i API. Står för extensible Markup Langugae och är ett universellt och utbyggbart märkspråk. XML används i syfte att utväxla data mellan informationssystem som inte är uppbyggda på samma språk.

6 1.4 Avgränsningar Webbplatsen som vi valde att göra har vi begränsat för att kunna slutföra den på de tio veckor som vi har haft till vårt förfogande. Vid konsultation med företaget kom vi överens om att designen skulle göras av företagets egen designer. Denna avgränsning gjordes eftersom vi inte hade kunskaper inom html-design och för att tiden inte skulle räcka till. Vi bestämde även tillsammans med företaget att webbplatsen bara skulle ha tjänsten för att ladda på kredit samt alternativet för att redigera sina kunduppgifter. Dessa två avgränsningar fick vi oss tilldelade av företaget då detta är den enda tjänst och alternativ de behövde för den första lanseringen av webbplatsen. Flera mindre begränsningar gjordes även under arbetets gång. Dessa begränsningar består först och främst av att kunden bara kan betala med sitt kreditkort samt välja valutan svenska kronor (SEK), USA-dollar (USD) alternativt euro (EUR). Kunden kan inte heller förhandsgranska sina ändrade kunduppgifter. De första två avgränsningarna beträffande kreditkortsbetalning och val av valuta diskuterades fram tillsammans med företaget och antogs sedan då företaget ansåg att dessa alternativ var de mest nödvändiga i första versionen av webbplatsen. Avgränsningen rörande att kunden inte kan förhandsgranska sina ändrade uppgifter innan de sparas diskuterade vi fram inom gruppen. Avgränsningen valdes på grund av att implementeringen av detta alternativ orsakade komplikationer som var för tidskrävande för att åtgärdas under den tid vi hade till vårt förfogande. 2. Tillvägagångssätt Projektet inleddes med ett möte i ByAirs lokaler i Göteborg tillsammans med vår projekthandledare Tobias Wernergren. Vi började med att diskutera en handlingsplan för projektet och vad som behövde göras. Vi valde att dela upp arbetet i två faser, en fas för analys/design och en för implementering. Det som behövde göras var att först sätta upp en databas för att lagra information om kunderna och deras transaktioner. Databasen skulle byggas på en MSSQL server. Efter detta skulle utformningen av själva produkten ske. Vi beslutade att det skulle bli ett webbaserat system baserat på ASP.NET 2.0 skrivet i C#.

7 2.1 Analys och Design Den första fasen som vi valt att kalla Analys och Design innefattade en insamling av fakta och information om bland annat databasen, systemets funktionalitet, händelseflöden och felhantering. Denna del av arbetet är väldigt viktigt då det är nödvändigt att veta så mycket som möjligt om ett system innan man börjar implementera. När insamling av all viktig data kring systemets byggstenar var gjort började vi på designen, denna del görs för att få en klarare bild över hur systemet kommer att vara uppbyggt Use Cases Som ett första steg i analysfasen valde vi att ta fram så kallade Use Cases för den färdiga produkten. Ett Use Case har till uppgift att på ett enkelt sätt ge en överblick över vad som ska ske för att en användare av produkten skall kunna utföra en specifik uppgift. Detta ger utvecklaren en bra överblick över hur systemet skall konstrueras för att uppfylla alla de olika situationerna som kan uppstå på vägen mellan startpunkten och uppgiftens mål. Ett use case kan också kallas för ett scenario i programmet, alltså ett händelseflöde. Varje Use Case har en eller flera aktörer. En aktör är den person som på något sätt interagerar och sätter de händelser som finns i Use Caset i rörelse. En aktör kan t.ex. vara användaren av programmet men det kan även vara systemet självt. Alla Use Cases har även ett mål som skall vara uppfyllt efter det att alla händelser i det utförts. En del Use Cases har så kallade förkrav vilka måste vara uppfyllda innan de händelseförlopp som Use Caset innehåller kan starta. Ett sådant förkrav kan t.ex. vara att användaren är inloggad i systemet. Händelserna i ett Use Case är numrerade i den ordningen de sker, alltså utförs alltid händelsen med händelse nummer fyra före händelse nummer fem osv. Sist i Use Caset anger man Undantag, vilket anger alternativa vägar som händelseförloppet kan ta beroende på t.ex. val som aktören gör i systemet eller vid hantering av olika fel som kan ske när programmet körs. Som exempel för dessa undantag kan nämnas då en användare ombeds fylla i sitt för och efternamn men enbart fyller i sitt förnamn. Programmet kan då känna av detta och ta en alternativ väg i Use Caset vilket alltså ger ett annat händelseflöde än om användaren matat in rätt data direkt. Undantagen är numrerade precis som de vanliga händelserna och ett undantag med nummer fem är därmed ett alternativt flöde till händelse nummer fem.

8 Påfyllning Det första Use Caset vi konstruerade ses i Bild 2.1 som visar de steg som tas då en användare loggar in i vårt system och väljer den summa denne önskar fylla på sitt SIM-kort med. Bild 2.1 Namn: Påfyllning Aktör: Kunden Mål: Kunden loggar in och väljer hur mycket hans telefonkort ska tankas med. Förkrav: Kunden ska redan vara registrerad kund. Händelser: 1. Kunden presenteras med en inloggnings ruta och en registrera ny användare knapp. 2. Kunden skriver in sitt användar namn och sitt lösenord. 3. Systemet kontrollerar så att den inskrivna datan överstämmer med kundens sparade uppgifter och loggar in kunden. 4. Systemet loggar in användaren och presenterar olika val som kunden kan göra. 5. Kunden väljer att ladda på sitt telefonkort med pengar. 6. Systemet hämtar kundens lista över tillgängliga telefoner som kunden äger.kunden väljer en av telefonerna som pengarna ska sätas in på. 7. Kunden går vidare och väljer mängd kredit. Valutan är förinställd på kundens ursprungsland. 8. Kunden skickas vidare till Paynova där information om kreditkort anges. 9. Kunden accepterar ordern. Undantag: 3 a) Om kunden inte hittas av systemet. 1. Gå tillbaka till steg a) Kunden väljer att ändra ordern. 1. Sidan laddas om och kunden återgår till steg 7 men med redan ifyllda val sen tidigare.

9 Transaktion I Use Case Transaction som finns i Bild 2.2 illustreras de händelser som utförs från det att kunden är inloggad i systemet och har valt summa pengar att sätta in på SIM-kortet tills dess att betalningen från kundens kreditkort till företaget är utförd. Bild 2.2 Namn: Transaction Mål: Betalning från kund till Företaget Aktör: System Förkrav: 1. Kunden är inloggad i systemet. 2. Kunden har fyllt i mängden som skall överföras. Händelser: 1. Systemet får bekräftelse om ny order. 2. Systemet skickar nödvändig information till Paynova (PaymentSessionRequest). 3. Paynova skickar ett svar till Systemet (PaymentSessionResponse). 4. Systemet skickar en Iframe till Paynovas Webservice som genererar ett formulär där användaren kan fylla i information. 5. Användaren fyller i betalningssätt. 6. Användaren skriver in sitt kort eller banknummer. 7. PaymentStatus(Request) skickas från Paynova till Systemet. 8. Systemet skickar ett svar på medelandet att allt är ok (Response). 9. Paynova skickar ett Redirect till Länksystemet som i sin tur skickar vidare användaren till en sida som visar info om överföringen. Om den lyckades och varför den inte lyckades om så är fallet. Undantag: 3 a) Inget svar kommer från Paynova. 1. Informera kunden om att inget svar har fåtts och be denne försöka igen.

10 Påfyllning genom CallKey I Use Case Påfyllning genom CallKey som finns i Bild 2.3 ser vi de händelser som utförs efter att kundens betalning gått igenom och krediten som kunden köpt skall föras in på SIM- Kortet. Bild 2.3 Namn: Påfyllning genom CallKey Aktör: Länksystemet Mål: Lägga till den redan förbetalda krediten på kundens telefonkort. Förkrav: Transaktionen har gått igenom. Utlösare: PaymentStatus(Respons) Händelser: 1. Systemet gör ett anrop till callkey metoden AddPrepaidCredit. 2. CallKey reunerar en respons kod, kundens id och real-tids balans. Undantag: 2 a) Om respons kod 2036 eller 20xx. 1. Systemet kontrollerar så Kund-id överstämmer med kunden och att mängd kredit är större än noll. 2. Återgå till steg 1. 2 b) Om responskod 70xx. 1. Kontakta Systemadministratören och kontrollera om kundens kort kan tankas på genom kredit.

11 2.1.2 Kommunikation mellan webbplatserna För att få en bättre överblick över kommunikationen mellan CallKey API: t, PayNova och vårt system gjorde vi ett sekvensdiagram samt en sekvensbeskrivning. Dessa syftar till att ge en god överblick över kommunikationen som behöver ske i programmet. De kvadrater som kan ses högst upp i bild 2.4 representerar de olika delarna som kommer att ingå i kommunikationen. Customer är användaren av systemet och det är vid denna del som kommunikationen börjar. Linker harr vi valt att kalla den del av systemet som vi konstruerat och det är denna del som kommunicerar med PayNova Webservices, PayNova Webform och CallKey API:t. Kommunikationsflödet sker i fallande ordning utmed de lodräta linjerna. Pilarna som går horisontellt mellan delarna representerar kommunikationen. Över pilarna står namnet på de funktioner som de olika delarna anropar. Bild 2.4 Bilden representerar kommunikationen mellan de olika delarna som systemet består av Flödesbeskrivning Det första användaren gör är att logga in eller skapa ett nytt konto. Systemet presenterar sedan olika val för användaren, som t.ex. att lägga till pengar eller att ändra sina kontouppgifter. Om vi antar att användaren väljer att lägga till pengar på sitt konto får han nu fram olika alternativ för att välja summa och valuta samt på vilket SIM-kort pengarna skall sättas in. När användaren gjort dessa val och accepterat ordern genererar systemet ett så kallat HTTP POST anrop som sedan skickas till PayNova i form av ett PaymentSession (Request). Detta anrop meddelar PayNova att vi vill starta en ny överföring via deras sida. I anropet finns information som användaren angett om den summa pengar och valuta samt även annan information rörande exempelvis kundens namn och vilket land kunden kommer från.

12 I anropet finns också ett användarnamn och lösenord som vi i egenskap av mellanhand måste ange för att få skapa en ny session hos PayNova. PayNova skickar sedan ett PaymentSession (Respons) som verifierar att betalningen kan ske. Svaret består av en sifferkombination som låter vårt system veta om en ny session kan skapas och ifall de fall detta inte är möjligt får vi även reda på varför detta hänt. Om allt fungerar som tänkt finns även ett sessionid med som kommer att användas senare i kommunikationen med PayNova. Vårt system skickar sedan ett anrop till PayNova Webbform som är en webbaserad del av PayNova. Detta anrop sker så att en typ av formulär skapas med hjälp av det unika sessionid som kom från PaymentSession (Response). Användaren skickas sedan vidare till en sida som genererats av PayNova med hjälp av vårt formulär och det SessionID vi tilldelades. På denna sida får användaren fylla i sina kreditkortsuppgifter och annan nödvändig information för betalningen. Efter att användaren fyllt i all information och accepterat så sker kommunikationen mellan PayNova Webbform och PayNova Webbservice. Webbservice skickar sedan ett svar på om betalningen gått igenom eller inte. Detta svar kan inte skickas direkt till vårt system eftersom det inte går att förutse hur lång tid det tar för användaren att fylla i de nödvändiga uppgifterna. Svaret skickas istället till en fördefinierad sida som ligger och väntar på detta svar. Systemet får sedan läsa av denna sida för att ta reda på vad som fanns i anropet. Efter att systemet mottagit meddelandet om transaktionen och om allt var godtagbart så kommer CallKey API: t att anropas för att fylla på användarens telefonkort med vald summa pengar. Detta anrop sker med hjälp av så kallad XML som är en vanlig standard vid kommunikation mellan olika slags gränssnitt. Ett svar i form av ett nytt XML Dokument skickas sedan av CallKey till vårt system. Detta XML dokument tolkas sedan och beroende på informationen som finns i så skickas en respons till PayNova att antingen fullfölja transaktionen, avsluta den eller att ett fel har skett med systemet. Om betalningen genomförts korrekt skickas användaren vidare till en sida där information om köpet visas, som exempelvis vilken summa pengar som satts in på kontot. Om fallet skulle vara att något gick fel med betalningen och denna avbröts skickas användaren vidare till en annan sida där information om detta visas.

13 3. Implementering 3.1 Databasen Efter den inledande design- och analysfasen började vi med delen rörande implementeringen och att bygga MSSQL databasen. Databasen är gjord med hjälp av frågespråket SQL vilket fungerar så att all information som skall sparas i databasen sparas i tabeller. Tabellen nedan är ett exempel på hur en SQL tabell kan se ut. Som vi ser så innehåller denna tabell information om olika personer. Tabell 1. SQL-tabell med personinformation Personer ID Namn Ålder Adress 1 Sven Svensson 34 Åkervägen 23 2 Bertil Karlsson 24 Slottsgatan 44 3 Joakim Eriksson 24 Sjögatan 24 Det är upp till programmeraren att skapa en smart struktur över tabellerna så att informationen kan hittas så fort som möjligt. Det är även viktigt att tänka på att göra en effektiv databas som kan hantera stora mängder information. Själva SQL språket fungerar så att man med hjälp av så kallade Querys eller frågor till databasen kan hämta information ur de olika tabellerna. En SQL fråga kan se ut på följande vis: SELECT Namn FROM Personer WHERE ID = 3; Frågan ovan består av de tre delarna SELECT, FROM och WHERE. Det som står efter en SELECT är namnet på kolumnen där informationen ska hämtas från. I vårt fall har vi valt Namn som kolumn men vi skulle lika gärna kunna ta Ålder eller alla kolumnerna genom att skriva * efter SELECT. Detta ska man försöka undvika och istället skriva ner namnet på alla kolumnerna som man vill hämta då det blir lättare att läsa koden. Nästa del är FROM och den bestämmer ur vilken tabell informationen ska hämtas. Här kan man välja att hämta information ur flera tabeller genom att skriva ner tabellernas namn. Eftersom vi i vårt exempel bara har tabellen Person är det bara den vi kan hämta från. Genom att specificera flera tabeller kan man kombinera informationen man hämtar för att få fram unik data ur en tabell beroende på de andra tabellernas data. WHERE används för att specificera exakt rad i tabellen som data ska läsas från. I vårt exempel är ID unikt vilket innebär att det bara kommer att finnas en rad i tabellen som har just det ID:et. Vi kunde valt att skriva WHERE Ålder = 27 AND Adress = Sjögatan 24 vilket skulle ge oss samma svar.

14 3.2 Planering Det första vi gjorde var att ta fram en enkel modell över hur databasen skulle se ut, se bild Vi ritade upp ett enkelt diagram för detta som skulle ge en bättre överblick över vilka olika tabeller som skulle komma att behövas för att spara all nödvändig information i databasen. Modellen visar också med pilar vilka typer av relationer som finns mellan de olika tabellerna. Kvadraterna i modellen representerar SQL tabeller där olika data lagras. Pilarna som går mellan kvadraterna visar om tabellerna har någon relation gentemot varandra och i det fall tabellerna har det visar de även vilken typ av förhållande de har till varandra med hjälp av pilarna. Pilarna pekar på den tabell som har relationen till den andra tabellen, exempelvis ser vi i modellen att tabellerna Language, Coun och PhoneNumbers alla har relationer till tabellen Customer som alltså representerar själva kunden. Siffrorna som står skrivna på pilarna representerar vilken typ av relation de olika tabellerna har gentemot varandra. I vårt diagram över databasen har vi använt oss av två olika typer av relationer. En till en relation och En till många raltion. En till en relation har vi visat genom att skriva siffran 1 på linjen och denna typ av relation innebär att en unik rad i tabellen bara kan ha en relation till en annan tabell. Som exempel kan vi titta på Customer och Coun tabellerna. En kund kan bara ha en Coun och därför är denna relation En till en relation. En till många relation har vi visat genom att skriva 1...N på pilarna och denna typ av relation inebbär att en unik rad i tabellen kan ha många relationer till en annan tabell. Som exempel tittar vi på Customer och Transactions där en Customer kan ha många olika transaktioner som sparats i Transactions men en transaktion i Transactions kan bara ägas av en kund i Customer. Bild 3.1 Bilden visar uppbyggnaden av databasen som använts i arbetet.

15 3.3 Skapande av tabeller Efter att vi fått denna överblick över hur databasen skulle byggas upp så började vi med att skapa de olika tabellerna som behövdes. Detta görs med hjälp av SQL och så kallade Create Table satser. En Create Table sats kan se lite olika ut beroende på vilken typ av SQL databas som används. Då vi använde MSSQL så såg dessa satser ut på följande vis: CREATE TABLE Currency ID INT AUTO INCREMENT NOT NULL, Currency VARCHAR(3), PRIMARY KEY(ID) CREATE INDEX CurrencyIndex ON Currency(ID) Exemplet ovan skapar en tabell vid namn Currency som har variablerna ID och Currency. Variabeln ID är av typen Integer och ökas automatiskt på med ett när en ny post läggs till i tabellen, denna variabel behöver därmed inte sättas manuellt. Variabeln Currency är av typen variable-character och har en längd på maximalt tre bokstäver. För att kunna hitta i en SQL tabell måste man ha en Nyckel som är unik för varje rad i tabellen, i detta fall är det ID kolumnen. Vi valde även att skapa ett så kallat index för ID vilket gör att snabbare sökning är möjlig. 3.4 Tabeller Uppbyggnad I vårt program har vi använt oss av följande tabeller: API : Coun: Currency : Denna tabell innehåller förutom ett unikt ID även en variabel Namn som används för att beskriva de olika API:N som kan användas tillsammans med Systemet. Används för att ange vilken nationalitet en användare har, innehåller variablerna ID och Nationality som är en landsförkortning som exempelvis SWE för Sverige. Tabellen innehåller även variabeln Name som är namnet på landet, i samma fall, Sverige. Används för att ange valutan vid betalningarna och innehåller ID samt Name, som är en förkortning av valuta, exempelvis förkortningen SEK för svenska kronor.

16 Customer: Events: Är en tabell som representerar kunden i vårt system. Tabellen har variablerna ID, Password, Name, UserName, och verifiedaccount samt CounID och LanguageID. Password och UserName används för att logga in på kundens konto, Name anger kundens namn och anger kundens som han kan kontaktas via. De två variablerna CounID och LanguageID används för att länka ihop tabellen med tabellerna Coun och Language. Variabeln CounID hör alltså ihop med den rad i Coun som har det värde i sin ID variabel som CounID har. Används för att en administratör enkelt ska kunna se vilka händelser som skett då en kund gjort en transaktion via vårt system. I tabellen sparas TransaktionsID som anger vilken transaktion det gäller och EnventID som anger vilken händelse i systemet som genomförts. I tabellen finns även en tidstämpel, CreatedAt, som anger vid vilken tidpunkt transaktionen och händelsen genomfördes. EventType: Anger vilket typ av event eller händelse som genomförts. I tabellen finns variablerna APIID och EventID samt Type. APIID används för att binda ett event till ett visst API och EventID används för att binda denna typen av Event till ett specifikt event i tabellen Events: ISO693: Language: Phones: Type anger vilken typ av event det handlar om, exempelvis anrop eller svar. Denna tabell innehåller en lista över alla nationaliteter enligt ISO693- standarden vilken är en standard över landsförkortningar. Innehåller information om vilket språk kunden använder. Denna tabell har variablerna Language, Name och ID. Language innehåller språkförkortningar som exempelvis SWE för svenska och Name innehåller de hela språknamnen, svenska. Denna tabell används för att ange de telefonnummer som tillhör en kund. Tabellen innehåller ID, CustomerID, PhoneNR och PinNR. CustomerID används för att skapa länken mellan en kund och hans telefonnummer, PhoneNR är telefonnumret och PinNR är PIN-numret som tillhör SIM-kortet Transaction: Används för att hålla reda på de transaktioner som systemet utför. Innehåller variablerna ID, CreatedAt och SuperTransactionID. Variabeln ID identifierar de olika transaktionerna och CreatedAt anger när en transaktion genomfördes. SuperTransactionID: Används för att länka samman tabellen med SuperTransaktion.

17 Super- Transaction: Denna tabell används för att ange de gemensamma attribut som alla transaktioner har, denna länkas sedan ihop med de tabellerna som anger den specifika typen av transaktion. Money- Transaction: Denna tabell anger de specifika variabler som används vid överföring av pengar. Tabellen innehåller variablerna ID, Amount och CurrecyID. Amount anger den summa pengar som överfördes och variabeln CurrencyID används för att länka ihop tabellen med en valuta i tabellen Currency. XMLFile: Denna tabell används för att lagra XML filer som skickas fram och tillbaka mellan de olika delarna i det totala systemet. Detta möjliggör att hanteraren senare skall kunna gå tillbaka och se vad som har skickats. 3.5 Webbapplikationen Efter att alla tabeller till databasen var klara så byggde vi vidare på de Use Case-diagram som vi tagit fram i ett tidigare skede. Detta gjorde vi genom att börja göra enklare klassdiagram över vårt system. Klassdiagram används för att få en överblick över de klasser som man tror kommer att behövas i projekt och även vilka metoder och variabler dessa innehåller. Att jobba med Webbapplikationer var en ny erfarenhet för oss och därför var det först svårt att få en helhetsbild över hur systemet skulle byggas upp. Efter att ha arbetat med detta så började vi dock att få grepp om det mer och mer. Samtliga sidor är byggda med ASP.NET 2.0 plattformen och språket C#. 3.6 Säkerhet och felhantering Vid arbete med överföring av pengar är det självklart väldigt viktigt att allt måste vara säkert, vi har därför gjort detta projekt med säkerhet i fokus. Eftersom själva överföringen sköts av PayNova så behövde vi inte oroa oss för säkerheten i det steget men det finns andra delar i programmet som är känsliga och måste skyddas. En användares uppgifter och speciellt användarens lösenord är tydliga exempel på uppgifter som måste skyddas noggrant. För att se till att lösenordet är så skyddat som möjligt har vi därför valt att spara alla lösenord i databasen krypterade med MD5-standarden. MD5 fungerar så att man av den inmatade datan skapar ett hash-värde som sedan inte går att kryptera tillbaka. En annan säkerhetsåtgärd som vi implementerat i kommunikationen är skydd mot så kallade SQL Injections. Dessa går ut på att med hjälp av att mata in SQLkommandon istället för den önskade indatan när man kör programmet. Detta kan leda till katastrofala följder om det inte stoppas eftersom någon utomstående på detta vis kan ta bort hela databasen alternativt eller ladda ner den och spara den på sin egen dator.

18 Som exempel kan vi säga att kunden matar in följande: ; DROP Table Customer istället för sitt användarnamn. Detta som matats in är en typ av SQL-fråga som tar tabellen Customer och raderar innehållet i den. Ett semikolon ; i en SQL-fråga avbryter frågan. Vår fråga mot databasen vid inloggning kan se ut på följande sätt. SELECT ID FROM Customer WHERE username = + inmatad_namn ;. Eftersom semikolon avbryter en SQL-fråga kommer semikolonet i Injections att stoppa den ursprungliga frågan och utföra en radering av tabellen Customer. SELECT ID FROM Customer WHERE username = ; DROP Table Customer ; Det vi kan göra för att förhindra detta är att med hjälp av så kallade escape -tecken ändra om denna inmatade datan så att de inte längre tolkas som kommandon av SQL-databasen. Vi kan ta kommandot DROP Table Customer som exempel, det vi gör är då att lägga till ett tecken alternativt en bokstav framför all indata som går till databasen. Vi har i vårt program använt oss alltså skulle DROP Table Customer istället skickas in Table Customer och indatan läses då av som en vanlig sträng istället för ett kommando av vår databas.

19 3.7 Översikt över systemet Eftersom vi gjort ett webbaserat system så har vi inte kunnat använda oss av traditionella klassdiagram vilka i vanliga fall används vid utvecklandet av program. Vi har istället valt att representera vårt program och de olika sidorna det innehåller med hjälp av ett eget diagram och utförliga beskrivningar av de olika delarna i det, se bild 3.2. Detta diagram har vi ritat upp allt eftersom arbetet har pågått och vi har fått en bättre insikt i hur produkten ska se ut i sitt slutgiltiga skick. Vi började med att implementera FirstPage eftersom det kändes mest logiskt. Redan under denna sidas implementering fick vi komma i kontakt med databas och hur man skapar ett objekt av en uppkoppling mot den. Även genom att studera CallKey och PayNova Dokumentationen fick vi en överblick av hur det ska fungera med implementeringen av dessa. Bild 3.2 Det vi ser i bilden ovan är en en representation över hela systemet som vi har byggt, det visar alla sidor som finns i programmet och hur man kan komma runt mellan dem.

20 3.7.1 FirstPage Detta är den sida som användaren först kommer till då denne önskar logga in i vårt system, se bild 3.3. Användaren har två olika val att välja mellan, antingen att logga in på ett redan skapat konto med hjälp av ett befintligt användarnamn och lösenord eller att registrera ett nytt konto i vårt system. När sidan laddas skapas direkt en SQL-uppkoppling mot databasen. Om denna uppkoppling skulle misslyckas kommer besökaren att förflyttas till en felhanteringssida som kommer att meddela besökaren om vad för typ av fel förflyttningen orsakades av. Om användaren väljer att logga in så kommer systemet att göra en kontroll mot databasen om det användarnamn och lösenord som användaren angav är korrekta. Systemet kontrollerar även att det angivna kontot har statusen aktiverat i databasen. Även kundens e- mailadress och ID kommer att returneras. På dessa returvärden skapar vi sedan Sessions och dessa används för att skicka information mellan de olika sidorna som körs. På detta sätt underlättar vi kodningen då vi nu inte behöver göra något anrop för att hämta dessa värden fler gånger. Om användaren anger fel lösenord eller användarnamn eller ifall det konto som denne försöker logga in på inte är aktiverat så kommer detta meddelas med en text som kommer placeras i en label på sidan. Bild 3.3 Firstpage som låter användaren registrera sig eller logga in med design implementerad.

21 3.7.2 Registrering Sidan Registrering är till för att registrera nya användare i systemet och därefter lägga till dessa i listan med användare i databasen, se bild 3.4. Användaren kommer till denna sida genom att på sidan Firstpage cka på knappen New User. För att registrera sig och kunna använda vår tjänst måste användaren först fylla i en rad med information som exempelvis användarnamn, lösenord och adress. Användaren måste även ange det telefonnummer och den PIN-kod som tillhör det SIM-kortet denne inhandlat. Efter att kunden angivigt all information görs en kontroll av formuläret för att vara säker på att det som kunden angivigt är korrekt. Om ett fel upptäcks eller om användaren glömt att fylla i någon viss information meddelas detta och kunden får möjlighet att ändra eller lägga till ny information. För att vara helt säker på att användaren verkligen angett rätt telefonnummer och PIN-kod görs även en kontroll gentemot CallKey som har alla telefonnummer och tillhörande PIN-koder sparade. När all information är korrekt så sparas all data i våran databas och ett aktiveringsmail skickas till användarens angivna adress. Användaren skickas nu vidare till sidan Registration Success. Bild 3.4 Registration som låter kunden registrera sig genom att fylla i nödvändiga uppgifter.

22 3.7.3 Registration Success Denna sida, se bild 3.5, meddelar användaren att dess konto nu är registrerat och att ett aktiveringsmail har skickats till den angivna adressen. Användaren uppmanas sedan att följa de anvisningar som finns i mailet för att aktivera sitt konto och göra det möjligt att logga in i systemet. Bild 3.5 Denna sida meddelar kunden att ett verifikations mail har skickats till användarens mail adress MainPage Efter inloggning i systemet kommer användaren till denna sida, se bild 3.6. Här finns valen att köpa kredit till sitt SIM-Kort eller att ändra sina användaruppgifter. En välkomsttext visar vem som är inloggad på sidan. Bild 3.6 MainPage med designen implementerad är sidan som låter kunden välja vad denne vill göra härnäst.

23 3.7.4 Activation I aktiveringsmailet så får kunden med en länk till denna sida, se bild 3.7, tillsammans med en så kallad QueryString för att aktivera sitt konto. Med querystring menas att information som sedan kan hämtas av den berörda sidan skickas med i adressen. I vårt fall så skickades användarens namn och angivna telefonnummer som angavs vid registreringen med på följande sätt: Argumenten namn och telefonnummer används sedan i Activation för att hitta användaren i databasen och aktivera dennes konto. Detta görs enkelt genom att sätta användarens värde under validatedaccount i Customer tabellen till 1. Vi har under konstruktionen av verifications mail funderat på vad som kommer hända om någon skulle ändra sin mottagna verifikations adress till att aktivera någon annans konto. Detta skulle kunna vara möjligt genom att man ändrar det angivna namnet på querystring. Vi beslutade oss för att detta inte skulle kunna påverka säkerheten då aktivering av någon annans konto inte ger något upphov till intrång. Efter att detta gjorts så meddelas användaren om att dennes konto nu är aktiverat och att det nu går att logga in på kundens personliga sida. Bild 3.7 Activation sidan visar för kunden att konto har blivit aktiverat.

24 3.7.6 ChangeCustomerInfo Användaren har på denna sidan, se bild 3.8, möjlighet att ändra alla sina kontouppgifter förutom telefonnummer, PIN-kod och användarnamn som är fasta. På sidan visas alla kundens nuvarande uppgifter och även ett ifyllningsformulär med de nuvarande värdena redan ifyllda. Det är i formuläret kunden kan ändra sina uppgifter genom att ändra på de redan ifyllda uppgifterna. Det finns en rad olika kontroller som utförs beroende på ändring i formuläret. Alla fält kontrolleras så att de inte är tomma. Ändras lösenord så görs en kontroll om lösenorden överstämmer med varandra och även så att lösenordet är längre än fem tecken. E- mailet kontrolleras så att det inte redan finns en kund som är registrerad på detta mail. För att ändringarna ska gå igenom måste det nuvarande lösenordet uppges. När kunden angivit den information denne önskar ändra kontrolleras denna efter fel och om allt skrivits in korrekt så uppdateras informationen i databasen. Om någon angiven information var felaktig meddelas kunden om vilken information som behöver skrivas om. Bild 3.8 ChangeCustomerInfo med design implementerad låter kunden ändra sina sparade uppgifter.

25 3.7.7 BuyCredit När användaren vid MainPage väljer att köpa krediter kommer användaren till denna sida, se bild 3.9. Här får användaren välja den summa pengar som han önskar sätta in på sitt konto och i vilken valuta samt vilket telefonnummer som krediterna skall läggas till på. För närvarande så kan användaren bara välja att fylla på sitt kort med svenska kronor, euro eller amerikanska dollar men fler valutor kommer att läggas till vid vidareutveckling av webbsidan. Användaren väljer lätt vilken valuta och summan med hjälp av så kallade Drop down boxar med de fördefinierade alternativen. När användaren specificerat sina val så går han vidare genom att cka på knappen Next. Det som sker härefter är att det så kallade Payment Session Request anropet som finns beskrivet tidigare i denna rapport görs till PayNova. Användaren skickas sedan vidare till PayNova Web service sidorna där information så som kreditkortsnummer skall anges. Bild 3.9 BuyCredit med design implementerad låter kunden välja valuta, telefonkort och mängd kredit som ska fyllas på.

26 3.7.8 OrderComplete Då betalningen och överföringen av pengar har genomförts utan problem kommer denna sida att laddas, se bild Vid laddning kommer ett anrop att göras mot CallKey. Sidan anropar då en Agentmetod som fyller på redan betald kredit till kunder som hör till denne Agent. Detta anrop skickas via XML med POST och svaret tillbaka kan hämtas med ett metodanrop. För att implementera CallKey API har vi inkluderat webbreferenser i projektet och dessa ger oss tillgång till alla metoder som API har till förfogande. Efter att kunden har fått krediten insatt på sitt kort kommer sidan upp, se bild 7.10 som meddelar kunden om att överföringen har skett utan problem. Om något fel skulle uppstå vid detta läge kommer kunden att meddelas genom ErrorPage. Det är då upp till administratören att kontrollera vad som gick fel och att åtgärda problemet. Vi har diskuterat att denna typ av fel ska skicka ett automatiskt mail till administratören och meddela kunden om detta så att denne inte behöver oroa sig om att pengarna gått förlorade. Bild 3.10 OrderComplete sidan visar kunden att betalningen gått igenom och att påfyllningen till kortet har gjorts.

27 3.7.9 ErrorPage Om något fel skulle ske under körning av vårt system så kommer användaren att dirigeras om till denna sida, se bild Här får användaren information om vad felet består av och orsaker bakom detta. Exempel på fel som kan inträffa är att databasen eller någon av de externa delarna i systemet inte är tillgängliga för tillfället. Denna sida är även tänkt att fungera som en meddelandeservice till administratören vid mer allvarliga fel såsom att kunden inte fått telefonkortet laddat med kredit eller att PayNova inte svarar på anrop. Bild Denna sida är ErrorPage och visas för kunden om ett fel skulle uppstå.

28 4. Slutsats I systemutveckling finns det en generell modell för hur ett projekt av denna typ ska läggas upp. I början av projektet ska man samla på sig krav för produkten och sedan ska dessa krav analyseras. Efter analysen kommer designen av produkten och det är här en visuell bild över hur produkten kommer att vara uppbyggd ges. När designen är slutförd kan implementering ta sin början för att följas av testning. Denna modell fungerade bra för oss i början av projektet då vi samlade på oss krav och analyserade dessa då vi tidigare under vår utbildning har lärt oss metoder för att göra detta. När vi skulle börja med att designa och implementera webbplatsen kom vi till vårt första hinder vilket var att vi aldrig tidigare jobbat med webbapplikationer. Detta medförde att en del av tiden som skulle ha ägnats åt implementering istället spenderades på att lära oss om de väsentliga bitarna i en webbapplikation i.net miljön. Detta visade sig inte vara alldeles för olikt den vanliga C# programmeringen och arbetet kunde fortsätta utan större problem. Då mycket under projektets gång var nytt för oss har projektet inte kunnat följa den generella modellen utan produkten och planeringen har kommit till när förståelse för nästa steg har erhållits. Denna arbetsstruktur var kanske inte optimal eftersom det ibland var väldigt svårt att veta om man utfört ett steg korrekt innan man byggt på med nästa steg. Detta ledde i sin tur till att en hel del av arbetstiden gick åt för att i efterhand gå tillbaka för att göra ändringar och korrigeringar i kod som skrivigts i tidigare under arbetets gång. Vi märkte också att detta lätt kunde leda till förvirringar gällande vad i koden som behövde ändras. Ett annat problem som var en följd av detta arbetssätt var att kodens struktur blev väldigt rörig eftersom den gått igenom så många olika ändringar och korrigeringar. För att minska detta problem försökte vi använda vi oss av kommentarer i koden vid viktiga stycken för att få en bättre överblick. Ett annat av hinderna som stöttes på var försening av de olika API konton som vi behövde för att implementera systemet. PayNova testkonto fick vi dock efter en liten försening och kunde börja implementera betalningen av krediten. Vid den preliminära rapportskrivningen saknades CallKey kontot och ingen implementering kunde göras för att fylla på kundens kredit på SIM kortet. Nu i efterhand har kontot till CallKey tillkommit och implementeringen har slutförts utan några större hinder.

29 5. Referenser Glyn Edmunds,( 2006 ). CallPlex Agent Release V1.0 Additions. CallKey Group Ltd. Glyn Edmunds,( 2006 ). CallPlex Customer Interface guide 2.1. CallKey Group Ltd. < PayNova, (2007). Technical Description and Implementation Manual Paynova 3.0 <

30 Bilaga A källkod för Inteli3 Roaming Plattform Denna kod är främst avsedd till att studera strukturen på implementeringen. Då Webbapplikationen inte är fullständig kommer mer information tillkomma till denna bilaga. Comments in this color. Methods in this color. MainPage.aspx.cs using System; using System.Data; using System.Configuration; using System.Collections; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; using System.Xml; using System.Text; using System.Collections.Generic; using System.Net; using System.IO; using com.callkey.www; using System.Data.SqlClient; using System.Security.Cryptography; public partial class _Default : System.Web.UI.Page SqlConnection Conn = new SqlConnection("user id=" + ConfigurationManager.AppSettings["sqlloginname"].ToString() + ";" + "password=" + ConfigurationManager.AppSettings["sqlloginpass"].ToString() + ";" + "server=" + ConfigurationManager.AppSettings["databaseIP"].ToString() + ";" + "Trusted_Connection=no;" + "database=transaction; " + "connection timeout=5"); protected void Page_Load(object sender, EventArgs e) String custid = ""; custid = Session["ID"].ToString(); catch (WebException f) Session["Error"] = "-2"; SqlDataReader myreader = null; SqlCommand mycommand = new SqlCommand("select UserName, , FullName from Customer WHERE ID = " + custid, Conn);//lägg til Limit 1 myreader = mycommand.executereader(); while (myreader.read()) WelcomeLabel.Text = "Användare: " + myreader["username"].tostring(); Session["Name"] = myreader["username"].tostring(); Session[" "] = myreader[" "].tostring(); Session["FullName"] = myreader["fullname"].tostring();

31 myreader.close(); catch (SqlException f) Session["Error"] = "-2"; catch (System.Web.HttpException) Session["Error"] = "-2"; finally protected void Button1_Click(object sender, ImageClickEventArgs e) Response.Redirect("ChangeCustomerInformation.aspx"); catch (System.Web.HttpCompileException) Session["Error"] = "-2"; protected void Button2_Click(object sender, ImageClickEventArgs e) Response.Redirect("BuyCredit.aspx"); catch (System.Web.HttpCompileException) Session["Error"] = "-2"; protected void Button3_Click(object sender, ImageClickEventArgs e) string custid = Session["ID"].ToString(); String token = ""; String PhoneNR = ""; String PinNr = ""; SqlDataReader myreader = null; SqlCommand mycommand = new SqlCommand("select PhoneNr, PinNr from Phones WHERE CustomerID = " + custid, Conn); myreader = mycommand.executereader(); while (myreader.read()) PhoneNR = myreader["phonenr"].tostring(); PinNr = myreader["pinnr"].tostring(); myreader.close(); catch (SqlException f) Session["Error"] = "-1"; finally

32 String param = "Username=" + PhoneNR + "&Password=" + PinNr + "&Targetuser=" + PhoneNR; HttpWebRequest Request = (HttpWebRequest)WebRequest.Create(" Request.ContentLength = param.length; Request.Method = "POST"; Request.ContentType = "application/x-www-form-urlencoded"; StreamWriter stout = new StreamWriter(Request.GetRequestStream(), System.Text.Encoding.ASCII); stout.write(param); stout.close(); StreamReader stin = new StreamReader(Request.GetResponse().GetResponseStream()); XmlTextReader reader = new XmlTextReader(stIn); while (reader.read()) if (reader.nodetype == XmlNodeType.Element) // The node is an element. if (reader.name == "token") reader.read(); token = reader.value; if (reader.name == "error") reader.read(); stin.close(); catch (System.Exception f) String exept = f.tostring(); Session["Error"] = "-2"; String url =" + PhoneNR + "&_authtoken=" + token; Response.Write("<script>window.open('" + url + "');</script>");

33 FirstPage.aspx.cs using System; using System.Data; using System.Configuration; using System.Collections; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; using System.Web.SessionState; using System.Xml; using System.Text; using System.Collections.Generic; using System.Net; using System.IO; using System.Data.SqlClient; using System.Security.Cryptography; public partial class _Default : System.Web.UI.Page SqlConnection Conn = null; byte[] data = new byte[32]; MD5 md5 = new MD5CryptoServiceProvider(); System.Text.ASCIIEncoding encoding = new System.Text.ASCIIEncoding(); protected void Page_Load(object sender, EventArgs e) Conn = new SqlConnection("user id=" + ConfigurationManager.AppSettings["sqlloginname"].ToString() + ";" + "password=" + ConfigurationManager.AppSettings["sqlloginpass"].ToString() + ";" + "server="+ ConfigurationManager.AppSettings["databaseIP"].ToString() + ";" + "Trusted_Connection=no;" + "database=transaction; " + "connection timeout=5"); protected void Button1_Click(object sender, ImageClickEventArgs e) String EnteredPass = ""; SqlDataReader myreader = null; SqlCommand mycommand = new SqlCommand("select UserName, Password, verifiedaccount, ID, , FullName from Customer WHERE UserName Conn);// hämta bara användaren som överstämmer emd inskriven username mycommand.parameters.addwithvalue("@username", LoginUserName.Text.ToString()); myreader = mycommand.executereader(); while (myreader.read()) String Name = myreader["username"].tostring(); String Pass = myreader["password"].tostring(); String activated = myreader["verifiedaccount"].tostring(); String CustID = myreader["id"].tostring(); String = myreader[" "].tostring(); String fullname = myreader["fullname"].tostring(); data = encoding.getbytes(loginpassword.text.tostring()); byte[] result = md5.computehash(data); // EnteredPass = encoding.getstring(result); StringBuilder base16hash = new StringBuilder(); for (int i = 0; i < result.length; i++) base16hash.append(result[i].tostring("x2"));