Institutionen för datavetenskap

Institutionen för datavetenskap Department of Computer and Information Science Examensarbete Utvärdering av inläsning av XML-kontra flatfiler av Mathias Pettersson LIU-IDA/LITH-EX-G--12/028--SE 2012-11-23 Linköpings universitet SE-581 83 Linköping, Sweden Linköpings universitet 581 83 Linköping

Utvärdering av inläsning av XML- kontra flatfiler Av: 2012-11- 23 Handledare: Björn Eklund Skatteverket Visby Examinator: Patrick Lambrix Linköpings Universitet

Sammanfattning Examensarbetet har utförts på Skatteverkets kontor i Visby. Eftersom Skatteverket arbetar med ett befintligt projekt som medför en kommande förändring på filformatet från flatfil till XML- fil så fanns en oro över att det nya formatet skulle medföra prestandaproblem. Därför ville Skatteverket göra en utvärdering på inläsningen från filformaten till en databas med fokus på prestanda men även andra kvalitetskriterier. Målet med examensarbetet var att jämföra inläsningen av de olika filformaten där systemet skulle klara av hundratals till hundratusentals kontrolluppgifter för att sedan sammanställa resultatet av jämförelsen i en rapport. För att arbetet skulle kunna utföras så behövdes en lokal utvecklings- och testmiljö installeras. Testdata behövde även tas fram för att kunna utföra utvärderingen. Slutsatsen blev inte helt oväntat att flatfilsformatet är snabbare att läsa av än XML- formatet. Detta grundar sig i att XML- formatet innehåller betydligt fler tecken än flatfilsformatet. Flatfilsparsern var i genomsnitt 29% snabbare än XML- parsern i de fallen då ett hundratal kontrolluppgifter till flera hundratusentals parsades. Resultatet var dock mer oväntat då skillnaden i filstorlek mellan formaten förhöll sig konstant runt 80% för samma antal kontrolluppgifter. I min mening tycker jag att skillnaden i berarbetningstid och filstorlek borde ha varit mer jämna procentuellt. En graf med bearbetningstiderna finns att se i rapporten. Resultatet blev fyra stycken Eclipse- projekt på totalt 2988 rader kod. XML- parsern som valdes för utvärderingen var SAX- parsern, vilket var den mest lämpade parsern då den strömmar inläsningen av XML- dokument och håller därför en låg minnesanvändning. Flatfilsparsern var lite knepigare, då det inte fanns en färdig parser att tillgå som var anpassat efter formatet, därför var jag tvungen att skriva en egen parser för Skatteverkets format. Detta går att läsa mer om i rapporten. UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER I

Innehållsförteckning II UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER 1 Inledning... 1 1.1 Bakgrund till examensarbetet... 1 1.1.1 Krav... 1 1.2 Motivering... 1 1.3 Syfte... 1 1.4 Frågeställning... 2 1.5 Avgränsningar... 2 1.6 Målgrupp... 2 1.7 Språkbruk... 3 1.8 Rapportens struktur... 3 2 Bakgrund... 4 2.1 XML... 4 2.2 Flatfiler... 4 3 Teori... 6 3.1 Programspråk & tekniker... 6 3.1.1 Java... 6 3.1.2 XML parser... 6 3.1.2.1 SAX (Simple API for XML)... 6 3.1.2.2 DOM (Document Object Model)... 6 3.1.2.3 StAX (Streaming API for XML)... 7 3.1.3 Flatfilsparser... 7 3.1.4 JPA (Java Persistence API)... 7 3.1.5 JAXB (Java Architecture for XML Binding)... 7 3.2 Databasdesign... 7 3.3 Testning... 7 3.3.1 Beteendetestning (Black box testing)... 8 3.3.2 Glasboxstest (White box testing)... 8 3.3.3 Enhetstest (Unit testing)... 8 3.3.4 Lasttest (Load testing)... 8 3.3.5 Acceptanstest (Acceptance testing)... 8 3.4 Användbarhet... 8 3.5 Prestanda... 8

3.6 Utvecklingsmiljö... 8 3.6.1 IDE- program... 8 3.6.2 Databas... 9 4 Metod... 10 4.1 Utvecklingsmetod... 10 4.1.1 Milstolpar... 10 4.1.2 Agil utveckling... 10 4.1.3 Mitt arbete... 10 4.2 Testning... 11 4.3 Utvecklingsmiljö... 11 4.3.1 Rational Rose... 11 4.3.2 Apache Ant... 11 4.3.3 Eclipse IDE- mjukvaruutvecklings- verktyg... 12 4.3.4 Databas... 12 4.3.5 Oracle WLS... 12 4.4 Tekniker... 12 4.4.1 JAXB... 12 4.4.2 SAX- XML parser... 13 4.4.3 Flatfils- parser... 13 4.4.4 JPA... 13 5 Resultat... 15 5.1 Arbetsförlopp... 15 5.1.1 Generering av testdata... 15 5.1.1.1 XML- dokument... 15 5.1.1.2 Flatfil... 15 5.1.2 Parsning av filformat... 15 5.1.2.1 Parsning av XML fil... 15 5.1.2.2 Parsning av flatfil... 15 5.1.3 Prestandajämförelse... 16 5.1.3.1 Sammanställning av prestandajämförelse... 16 5.2 Användargränssnitt... 16 5.3 Databasstruktur... 17 5.4 Programkod... 17 5.4.1 Statistik... 17 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER III

5.5 Prestandamätning... 18 6 Slutsats och diskussion... 19 6.1 Egen reflektion och diskussion... 19 6.1.1 Fortsatt arbete... 20 6.2 Slutsats... 20 7 Referenser... 22 8 Bilagor... 23 8.1 Kontrolluppgifter... 23 8.1.1 XML- format... 23 8.1.2 Flatfilsformat... 25 IV UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

1 Inledning 1.1 Bakgrund till examensarbetet Skatteverkets IT- avdelning jobbar med utveckling, drift, förvaltning och underhåll av Skatteverkets och Kronofogdens IT- system. Uppdragen kommer från Skatteverkets huvudkontor. Större delen av verksamheten finns i Solna, samt på orterna Göteborg, Umeå, Visby, Västerås och Östersund. Kontoret i Visby är uppdelat i två sektioner och har ca 50 medarbetare. Arbetsuppgifterna är uppdelade i domäner, en datawarehousedomän samt en javadomän. I javadomänen utvecklas allt från infrastrukturella komponenter till Figur 1: Skatteverket är en statlig myndighet i Sverige handläggningsstöd och applikationer avsedda för Skatteverkets externa webbplats. Examensarbetet blev därför placerat i javadomänen. På uppdrag av Skatteverkets kontor i Visby så behövdes en utvärdering på inläsningen av filformaten XML kontra flatfil innehållandes kontrolluppgifter till en databas. Källan till arbetet var att den danska motsvarigheten till Skatteverket hade pekat på att de tvingats gå från XML- format till förmån för flatfiler p.g.a. prestandaproblem med XML- filer. Då Skatteverket ska införa liknande funktionalitet så ville de säkerställa att XML- formatet i sig inte skulle vara något problem. 1.1.1 Krav Installation av lokal test/utvecklingsmiljö. Testdata skulle tas fram. Stöd för kontrolluppgiftsfiler innehållandes hundratals till hundratusentals kontrolluppgifter. En rapport där IT- miljön beskrivs samt de utvärderade teknikerna. En testbilaga med bearbetningstider och diagram under olika laster. 1.2 Motivering På grund av en kommande formatändring från flatfil till XML fil i ett befintligt projekt hos Skattekontoret i Visby så fanns det oro för eventuella prestandaförsämringar, då den danska motsvarigheten till Skatteverket pekade på detta. Därför var det viktigt för dem att göra en utvärdering som påvisar olikheter i en prestandajämförelse mellan de två olika filformaten. 1.3 Syfte Syftet med examensarbetet var att göra en utvärdering på inläsning av de olika filformaten XML kontra flatfil till en databas. Filerna innehöll kontrolluppgifter 10

(KU10) från arbetsgivare m.fl. Detta skulle göras för att påvisa olikheter och eventuella fördelar och nackdelar mellan de olika filformaten, så som prestanda och andra kvalitetskriterier. Testdata skulle tas fram för att kunna göra flera mätningar på olika laster om hundratals till hundratusentals kontrolluppgifter. Resultaten från testkörningarna skulle sammanställas i en testbilaga med grafer och diagram som visar skillnaden i bearbetningstid för olika antal kontrolluppgifter, om hundratals till hundratusentals. 1.4 Frågeställning Finns det någon teknik att generera XML dokument i Java eller hur gör man det enklast? För att förenkla och abstrahera arbetet så är det en viktig fråga. Vilka olika parsningstekniker finns det för att traversera de olika filformaten och vilken metod lämpar sig bäst för arbetet? Eftersom fokus främst låg på prestanda var det viktigt att hitta den tekniken som var snabbast. Eftersom antalet kontrolluppgifter kunde vara hundratusentals som mest så var det även viktigt att hitta den teknik som klarade av att hantera stora mängder för att hålla prestandan uppe. Finns det något bra sätt att hantera databasanslutningen på? Då inläsningen av kontrolluppgifter skulle ske till en databas så ansåg jag det viktigt att hitta ett bra sätt att hantera anslutningen och innehållet i databasen på. Hur stor är storleksskillnaden mellan filformaten och hur mycket påverkar det bearbetningstiden? Eftersom XML filen innehåller betydligt fler tecken än flatfilen så borde storleken vara markant. Det kan även vara av intresse att se om storleken ökar linjärt med antalet kontrolluppgifter. Kommer bearbetningstiden öka sekventiellt med antalet kontrolluppgifter? Då storleken ökar med antalet kontrolluppgifter så ökar även bearbetningstiden. Det kan därför vara av intresse att veta om bearbetningstiden ökar linjärt. 1.5 Avgränsningar Utvärderingen använder programspråket Java med en SQL databas från Oracle. Allt ska köras på en dator vilket Skatteverket tillhandahåller. Arbetet ska integreras med Skatteverkets säkerhetsbibliotek för att det ska kunna köras säkert på en WLS från Oracle. Resultat sammanställs i ett Excelldokument med grafer som påvisar skillnader, om för och nackdelar mellan de två filformaten. 1.6 Målgrupp Den här rapporten är riktad till studenter med datautbildning inom programmering på kandidatnivå eller personer med förståelse och intresse för programmering. 2 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

1.7 Språkbruk KU - Kontrolluppgift 10, kontrolluppgift från arbetsgivare m.fl. JPA - Java Percistence API, ett ramverk för att hantera relationsdata mellan objekt. JAXB - Java Architecture for XML Binding, "mappar" Java- klasser till XML representationer. SQL - Ett standardiserat språk för att hämta och modifiera data i en relationsdatabas. WLS - Web Logic Server, en Java web applikationsserver från Oracle. Entitet - Ett objekt/tabell i en databas. Parser (tolk) - tolkar strängar av symboler (indata) enligt regler i en formell grammatik. Kommandorad - När jag skriver kommandorad så syftar jag på raden i ett terminalfönster där olika kommandon kan skrivas in för att kommunicera med olika program. GUI - Graphical User Interface, eller på svenska: grafiska användargränssnitt. XML - Extensible Markup Language, ett märkspråk (engelska: markup language). XML dokument används för att strukturera data. Element - Ett XML- dokument är i grunden uppbyggt av element. Ett element består vanligtvis av en start- och en sluttagg och kan ha olika attribut och innehåll. Flatfil - Har samma funktion som ett XML- dokument. Syntaxen/strukturen däremot bestäms självt. JAR - Java Archive, Är ett arkivformat för att hålla samman många Java- klassfiler, metadata och andra resurser i en och samma fil. Tråd - (programtråd) Används för att utföra saker samtidigt. kb - kilobyte, måttenhet. 1 kb motsvarar 1024 bytes (2^10). ms - millisekunder, på en sekund går det 1000 millisekunder. 1.8 Rapportens struktur Den här rapporten sammanfattar examensarbetet för på Skatteverkets kontor i Visby under våren 2012. Rapporten är uppdelad i åtta kapitel. Rapportens första kapitel är inledningen med bakgrunden, syftet och avgränsningar till examensarbetet. Andra kapitlet är lite bakgrundsfakta om filformaten då exjobbet behandlar detta. Tredje kapitlet innehåller teorier som ligger bakom examensarbetet som kan vara bra att känna till. Det fjärde kapitlet handlar om metoder som jag använt under arbetet. Femte kapitlet innehåller resultaten för arbetet och kapitel sex en slutsats och diskussion kring arbetet. Det sjunde kapitlet innehåller de referenser som jag har använt för rapporten och examensarbetet. Åttonde och sista kapitlet innehåller bilagor till rapporten.

2 Bakgrund För att reda ut några begrepp och tekniker som jag har använt eller kommit i kontakt med i examensarbetet så har jag valt att beskriva det här för att förståelsen för rapporten ska ökas och läsaren ska ha lättare att hänga med. 2.1 XML Extensible Markup Language (XML) är ett så kallat märkspråk vars syfte är att kunna utväxla data mellan olika informationssystem. XML dokument innehåller data som beskrivs direkt i dokumentet till skillnad från flatfiler som endast brukar innehålla data. Ett XML- dokument är i grunden uppbyggt av element. Ett element består vanligtvis av en start- och en sluttagg och kan ha olika attribut och innehåll. Genom att kombinera ett flertal element med valfria attribut kan olika information beskrivas. Följande exempel är en beskrivning på en kontrolluppgift med lite persondata: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <?xml version="1.0" encoding="iso- 8859-1" standalone="yes"?> <!- - Deklarerar att det är en XML- fil med teckenkodning iso- 8859-1 - - >... <Kontrolluppgift> <!- - Kontrolluppgift är ett element i rotelementet Manadsuppgift - - > <Inkomsttagare> <!- - En inkomsttagare/persondata- - > <!- - ns2: är ett "namespace", vilket används för att lösa namnkonflikter - - > <ns2:adress> <ns2:gatuadress>skatteverket 1</ns2:Gatuadress> <ns2:postnr>62123</ns2:postnr> <ns2:postort>visby</ns2:postort> </ns2:adress> <Fornamn>John1</Fornamn> <Efternamn>Doe</Efternamn> <Personnr>500101-0015</Personnr> <Orgnr></Orgnr> </Inkomsttagare> <!- - Slut på elementet persondata - - >... 2.2 Flatfiler Flatfiler innehåller ren text vars syfte är samma som XML- dokument. Strukturen på dessa skiljer sig dock då flatfiler oftast innehåller en post per rad. Det finns ingen förutbestämd struktur på hur en flatfil ska se ut, utan detta bestäms av skaparen. Inom en post så kan flera fält finnas, vilka kan vara separerade med något sorts tecken (vanligtvis kommatecken), men inte i detta fall då det handlar om nyckelord som t.ex. "#NAMN". 4 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

Följande är en del ur en flatfil där en kontrolluppgift beskrivs precis som i exemplet för XML: 1 2 3 4 5 6 7 8 9 10 11 12... #POST_START KU10 #PERSONNR 195001010015 #NAMN Doe John1 #ADRESS Skatteverket 1 #POSTORT Visby #POSTNR 62123......... #POST_SLUT KU10...

3 Teori Inom examensarbetet så har jag behövt använda en del tekniker och program för att kunna utföra arbetet. Därför har jag varit tvungen att göra vissa jämförelser mellan dem för att välja det som jag anser lämpar sig bäst för uppgiften. Jag tänkte därför ge lite bakgrund till allt i detta kapitel och där jag även beskriver hur jag har tänkt. 3.1 Programspråk & tekniker Programmeringsspråket ska väljas efter uppgiften. Vilket språk eller vilken teknik som bäst lämpar sig för arbetet kan vara det som har bredast urval av funktioner som kan användas under arbetets gång, eller det som är enklast att använda men kanske inte är så optimerat. Jag kommer här gå igenom några programspråk och tekniker som jag har tittat på och ge lite bakgrund om dem. 3.1.1 Java Java är ett objektorienterat programspråk som presenterades för världen år 1995. Java är ett plattformsoberoende språk som har många användningsområden, som t.ex. programapplikationer i detta fall. Nedan presenterar jag olika fördelar och inbyggda funktioner som Java tillhandahåller vilket jag använt mig av i mitt arbete. 3.1.2 XML parser Eftersom XML filer innehåller betydligt fler tecken än en flatfil så behövdes en snabb XML parser som inte höll så mycket data i minnet då systemet kunde bli segt om flera hundratusentals kontrolluppgifter skulle hanteras. Jag kom fram till att följande XML parsers fanns att tillgå i Java: SAX, DOM och StAX. 3.1.2.1 SAX (Simple API for XML) En SAX- parser skapar inte någon intern struktur av XML dokumentet utan istället tar den påträffandet av olika komponenter som event och talar om för klienten vad den läser under tiden den läser. Eftersom SAX- parsern inte skapar någon intern struktur så är den mycket minneseffektiv vid stora XML dokument. Parsern är också generellt snabbare och lättare att lära sig än DOM- parsern, dock så blir det mer för programmeraren att hålla reda på då denne måste ta hand om all data som kommer och skapa sin egen struktur. 3.1.2.2 DOM (Document Object Model) DOM- parsern bygger s.k. DOM- träd från XML dokument och sparar det i minnet. Fördelen med DOM- träd är att det är enklare för programmeraren att ta ut och förändra de delar som behövs. DOM- parsern läser alltid in hela XML dokumentet oavsett hur mycket data som behövs. DOM- parsern är väldigt ineffektiv om XML dokumenten är stora eftersom hela trädet hålls i minnet. Eftersom det var som mest 500 000 kontrolluppgifter som fanns i ett XML dokument så fanns risken att systemets minne skulle ta slut. Därför ansåg jag att denna parser inte lämpade sig för arbetet. 6 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

3.1.2.3 StAX (Streaming API for XML) StAX parsern är en blandning mellan DOM och SAX parser där det går att välja antingen eller. Huvudingången för StAX är en filpekare som representerar positionen inom XML dokumentet. Applikationen flyttar sedan pekaren framåt och tar informationen som den behöver från parsern. 3.1.3 Flatfilsparser Eftersom flatfiler kan se lite olika ut så fanns det ingen direkt funktion som passade för att parsa de flatfiler jag hade till handa. Därför är alternativet att delvis läsa in filen (i s.k. "chunks") som programmeraren sedan får sålla ut data ur. Detta ansåg jag vara det mest effektiva sättet för att hålla prestandan uppe vid större flatfiler om hundratusentals kontrolluppgifter. 3.1.4 JPA (Java Persistence API) JPA är ett ramverk som används för att mappa s.k. entiteter i form av klasser i Java till en relationsdatabas. JPA förenklar därmed anslutningen och hanteringen av databasen då utvecklaren inte behöver bry sig speciellt om hur databasen ser ut då detta specificeras i JPA. 3.1.5 JAXB (Java Architecture for XML Binding) JAXB används för att mappa Java klasser till XML representationer. Detta förenklar uppbyggnaden av XML filer som skulle genereras som testdata då jag slapp bygga en egen funktion som skulle utföra samma sak. JAXB tar ett XML- schema och genererar objekt utifrån elementen i det. XML- schemat används senare för att validera att alla obligatoriska objekt finns med för att generera ett XML- dokument. 3.2 Databasdesign Databasen ska ha tydliga och strukturerade relationer så den är lätt att följa, med så tydliga entiteter med så hög normalform som möjligt på databasstrukturen. Med databasnormalisering menas att systematiskt för varje normalform (1NF och uppåt) stegvis minska redundans och beroenden i databasen. Databasdesignen är enkel i detta fall, då detta specificeras och sköts av tidigare nämnt JPA, se 3.1.4. Endast en entitet kommer att existera i detta fall, vilket är "Kontrolluppgift" för båda filformaten, se utdraget av entiteten kontrolluppgift i kapitel 4.4.4. 3.3 Testning Testningen ska vara likvärdig mellan filformaten då samma antal kontrolluppgifter ska testas för varje filformat. Det är viktigt att testa ofta och så mycket som möjligt då det kommer att förenkla arbetet och undvika eventuellt onödiga fel. Det är bra att använda olika testmetoder för att få olika synvinklar på programmet så det blir lättare att komma fram till ett bra resultat från början. Nedan följer olika testmetoder som jag kommit fram till att jag tycker är bra och passar in på arbetsuppgiften.

8 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER 3.3.1 Beteendetestning (Black box testing) Den som testar känner endast till vad mjukvaran förväntas göra och inte hur programmet fungerar. Det viktiga här är att programmet ger rätt utdata i förhållande till vad som kommer in. Denna metod är bra eftersom bl.a. saknade funktioner, fel i gränssnittet eller beteendefel uppdagas. 3.3.2 Glasboxstest (White box testing) Testaren har tillgång till programkoden. Denna testmetod är bra för den garanterar att alla oberoende vägar/möjligheter har exekverats minst en gång. En risk med denna metod är att testerna kan anpassas för att matcha kodens funktion. 3.3.3 Enhetstest (Unit testing) Utförs generellt av programmeraren. Denna metod brukar ske fortlöpande i takt med att arbetet fortlöper. 3.3.4 Lasttest (Load testing) En metod för att testa hur systemet beter sig under större/tyngre laster. 3.3.5 Acceptanstest (Acceptance testing) Används normalt för att verifiera om systemet möter kundens krav. Detta sköts normalt av kunden. 3.4 Användbarhet Användbarheten är av stort fokus. Projektet ska kunna användas och vidareutvecklas efter min tid på Skatteverket. Klasser och projekt ska vara tydligt uppdelade med lämpliga namn som beskriver dess innebörd. Att uppnå en hög abstraktionsnivå är bra, då programmeraren kan dölja mer komplicerade lösningar i konkreta modeller eller användargränssnitt. 3.5 Prestanda Prestanda var något som var väldigt viktigt för examensarbetet, därför gick mycket av tiden åt till att forska i hur stor mängd data som kan läsas in i taget för att hålla en så bra prestanda som möjligt, då antalet kontrolluppgifter kunde variera från hundratals till hundratusentals. Prestanda är något som är viktigt i dagens läge. Därför var det viktigt att hitta de teknikerna och Java- biblioteken som fungerade bäst och gav bäst resultat vid inläsning av filformaten till databasen. Därför jämförde jag bland annat några olika tekniker för att läsa XML- dokument, men även olika sätt att läsa in flatfiler, se tidigare kapitel 3.1.2 samt 3.1.3. 3.6 Utvecklingsmiljö Utvecklingsmiljön är väl kanske något av de viktigaste områden för att ett programmeringsarbete ska kunna utföras. För att arbetet skulle kunna utföras så behövdes vissa program och verktyg vara installerat i utvecklingsmiljön. 3.6.1 IDE- program Då arbetet skulle skrivas i Java och var ganska omfattande så rekommenderar jag att använda ett väl utvecklat IDE- program som är anpassat efter detta.

Ett IDE- program (integrerad utvecklingsmiljö) innehåller textredigerare, kompilator och debugger. Bra exempel på dessa är Eclipse och NetBeans som båda har stöd för programspråket Java. 3.6.2 Databas Då kontrolluppgifterna ska skrivas till en databas så finns det lite olika valmöjligheter som t.ex. Oracles gratisalternativ Oracle Database Express eller MySQL som är helt gratis. Båda alternativen är databaser som använder frågespråket SQL, så det är mest en smaksak eller vad man är van att använda som spelar in.

4 Metod 4.1 Utvecklingsmetod Under arbetet har jag valt att utveckla agilt med tio grovplanerade sprints/milstolpar som definierades i tidsplaneringen vilket reflekterade de veckor som examensarbetet var inplanerat på. 4.1.1 Milstolpar Vecka 1 Planeringsrapport skrivs. Installation av test- och utvecklingsmiljö påbörjas. Vecka 2 Studie av filformat som ska behandlas. Ett testskript för att generera (unika) poster för de olika filformaten som ska testas tas fram. Vecka 3 Forska i och testa vilka tekniker som lämpar sig för arbetet. Detta ska göras innan själva arbetet. Vecka 4-6(7) Implementation av de olika utvärderade teknikerna görs. Vecka (7- )8 Prestandamätning görs. Arbetet färdigställs och en rapport innehållande en beskrivning av systemet lämnas in till arbetsplatsen där olika fördelar påvisas för de tekniker som använts. En bilaga med olika tester under olika laster lämnas även in till Skatteverket. Vecka 9 Reflektionsdokument och rapport påbörjas. Vecka 10 Reflektionsdokument och rapport. 4.1.2 Agil utveckling Syftet med agil utveckling är att kunden hela tiden är nöjd med vad som utvecklas. Detta sker genom ett mycket nära samarbete och öppenhet under hela utvecklingstiden med täta regelbundna möten mellan utvecklare och kund. Utvecklingen sker iterativt vilket medför att många små delleveranser sker. Detta ger hela tiden en chans till utvärdering av systemet och kan därför lättare ändras för att möta nya krav och önskemål. 4.1.3 Mitt arbete Då jag arbetade ganska tätt intill mina två handledare Björn Eklund och Gert Lundin så hade jag en naturligt daglig kommunikation med dem om mitt arbete. Därför talade jag ofta om hur jag låg till och vad jag höll på med för stunden och där av fick jag en naturlig feedback (daily communication). Då jag hela tiden utvecklade fortlöpande så höll jag arbetet enkelt utan alltför komplicerade lösningar. Jag lämnade även många små delleveranser utav systemet. Detta för att ge rum för eventuellt plötsliga förändringar eller önskemål som skulle kunna uppstå. 10 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

Mot arbetets slut så förfinade jag och snyggade till koden samt dokumenterade systemet så det blev mer lätthanterligt att använda och vidareutveckla i framtiden. 4.2 Testning Testning av systemet har hela tiden skett fortlöpande i takt med alla små delleveranser som jag levererade. Jag testade hela tiden att systemet fungerade som förväntat innan jag gick vidare till nästa del. Inga testfall skrevs för systemet då bland annat JAXB som genererar XML- dokument utifrån ett XML- schema som jag tillhandahöll från Skatteverket validerar att XML- dokumentet är korrekt utifrån schemat innan filen skapas. Sedan var det även svårt att validera tidsåtgången för bearbetning av KU- filerna som var en av de intressantaste aspekterna när det gällde prestandan för systemet, då det var det som skulle utvärderas. Det jag gjorde här var att notera tiden och föra in det i ett Exceldokument för de olika filformaten. Jag noterade även att rätt antal kontrolluppgifter hade skrivits till databasen för varje filformat efter varje mätning. De egentliga testerna som utfördes var generellt de som är beskrivna i kapitel 3.3 (bortsett från enhetstestet). Främst så kontrollerade jag hela tiden att systemet klarade av tyngre laster (lasttest, se kapitel 3.3.4), då det förekom vissa problem när många kontrolluppgifter skulle genereras eller parsas när antingen minnet tog slut eller att en "anslutnings- time- out" förekom till WLSen. Orsaken till time- outen var när många antal KU bearbetades och WLSen inte gav något svar inom en viss tidsram vilket var satt till 30 sekunder från början. Det jag gjorde för att lösa problemet var att sätta connection- time- out till 1800 sekunder (en halvtimme) så förekom inte problemet något mer. 4.3 Utvecklingsmiljö Nedan går jag igenom de program och verktyg som jag har använt mig utav i mitt arbete. 4.3.1 Rational Rose Rational Rose är ett objektorienterat UML designverktyg som är avsett för visuell modellering. Rose används för att skapa ramen för ett program genom att definiera klasser med attribut och metoder. Rose ger en bra överblick och grund på de klasser som ingår i projektet. Rose användes för att generera tomma Java- klasser som sedan implementerades med själva koden för parsningen för att tillslut publiceras på WLSen. 4.3.2 Apache Ant Ant är ett kommandoradsverktyg som används som byggstöd för mjukvaruutveckling. Ant använder s.k. byggfiler vilket är XML dokument som beskriver byggprocessen och beroenden. Byggstödet är speciellt framtaget för att användas till Javaprojekt. Ant är väldigt bekvämt att använda i större projekt som innefattar många källkodsfiler.

4.3.3 Eclipse IDE- mjukvaruutvecklings- verktyg Eclipse är ett IDE mjukvaruutvecklings- verktyg med stöd för många olika programmeringsspråk och plugins. Skatteverket använder Eclipse som utvecklingsmiljö i sina projekt och jag var mest bekant med programmet sedan tidigare så därför föll valet på att använda Eclipse. Figur 2: Eclipse är ett populärt IDE mjukvaruutvecklingsverktyg 4.3.4 Databas Då uppgiften var att utvärdera inläsningen av filformaten till en databas så behövdes en bra och stabil databas som klarar av ett högt tryck och att många frågor (queries) ställs till den samtidigt. Då Skatteverket använder programvara från Oracle så föll även valet där på att använda Oracles databas "Oracle Database Express" som har stöd för SQL och är gratis. Gränssnittet för att hantera databasen var inte något som jag satte mig in i så mycket då JPA (se 3.1.4) skötte det mesta. Men vid de tillfällen då jag behövde kontrollera något så använde jag kommandoraden för eventuella databasförfrågningar. 4.3.5 Oracle WLS En WLS, eller Web Logic Server används för att agera bl.a. Java EE applikationsserver som i detta fall. På WLSen så publicerade jag min huvudapplikation som parsade filformaten. Applikationen kommunicerade med en Oracle databas där informationen från filformaten hamnade. För att ansluta till applikationen på WLSen så byggs en klient som kan kommunicera med den. 4.4 Tekniker 4.4.1 JAXB När jag upptäckte JAXB (se, 3.1.5) så förenklade det en stor del av mitt arbete då jag besparades att skriva en egen funktion som gjorde precis samma sak. En fördel med JAXB är att den validerar XML- objekten mot XML- schemat innan den skapar XML- dokumentet. Nackdelen är att hela XML strukturen hålls i minnet tills dess att den skrivs till fil, vilket kan medföra att arbetsminnet som programmet är tilldelat kan ta slut ifall strukturen blir stor. Detta kan dock lösas enkelt på så vis att programmet tilldelas 12 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

mer minne, antingen via Eclipse eller genom kommandoraden när JAR- filen exekveras. 4.4.2 SAX- XML parser Med förmån till SAX- parserns låga minnesanvändning så valde jag att implementera SAX- parsern för systemet eftersom t.ex. DOM- parsern inte hade varit optimal då flera hundratusentals kontrolluppgifter skulle behandlas i värsta fall. En lösning med StAX parser gjordes också. Det var dock inget som fanns med i den slutgiltiga produkten då jag såg att SAX- parsen var snabbare än StAX- parsern vid en enklare jämförelse mellan dessa. 4.4.3 Flatfils- parser I och med att det inte fanns en inbyggd parser för flatfiler så valde jag att skriva en egen som läser in Skatteverkets flatfiler bitvis (i chunks). Dessa bitar delas upp med hjälp av separator- tecknet "#" och med nyckelord som beskriver vilket fält värdet tillhör. 4.4.4 JPA Jag valde att använda JPA för att hantera databasanslutningen till Oracle- databasen. Det var väldig smidigt på så sätt att jag inte behövde skriva några direkta databasförfrågningar utan JPA skötte allt åt mig. Ett utdrag på entiteten "Kontrolluppgift" som användes i arbetet är enligt följande: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 @Entity public class Kontrolluppgift implements Serializable { @Id @GeneratedValue private long id; @Column(unique = true) private String personnr; private String namn; private String adress; private String postort; private String postnr; private String ug;... public Kontrolluppgift() { super(); } public long getid() { return id; } public void setid(long id) { this.id = id; } public String getpersonnr() {

27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 } return personnr; } public void setpersonnr(string personnr) { this.personnr = personnr; } public String getnamn() { return namn; } public void setnamn(string namn) { this.namn = namn; } public String getadress() { return adress; } public void setadress(string adress) { this.adress = adress; } public String getpostort() { return postort; } public void setpostort(string postort) { this.postort = postort; } public String getpostnr() { return postnr; } public void setpostnr(string postnr) { this.postnr = postnr; } public String getug() { return ug; } public void setug(string ug) { this.ug = ug; }... 14 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

5 Resultat 5.1 Arbetsförlopp Nedan beskriver jag hur upplägget av arbetsförloppet såg ut för examensarbetet. 5.1.1 Generering av testdata Första uppgiften för examensarbetet var att ta fram testdata i XML format samt flatfilsformat. Skatteverket tillhandahöll mallar för hur strukturen skulle se ut för båda dessa format. Testdatan som användes i utvärderingen genererades i de två filformaten och utgick från samma basklass för att vara så likvärdiga som möjligt så en rättvis prestandajämförelse kunde göras. Basklassen genererade unika personnummer och namn som hade en variabel som ökades med ett för varje ny kontrolluppgift. 5.1.1.1 XML- dokument För att generera XML dokumenten valde jag att använda mig av JAXB. Då jag hade fått ett färdigt XML- schema från Skatteverket så var denna process ganska snabbt avklarad. Nackdelen med JAXB var att hela strukturen hölls i minnet innan den skrevs ned till fil, vilket kunde resultera i att minnet tog slut om XML strukturen blev stor vid många KU. Detta löstes genom att tilldela Eclipse mer arbetsminne. Ett exempel på en kontrolluppgift i XML- format finns att se i kapitel 8.1.1. 5.1.1.2 Flatfil Flatfilen genererades rakt upp och ned enligt formatet som var förutbestämt från Skatteverket. Ett exempel på en kontrolluppgift i flatfilsformat finns att se i kapitel 8.1.2. 5.1.2 Parsning av filformat Efter att ha studerat olika tekniker för att parsa XML- och flatfiler så kom jag fram till följande. 5.1.2.1 Parsning av XML fil Som tidigare nämnts var jag tvungen att välja bort DOM- parsern på grund utav dess dåliga prestanda när stora XML- dokument ska behandlas (se 3.1.2.2). Jag valde därför att främst använda mig utav SAX- parsern, vilket var mycket mer minneseffektiv då den sekventiellt läser in XML- dokument. StAX parsern använde jag även till en annan lösning för XML formatet bara för att jämföra de olika teknikerna och för att se om det var någon större skillnad. Resultatet var att StAX parsern var något långsammare än SAX parsern. 5.1.2.2 Parsning av flatfil Det finns väl ett obenämnt antal lösningar för att parsa en flatfil. Mitt val föll på att läsa in ett X antal bitar/tecken i taget, där jag sedan tog ut de olika delarna utav inläsningen för varje KU i filen. Skulle en inläsning vara ofullständig, d.v.s. att den bröts mitt i en "uppgift" så sparade programmet den ofullständiga delen till nästa inläsning och lade sedan till den i början.

5.1.3 Prestandajämförelse Prestandajämförelsen som jag har utfört gick till så att jag skapade 9 st. KU- filer för båda filformaten med olika antal KU i varje fil om 100, 500, 1 000, 10 000, 50 000, 100 000, 200 000, 300 000 och 500 000 st. Jag gjorde ett flertal prestandajämförelser för varje antal KU så jag såg att resultaten blev någorlunda lika varandra. 5.1.3.1 Sammanställning av prestandajämförelse Skatteverket efterfrågade en testbilaga med bearbetningstider och diagram och för det så valde jag att använda Microsofts verktyg Excel. Resultatet av prestandajämförelsen blev enligt följande graf. X- axeln motsvarar antal KU och Y- axeln tiden i millisekunder. Figur 3: Resultat för bearbetningstid av XML & Flatfil om 100-500 000 KU 5.2 Användargränssnitt I planeringen av examensarbetet så ingick inget grafiskt användargränssnitt (GUI). Men då tid fanns över efter att prestandatesterna hade slutförts så bestämdes det att ett GUI skulle tas fram. Resultatet blev att jag använde mig av Java swing. Målet var att skapa ett enkelt gränssnitt där användaren kan välja antalet KU som ska parsas utifrån en fördefinierad lista med testfiler. Applikationen skriver ut vilken parser som är snabbast och med hur många procent mer den är snabbare jämfört med den andra. 16 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

Gränssnittet visar även andra intressanta parametrar så som hur många KU som parsats när som mest arbetsminne användes av datorn samt hur många KU som parsades totalt från varje fil, vilket gör det enklare att se ifall någon parser eller KU- fil skulle misslyckas eller vara trasig förutsatt att användaren vet hur många KU som filen borde ha innehållit. Figur 4: Användargränssnittet uppbyggt av Java- swing 5.3 Databasstruktur Eftersom examensarbetet endast innefattade en entitet "Kontrolluppgift" för databasen så blev det inte ett så stort ER- diagram. Som tidigare nämnts så använde jag JPA för att sätta upp databasentiteterna i Java vilket underlättade för mig då jag inte behövde bry mig så mycket om databasen mer än att anslutningen fungerade mellan Java- projektet och databasen, samt att rätt antal kontrolluppgifter skrevs till databasen och även att databasen tömdes efter varje fil som parsades. Ett utdrag av databasentiteten kontrolluppgift går att se i kapitel 4.4.4. 5.4 Programkod För exjobbet så skapade jag totalt fyra projekt, varav det första används för att generera testfilerna och de tre andra bygger på varandra för att parsa kontrolluppgiftsfilerna. Jag kommer därför ta upp dem i följande ordning som jag utvecklade dem. 5.4.1 Statistik Projekt ett; Detta är projektet som genererar test- KU- filerna. Projektet är ensamstående och innefattar totalt 4 filer som jag skrivit själv, 18 stycken som genererades av JAXB samt ytterligare 3 filer som är XML- schemat som jag fick från Skatteverket. Totalt antal rader som jag skrev för detta projekt var 821. Projekt två; Projektet är själva basen för parsningen och är en del utav applikationen som ligger på WLSen. Projektet parsar båda filformaten och skriver kontrolluppgifterna till SQL- databasen. Projektet består av 8 filer som jag skrivit själv, samt 1 fil som lånades från en tidigare kurs TDP024 där jag även använde JPA. Det totala antalet rader som jag skrev för projektet var 1847.

Projekt tre; En del av projektet genererades av Rational Rose, vilket är den delen som ska implementeras för WLSen. Men då jag gjorde projektet som parsar filformaten innan detta projekt så fick det bli så att det importeras som en JAR- fil i projektet. Totalt så genererade jag en klass i Rose som jag implementerade och blev på totalt 55 rader. Projektet innehöll ett X antal andra filer som jag varken hade skapat eller hade möjlighet att räkna. Dessa filer fick jag av Skatteverket och var beroende av byggstödet Ant för att få upp applikationen på WLSen. Projekt fyra; Projektet innehåller bland annat det grafiska användargränssnittet som jag skapade för att förenkla prestandamätningen. Projektet innehåller även kommunikationen till applikationen på WLSen och implementerar vissa Skatteverksspecifika funktioner i deras säkerhetsbibliotek. Projektet består av 3 filer som jag skrivit och innehåller totalt 265 rader kod. 5.5 Prestandamätning Som tidigare nämnt så valde jag att implementera SAX parsern för att parsa XML- dokument av förut förklarliga skäl. Jag försökte även att så gott som möjligt optimera koden jag skrev för att parsa flatfiler. Resultatet av prestandajämförelsen kan ses i grafen i figur 3 som visar bearbetningstiden för båda filformaten om 100 till 500 000 KU. Prestandamätningarna som jag utfört för filformaten var vid vissa tillfällen lite oviss då bearbetningstiderna varierade för samma antal KU om dessa parsades ett par gånger efter varandra. Jag kan dock ha kommit på en potentiell lösning vilket är att ändra "last modified" eller senast ändrad- stämpeln som finns för alla filer i operativsystemet till den aktuella tiden när skriptet körs. Enligt min mening borde det vara en av parametrarna som operativsystemet kontrollerar innan den lämnar ut filer från sin cache. Resultatet av bearbetningstiden blev aningen mer jämna efter att jag implementerade lösningen. Jag kom även fram till att min flatfilsparser trots skillnaden i filstorlek mellan kontrolluppgiftsfilerna för flat och XML fil är 29% snabbare i genomsnitt än XML parsern. 18 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

6 Slutsats och diskussion 6.1 Egen reflektion och diskussion Arbetet flöt på bra från början till slut. Det enda som jag fastnade på och som jag fick support av min handledare var när projektet skullen integreras med Skatteverkets säkerhetssystem och publiceras på den lokala WLSen. Det var intressant att arbeta med stora mängder data då jag fick erfara hur det kan vara att inte ha all information tillgänglig hela tiden, med risk för att arbetsminnet skulle ta slut. Jag var därför tvungen att ta vara på det som var viktigt och göra något med det för att hålla minnesanvändningen så låg som möjligt. Att arbetsminnet tog slut var ett problem som återkom ett par gånger. Resultatet av prestandajämförelsen med snittet på 29% (se tabell 1) skillnad i bearbetningstiden är rätt oväntat då den procentuella skillnaden i filstorlek är konstant runt 80% (se tabell 2) mellan samma antal KU för filformaten. Jag tycker att flatfilsparsern presterade dåligt och att den procentuella skillnaden mellan filstorleken och bearbetningstiden borde ha varit mer lika. Detta kan bero på att det ännu finns vissa delar kvar att optimera för flatfilsparsern, t.ex. antal tecken som läses in i taget vid varje bearbetning av data eller att en annan algoritm kan vara mer passande, t.ex. reguljära uttryck istället för att leta efter skiljetecken som min parser gjorde. ANTAL KU XML FIL (ms) FLATFIL (ms) Procentuell skillnad 100 141 94 33,33 500 391 328 16,11 1 000 1 593 1 125 29,38 10 000 10 969 7 313 33,33 50 000 64 466 47 092 26,95 100 000 111 531 73 964 33,68 200 000 277 928 181 260 34,78 300 000 332 059 232 696 29,92 500 000 613 133 447 108 27,09 MEDEL 29,40 Tabell 1: Procentuell skillnad för bearbetningstid. Enligt formeln: 100 - (minsttid/ mesttid) * 100. Där minsttid är filen som tog kortast tid att parsa (ms), mesttid är filen som tog längst tid att parsa (ms) och 100 som det hela (100%) ANTAL KU XML FIL (kb) FLATFIL (kb) Procentuell skillnad 100 249 51 79,52 500 1 243 252 79,73 1 000 2 485 503 79,76 10 000 24 862 5 047 79,70 50 000 124 395 25 321 79,64 100 000 248 808 50 662 79,63 200 000 497 831 101 541 79,60 300 000 746 855 152 420 79,59 500 000 1 244 901 254 178 79,58 MEDEL: 79,64 Tabell 2: Procentuell skillnad för filstorlek. Enligt formeln: 100 - (minststorlek/störststorlek) * 100. Där minststorlek är filen som har minst storlek (kb), störststorlek är filen som har störst storlek (kb) och 100 som det hela (100%)

En del laborerande med antalet tecken som lästes in för varje parser gjordes. Jag började med att sätta inläsningen till 1024 tecken och ändrade sedan till 2048. Jag såg en viss förbättring i bearbetningstiden, i alla fall för flatfils- parsern. Dock behöver fler tester göras för att hitta rätt storlek för inläsningen. Jag testade även att placera parsningen av filerna i trådar för att se hur det påverkade systemet då det är ungefär så det kommer att se ut senare i verkligheten i det riktiga systemet. Resultatet av det blev ovisst eftersom jag inte hittade ett sett att styra hur trådarna fick exekvera vilket medförde att trådarna kunde bli klara i olika ordningar. Därför så använde jag inte denna lösning i det färdiga resultatet. Programspråket Java passade uppgiften alldeles utmärkt då det fanns många stöd som förenklade mitt arbete, bl.a. JAXB som genererade alla nödvändiga klasser utefter ett XML- schema som behövdes för att skapa ett korrekt XML- dokument. JPA var en annan fördel med Java som förenklade databashanteringen mellan Java- projektet och Oracle- databasen. Inga testfall skrevs för arbetet utan systemet testades hela tiden manuellt med provkörningar av generering av KU- filer och parsning av dessa. JAXB validerade också dels att XML- dokumenten utifrån XML- schemat att de var korrekta innan de genererades till filer. Det skulle ha varit bättre om jag hade skrivit några testfall för systemet för att kunna påvisa att systemet fungerar korrekt utifrån de förväntningar det hade, t.ex. att rätt antal KU parsats från filerna. 6.1.1 Fortsatt arbete Det som finns att fortsätta arbeta vidare på är att utöka databasstrukturen, då jag endast hade en entitet för alla kontrolluppgifter där jag endast tog till vara på informationen för kontrolluppgifter för personer. Ett exempel skulle vara att bryta ut mer information från KU- filerna och dela upp det i flera entiteter, t.ex. en entitet "Arbetsgivare" och sen ha kvar "Kontrolluppgift" där Kontrolluppgift är länkat till Arbetsgivare. Detta för att uppnå en högre normalnivå. En annan sak som kan arbetas vidare på är de varierande bearbetningstiderna som förekom ibland. Under arbetet så gjorde jag ett antagande om att det kunde vara operativsystemet som sparade filerna i en cache för att optimera accessen av filerna. Dock blev resultatet mer jämnt efter att jag implementerat en lösning som uppdaterar senast ändrad- flaggan för filerna innan de börjar parsas. En annan anledning kan vara att något annat program i bakgrunden utförde något vilket påverkade testen. 6.2 Slutsats Här sammanställer jag min slutsats utifrån de frågeställningar som specificerades i kapitel 1.4. "Finns det någon teknik att generera XML dokument i Java eller hur gör man det enklast?" Ja, jag hittade ett verktyg/teknik JAXB som kan användas för att generera Java- klasser utifrån ett XML- schema. Dessa klasser fyller man upp med information och genererar sedan dessa till en fil. JAXB kan även tala om ifall XML- objekten inte är 20 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER

fullständiga när XML- dokumentet ska genereras och på så vis förhindra fel, detta valideras mot XML- schemat. "Vilka olika parsningstekniker/metoder finns det för att traversera de olika filformaten och vilken metod lämpar sig bäst för arbetet?" I min undersökning hittade jag tre möjliga tekniker för att parsa XML- filer som jag intresserade mig för: DOM, SAX och StAX. Mitt val föll på att implementera SAX- parsern till förmån av dess prestanda och då de kunde hantera större filer utan problem eftersom det var den parsern som var mest minneseffektiv. För flatfiler hittade jag dock ingen färdig teknik som jag kunde använda mig av. Utan jag implementerade en helt egen teknik som jag ansåg vara den bästa utefter de behov som fanns. "Finns det något bra sätt att hantera databasanslutningen på?" Då jag har arbetat med JPA i en tidigare kurs och tyckte att det fungerade bra så valde jag även att använda det i examensarbetet, vilket förenklade databashanteringen avsevärt. "Hur stor är storleksskillnaden mellan filformaten och hur mycket påverkar det bearbetningstiden?" Båda filformaten använde samma basklass och innehöll samma data så det var lika på det viset. Storleksskillnaden på det blev konstant ungefär 80% för samma antal KU. Bearbetningstiden höll sig även den någorlunda konstant ungefär runt 29% i skillnad för samma antal KU. Jag tycker att skillnaden i bearbetningstiden borde ha varit större eftersom skillnaden i filstorlek mellan filformaten är så pass stor. Bearbetningstiden är inte riktigt linjär men ändå inte långt ifrån. Detta är på grund av några undantag som jag har gjort ett antagande av, att det är operativsystemet som cachar filerna för snabbare uppläsning eller att ett program i bakgrunden utförde något som påverkade testen.

22 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER 7 Referenser "Types of software Testing" Hämtad från: <http://www.softwaretestinghelp.com/types- of- software- testing/> 2012-08- 30 Margaret Rouse: "What is Rational Rose?" (2005-08- 01) Hämtad från: <http://searchcio- midmarket.techtarget.com/definition/rational- Rose> 2012-08- 31 "Apache Ant" Hämtad från: <http://ant.apache.org/> 2012-08- 31 Allu: "Difference between SAX and DOM parsers?" (2006-12- 28) Hämtad från: <http://allu.wordpress.com/2006/12/28/difference- between- sax- and- dom- parsers/> 2012-08- 31 Margaret Rouse "Rational Rose" (2005-08- 01) Hämtad från: <http://searchcio- midmarket.techtarget.com/definition/rational- Rose> 2012-11- 26 7.1 Wikipedia "Database normalization" (2012-11- 25) Hämtad från: <http://en.wikipedia.org/wiki/database_normalization> 2012-11- 26 "Java Persistence API" (2012-11- 10) Hämtad från: <http://en.wikipedia.org/wiki/java_persistence_api> 2012-11- 26 "Simple API for XML" (2012-11- 12) Hämtad från: <http://en.wikipedia.org/wiki/simple_api_for_xml> 2012-11- 26 "Document Object Model" (2012-11- 02) Hämtad från: <http://en.wikipedia.org/wiki/document_object_model> 2012-11- 26 "StAX" (2012-11- 22) Hämtad från: <http://en.wikipedia.org/wiki/stax> 2012-11- 26 "Oracle WebLogic Server" (2012-11- 23) Hämtad från <http://en.wikipedia.org/wiki/oracle_weblogic_server> 2012-11- 26 "Apache Ant" (2012-11- 08) Hämtad från <http://en.wikipedia.org/wiki/apache_ant> 2012-11- 26

8 Bilagor 8.1 Kontrolluppgifter 8.1.1 XML- format 1 <?xml version="1.0" encoding="utf- 8" standalone="yes"?> 2 <ns3:manadsuppgift 3 xmlns="se/skatteverket/infoforbeskattning/komponent/0.1" 4 xmlns:ns2="se/skatteverket/gemensam" 5 xmlns:ns3="se/skatteverket/kontrolluppgifter/instans/0.1 6 "> 7 <Transport> 8 <Skapad>2012-06- 07T13:11:23.000+02:00</Skapad> 9 <Behandlingstyp>Produktion</Behandlingstyp> 10 <Mottagare> 11 <Namn>Skatteverket</Namn> 12 <Plats>Solna</Plats> 13 </Mottagare> 14 <Sandare> 15 <Orgnr>165555555555</Orgnr> 16 <Namn>Kringlans bageri</namn> 17 <Avdelning></Avdelning> 18 <Kontaktperson>Mästerbagaren</Kontaktperson> 19 <Adress>Skatteverket 1</Adress> 20 <Postnr>62123</Postnr> 21 <Postort>Visby</Postort> 22 <Telefonnummer>+46827362</Telefonnummer> 23 <Faxnr>+4692387623</Faxnr> 24 <Epost>masterbagare@kringlan.se</Epost> 25 </Sandare> 26 </Transport> 27 <Kontrolluppgift> 28 <Inkomsttagare> 29 <ns2:adress> 30 <ns2:gatuadress>skatteverket 31 1</ns2:Gatuadress> 32 <ns2:postnr>62123</ns2:postnr> 33 <ns2:postort>visby</ns2:postort> 34 </ns2:adress> 35 <Fornamn>John1</Fornamn> 36 <Efternamn>Doe</Efternamn> 37 <Personnr>500101-0015</Personnr> 38 <Orgnr></Orgnr> 39 </Inkomsttagare> 40 <AvdragenSkatt01>2323.0</AvdragenSkatt01> 41 <Deltagare61>true</Deltagare61> 42 <Arbetsstallenr60>892</Arbetsstallenr60> 43 <Kontantlon>

44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 24 UTVÄRDERING AV INLÄSNING AV XML- KONTRA FLATFILER <Bruttolon11>192580.0</Bruttolon11> <TillGrundEgenavgifter25>1500.0</TillGrundEgenavgifter25 > <SpecifikationTillGrundEgenavgift67>Hantvärkare tapetserade vardagsrummet</specifikationtillgrundegenavgift67> <InteGrundSocialaAvgifter31>700.0</InteGrundSocialaAvgif ter31> <SpecifikationTillInteGrundSocialaAvg>FRI TIDNING</SpecifikationTillInteGrundSocialaAvg> <SjuklonXX>0.0</SjuklonXX> <ErsattningSjuklForaldrarLedigXX>0.0</ErsattningSjuklFor aldrarledigxx> </Kontantlon> <Formaner> <Skattepliktiga12>1000.0</Skattepliktiga12> <BostadSmahus41>false</BostadSmahus41> <Kost42>false</Kost42> <BostadEjSmahus43>false</BostadEjSmahus43> <Ranta44>false</Ranta44> <Parkering45>false</Parkering45> <AnnanForman47>true</AnnanForman47> <FormanHarJusterats48>false</FormanHarJusterats48> <FormanSomPension49>false</FormanSomPension49> <AnnanFormanSpecifikation65>Tandläkare</AnnanFormanSpeci fikation65> <BilformanUtomDrivmedel13>0.0</BilformanUtomDrivmedel13> <Drivmedel18>1250.0</Drivmedel18> <KodForFormansbil14>TY2</KodForFormansbil14> <AntalKm16>2150</AntalKm16> <BetaltForBilforman17>550.0</BetaltForBilforman17> </Formaner> <Kostnadsersattningar> <SchablonBilersattning50>true</SchablonBilersattning50> <SchablonTraktamenteRiket51>false</SchablonTraktamenteRi ket51> <SchablonTraktamenteUtomRiket52>false</SchablonTraktamen