Systemintegration mellan tidsredovisnings- och bokföringssystem

Sj ¨alvst ¨andigt arbete i informationsteknologi

27 juni 2017

Systemintegration mellan

tidsredovisnings- och

bokf ¨oringssystem

Tom Althin

Patrik Larsson

Andreas Leander

Institutionen f ¨or informationsteknologi Bes ¨oksadress: ITC, Polacksbacken L ¨agerhyddsv ¨agen 2 Postadress: Box 337 751 05 Uppsala Hemsida: http:/www.it.uu.se Abstract

Systemintegration

mellan

tidsredovisnings-och bokf ¨

oringssystem

Tom Althin Patrik Larsson Andreas Leander

Society stores information in IT-systems in order to streamline day to to day tasks. In order to make sure that the information is legitimate and up to date, synchronisation between several locations is needed. We have chosen to synchronise and automate time reports between the time report system Timesheet and invoice system Fortnox for the com-pany Consoden. This has been done with the purpose of streamlining the work for the administrators in charge of invoices. The project has also focused on the integration process between some arbitrary system and Fortnox. Before this project two administrators worked a minimum of five days a month with manually synchronising time reports from projects and creating invoices for them. The process of synchronizing information regarding clients, projects and suppliers have been fully au-tomated in order to ease the creation of invoices.

Extern handledare: Bj¨orn Westr¨om, Consoden Handledare: Bj¨orn Victor, Tina Vrieler

Sammanfattning

I dagens samh¨alle sparas information i IT-system f¨or att effektivisera dagliga arbetsupp-gifter. D¨arf¨or ¨okar pressen p˚a att n¨odv¨andig information finns tillg¨anglig och i synkroni-serat tillst˚and p˚a flera platser. Vi har valt att synkronisera information n¨odv¨andig f¨or fak-turahantering mellan tidsredovisningssystemet Timesheet och bokf¨oringssystemet Fort-nox. Syftet har varit att underl¨atta fakturahantering f¨or f¨oretaget Consoden som haft tv˚a personer som arbetat minst fem dagar varje m˚anad med att manuellt hantera information n¨odv¨andig f¨or fakturering. Projektet har ¨aven fokuserat p˚a sj¨alva integrationsprocessen mellan n˚agot godtyckligt system och Fortnox. Processen att synkronisera information g¨allande klient-, projekt- och leverant¨orsuppgifter har blivit fullst¨andigt automatiserad.

Inneh ˚all

1 Introduktion 1

2 Bakgrund 2

2.1 Uppdragsgivarens problem . . . 2

3 Syfte, m˚al och motivation 3 3.1 Motivation . . . 3 3.2 M˚al . . . 4 3.3 Avgr¨ansning av problemet . . . 4 3.4 Etiska fr˚agest¨allningar . . . 4 4 Relaterat arbete 4 5 Metod 6 5.1 Samarbete med extern intressent . . . 6

5.2 Teknik och verktyg . . . 6

5.2.1 Timesheet . . . 6

5.2.2 Databas . . . 8

5.2.3 Fortnox . . . 8

5.2.4 Integrering och synkronisering . . . 9

5.2.5 Enhetstester . . . 9

5.2.6 Hypertext Transfer Protocol . . . 9

5.2.7 HTTP-svarskod . . . 9 5.2.8 cURL . . . 10 5.2.9 API . . . 10 5.2.10 JSON . . . 10 5.2.11 PHPUnit . . . 11 6 Systemstruktur 13 6.1 Kommunikationskanaler . . . 13 6.2 Gr¨anssnitt . . . 14 6.3 Databas . . . 14 6.4 Anv¨andare . . . 14

7 Krav och utv¨arderingsmetoder 15 7.1 Funktionella Krav . . . 15

8 Teknisk implementation 17 9 Implementation 18 9.1 Bakgrundsarbete . . . 19 9.2 Uppdatering av Databas . . . 19 9.3 Synkronisering av klientuppgifter . . . 20 9.4 Synkronisering av projektuppgifter . . . 20 9.5 Synkronisering av leverant¨orsuppgifter . . . 21 9.6 Loggning av synkronisering . . . 21 9.7 Misslyckad synkronisering . . . 22 9.8 Testning av l¨osningen . . . 22 10 Resultat 23 10.1 Synkronisering av Klientuppgifter . . . 23 10.2 Synkronisering av Projektuppgifter . . . 24 10.3 Synkronisering av Leverant¨orsuppgifter . . . 26 10.4 Loggning av synkronisering . . . 27 10.5 Enhetstester . . . 27 11 Diskussion 27 12 Slutsats 29 13 Framtida arbete 30

1 Introduktion

1

Introduktion

Ett ˚aterkommande problem som dyker upp vid anv¨andning av olika IT-system p˚a ar-betsplatser ¨ar att systemen inte ¨ar utformade med anv¨andaren i ˚atanke [10, sida 12]. System som har som uppgift att l¨osa ett problem eller underl¨atta en arbetsuppgift kan i slut¨andan skapa en process som ¨ar mer tidskr¨avande ¨an planerat. N¨ar tv˚a system likt tv˚a m¨anniskor ska l¨osa var sin del av ett st¨orre problem beh¨ovs en kommunikationskanal och en ¨overl¨amning s˚a att de tv˚a dell¨osningarna kan sammanf¨oras f¨or att bli komplett. En systemintegration ska utf¨oras ˚at f¨oretaget Consoden d¨ar tidsredovisningssystemet Ti-mesheet ska knytas samman med bokf¨oringssystemet Fortnox. Fortnox tillhandah˚aller en samling funktioner som m¨ojligg¨or f¨or informationsutbyte mellan Fortnox och ett godtyckligt system. Projektet ska unders¨oka integrationsprocessen mellan Timesheet och Fortnox, f¨or att tillhandah˚alla en metod som i framtiden g¨or det l¨attare f¨or f¨oretag att integrera sitt tidsredovisningssystem med Fortnox. Det finns ingen kanal f¨or kom-munikation emellan systemen, vilket leder till att manuellt arbete m˚aste till¨ampas f¨or att synkronisera information mellan systemen.

Syftet med projektet ¨ar att automatisera synkronisering av information mellan de tv˚a systemen. Det som ska synkroniseras ¨ar uppgifter om Consodens klienter och projekt fr˚an Timesheet till Fortnox samt uppgifter om Consodens leverant¨orer fr˚an Fortnox till Timesheet. Detta ¨ar information som Consoden anv¨ander f¨or att skapa fakturor. Att automatiskt kunna synkronisera information mellan de tv˚a systemen kommer att ef-fektivisera processen att skapa en faktura och d¨armed kr¨ava mindre arbetstimmar. En automatisering ska ¨aven minska risken f¨or misstag som kan uppkomma vid manuell ¨overf¨oring av information [18, sida 528].

Ut¨over synkronisering mellan de tv˚a systemen ska integrationsl¨osningen testas genom enhetstester f¨or att s¨akerhetsst¨alla att ingen information korrumperas vid ¨overf¨oringen samt f¨or att minimera antalet buggar i systemet. Varje synkronisering ska loggas i Consodens databas s˚a att det g˚ar att se om synkroniseringen g˚att bra, vem som har gjort den, samt vilken tid synkroniseringen skedde.

2 Bakgrund

2

Bakgrund

I dagens f¨oretagsklimat finns det f¨oretag som anv¨ander olika IT-system, h¨arefter kallat system, i sin f¨oretagsstruktur [7, sida 2]. Om dessa system ¨ar beroende av varandra rent informationsm¨assigt kr¨aver det kommunikation mellan systemen. Kommunikation mel-lan system inneb¨ar att det sker ett informationsutbyte melmel-lan systemen. N¨ar tv˚a system inom ett f¨oretag saknar just m¨ojligheten att kommunicera med varandra men fortfarande ¨ar beroende av varandra kr¨avs manuellt arbete f¨or ¨overf¨oring av informationen mellan systemen [23]. Personal tvingas d˚a l¨agga ner arbetstid p˚a att se till att information fak-tiskt ¨overf¨ors.

Det naturliga, och i l¨angden det mest kostnadseffektiva, skulle vara f¨or ett f¨oretag att au-tomatisera denna process. Genom en automatisering av informations¨overf¨oringen mel-lan system skulle arbetstimmar frig¨oras och man skulle dessutom minimera risken f¨or misstag orsakade av den m¨anskliga faktorn [18, sida 535].

2.1

Uppdragsgivarens problem

Uppdragsgivaren Consoden har ett tidsredovisningssystem, Timesheet, och ett externt bokf¨oringssystem, Fortnox. I tidsredovisningssystemet loggar Consoden all aktivitet g¨allande deras konsultprojekt. Anst¨allda matar in hur m˚anga timmar de har spenderat och p˚a vad. Det ¨ar denna information som ligger till grund f¨or Consodens fakturor. I dagsl¨aget anv¨ander Consoden Fortnox enbart i bokf¨oringssyften. I framtiden vill de ¨aven b¨orja anv¨anda samma system f¨or att fakturera sina klienter. En fakturering kan d¨aremot inte genomf¨oras utan den klient- och projektinformation som ˚aterfinns i Ti-mesheet. Information mellan dessa system m˚aste d¨arf¨or synkroniseras.

N˚agon s˚adan l¨osning finns inte i dagsl¨aget vilket inneb¨ar att ingen kommunikation sker mellan Timesheet och Fortnox. Faktureringen utf¨ors via manuella rutiner d¨ar klient, pro-jekt extraheras av en person p˚a ekonomiavdelningen. Informationen kopieras och klist-ras sedan in i ett excelark. En summering av arbetade timmar samt vilket arbete som utf¨orts fylls sedan manuellt in i arket f¨or att sedan mejlas eller postas till klienten. Sum-meringen fylls ¨aven manuellt in i Fortnox i bokf¨oringssyfte. Enligt v˚ar f¨oretagskontakt p˚a Consoden, Bj¨orn Westr¨om [17], medf¨or denna handp˚al¨aggningsprocess att tv˚a admi-nistrat¨orer spenderar minst fem dagar varje m˚anad ˚at detta. Det ¨ar ett kostsamt extraar-bete som skulle kunna minskas genom automatisering i form av en integrering mellan de tv˚a systemen [33].

3 Syfte, m˚al och motivation

I Fortnox ˚aterfinns ¨aven leverant¨orsfakturor. Leverant¨orsfakturor ¨ar fakturor Consoden f˚ar fr˚an exempelvis externa konsulter som anst¨allts f¨or att bist˚a i deras projekt. F¨or att i framtiden ha m¨ojlighet att sammanst¨alla dessa leverant¨orsfakturor vill Consoden ha m¨ojlighet att synkronisera informationen fr˚an Fortnox till Timesheet.

3

Syfte, m ˚al och motivation

Det ¨overgripande syftet med projektet ¨ar att unders¨oka problematiken med informa-tionssynkronisering mellan tv˚a system som saknar naturliga kommunikationskanaler. Vi vill unders¨oka f¨or- och nackdelar med olika tillv¨agag˚angss¨att f¨or att implementera en s˚adan kommunikationskanal. Vid skapandet av funktioner f¨or att hantera synkroni-sering av information kommer m¨ojligheterna f¨or integration mellan ett Timesheet och Fortnox att unders¨okas. Vid en lyckad integrering kan andra dra l¨ardom av detta projekt och integrera fler system med Fortnox.

3.1

Motivation

Om ett f¨oretag v¨aljer att l¨agga arbetstimmar p˚a att manuellt ¨overf¨ora information mel-lan tv˚a system ist¨allet f¨or att automatisera synkroniseringen kan flertalet risker uppst˚a. I takt med att f¨oretaget v¨axer finns en risk att arbetsb¨ordan relaterat till manuell synkro-nisering blir tung [18, sida 535]. ˚Atskilliga arbetstimmar m˚aste d˚a g˚a ˚at till att manuellt f¨ora ¨over och synkronisera information mellan system. D˚a information m˚aste matas in p˚a flera platser ¨okar ocks˚a risken f¨or misstag och konflikter i informationen [18, sida 537].

F¨or ett f¨oretag som vill integrera sina system ¨ar det viktigt att f¨oretaget uppr¨attar en genomg˚aende analys av de system de vill integrera. Detta ¨ar n¨odv¨andigt f¨or att data ska kunna synkroniseras s˚a riskfritt som m¨ojligt mellan systemen. I analysen b¨or f¨oretaget ta i beaktande hur systemen ¨ar uppbyggda, vilken data som ska synkroniseras och hur data ska synkroniseras [15].

Alla f¨oretag har dock inte ekonomin eller kompetensen f¨or att investera i utvecklingen av sina system och se till att systemen har en automatiserad synkronisering sinsemel-lan [11, sida 108]. D¨arf¨or tror vi det finns ett behov av hitta en enkel och smidig l¨osning p˚a integrationsproblematiken.

4 Relaterat arbete

3.2

M ˚al

Det huvudsakliga m˚alet med projektet ¨ar att integrera tv˚a system, tidsredovisningssy-stemet Timesheet och bokf¨oringssytidsredovisningssy-stemet Fortnox. Fortnox tillhandah˚aller ett API som kan anv¨andas via HTTP-anrop med hj¨alp av cURL. Detta g¨or det intressant att skapa eg-na funktioner som hanterar information till och fr˚an Fortnox. En konkretisering av m˚alet inneb¨ar att vi ska lyckas automatisera ¨overf¨orande av relevant information fr˚an Times-heet till Fortnox (se avsnitt 7.2). Utifr˚an den ¨overf¨orda information ska sedan Consoden ha m¨ojligheten att generera en faktura.

3.3

Avgr ¨ansning av problemet

Vi unders¨oker problematiken och l¨osningsm¨ojligheterna kring problemet att skapa en informationskanal mellan tv˚a IT-system. I v˚art fall handlar det om ett tidsredovisnings-system och ett bokf¨oringstidsredovisnings-system. Information ska extraheras fr˚an tidsredovisningssy-stemet f¨or att sedan omvandlas och importeras till bokf¨oringssytidsredovisningssy-stemet. All information i Timesheet ¨ar inte relevant i faktureringssyfte. D¨arf¨or g¨ors en avv¨agning av vilken in-formation som beh¨over synkroniseras.

3.4

Etiska fr ˚agest ¨allningar

De etiska fr˚agest¨allningarna g¨aller hanteringen av personuppgifter och annan k¨anslig in-formation som f¨oretaget Consoden har i sin databas och i Fortnox. Det ¨ar d¨arf¨or viktigt att all information skickas r¨att och inte kan avl¨asas av n˚agon utomst˚aende n¨ar informa-tion extraheras ur Fortnox eller Timesheet. I dagsl¨aget g˚ar det inte att komma ˚at n˚agon k¨anslig information om man inte loggar in i deras system. Varje enskild anst¨alld har en egen inloggning till Timesheet vilket g¨or att enbart beh¨origa har tilltr¨ade till systemet.

4

Relaterat arbete

Det finns flera f¨oretag som jobbar med integrering av IT-system, t.ex. IBM, Sogeti och Entiros [20] [3] [1]. Det finns ¨aven integreringsl¨osningar till Fortnox t.ex. Trivec som er-bjuder en tj¨anst f¨or dagskassaintegrering [4]. F¨oretagets dagsavslut l¨ases d˚a automatisk in i Fortnox. L¨osningen som Trivec erbjuder ¨ar d¨arf¨or inget som passar en konsultbyr˚a som Consoden d˚a de inte arbetar med dagsavslut.

4 Relaterat arbete

Det finns tv˚a grundl¨aggande tekniker f¨or att skapa en systemintegrering, en av tekniker-na ¨ar middleware d¨ar man bygger ett system som agerar medlare mellan tv˚a grundsy-stem [8]. Ett exempel p˚a detta ¨ar IBM’s MQ series som bland annat har anv¨ants f¨or att integrera sjukhusjournaler p˚a University Medical Center Freiburg [21] [22]. En annan implementationsteknik av middleware ¨ar Enterprise Application Integration h¨arefter kallat EAI. EAI ¨ar en integreringsteknik som g˚ar ut p˚a att integrera flera system in-om ett f¨oretag oberoende av filformat, operativsystem, databas, eller programmerings-spr˚ak [32]. Att utveckla en EAI-integration ¨ar en komplex process d˚a det kr¨avs en avan-cerad logik f¨or att flertalet system ska kunna kommunicera med varandra samtidigt [32, sida 2834].

Det finns ¨aven Point to point-integrering d¨ar system kommunicerar med varandra direkt utan mellanhand [29, sida 211], se figur 1 nedan. Denna typ av integrering l¨ampar sig b¨ast n¨ar det ¨ar f˚a system som ska kommunicera med varandra [29, sida 215]. Tekniken g˚ar ut p˚a att skapa en kommunikationskanal direkt mellan tv˚a system vilket medf¨or att det blir komplicerat att l¨agga till fler system [29, sida 211].

5 Metod

5

Metod

I arbetet med att integrera Consodens tidsredovisningssystem och deras bokf¨oringssystem har vi anv¨ant oss av olika verktyg och hj¨alpmedel. I denna sektion beskrivs dessa verktyg och hj¨alpmedel. Vi kommer ¨aven g˚a in n¨armare p˚a hur v˚art samarbete med Consoden har g˚att till.

5.1

Samarbete med extern intressent

Vi har genomg˚aende under hela projektarbetet haft en kontinuerlig kontakt med Bj¨orn Westr¨om och Bengt Norlin p˚a f¨oretaget Consoden. D˚a Bj¨orn och Bengt anv¨ander tidsre-dovisningssystemet Timesheet och bokf¨oringssystemet Fortnox i sitt dagliga arbete har de inblick i hur systemen anv¨ands och i vilka avseenden de m˚aste integreras. Genom att ha ett m¨ote i veckan med Bj¨orn och Bengt under hela projektets g˚ang har vi skaffat oss en klar bild av hur Consoden anv¨ander dessa system i dagsl¨aget. Under dessa m¨oten har vi bland annat diskuterat vilken information som ¨ar relevant att synkronisera.

5.2

Teknik och verktyg

F¨or att integrera Consodens tidsredovisningssystem Timesheet och deras bokf¨orings-system Fortnox har vi att anv¨ant oss av PHP 5.6, MySQL och HTML [6] [5] [13]. I f¨oljande underrubriker kommer vi g˚a n¨armare p˚a hur Timesheet och Fortnox fungerar och hur v˚ara verktyg ¨ar relaterade till dessa system.

5.2.1 Timesheet

Timesheet ¨ar en applikation som ¨ar designad f¨or att man skall kunna logga antalet tim-mar som ett f¨oretags anst¨allda har jobbat p˚a ett visst projekt. Timesheet ¨ar uppbyggt s˚a att ett projekt kan ha flera anst¨allda kopplade till det och en anst¨alld kan arbeta p˚a flera projekt samtidigt. Den stora f¨ordelen med att anv¨anda Timesheet ¨ar att man skaffar sig en ¨overblick p˚a vad f¨or arbetsuppgifter de anst¨alldas arbetstimmar l¨aggs p˚a. Timesheet fungerar d¨aremot enbart som ett tidsredovisningssystem och det finns d¨arf¨or inget st¨od i applikationen f¨or att till exempel generera fakturor utifr˚an den sammanst¨allda informa-tionen.

5 Metod

Timesheet ¨ar till st¨orsta del skrivet i PHP 5.6, HTML och CSS. D˚a Timesheet ¨ar en webbaserad applikation har man valt att bygga upp gr¨anssnittet med hj¨alp av HTML och CSS, se figur 2 nedan. HTML anv¨ands f¨or att ange strukturen p˚a varje sida och CSS f¨or att best¨amma utseendet. Programmeringsspr˚aket PHP anv¨ands f¨or att kommunicera med databasen d¨ar all information lagras. Timesheet ¨ar skrivet i PHP 5.6, vilket inte ¨ar den senaste versionen av PHP. Eftersom Consoden inte har n˚agra planer att skriva om applikationen till en senare version av PHP m˚aste vi f¨orh˚alla oss till det.

Att anv¨anda sig av en gammal version av ett programmeringsspr˚ak medf¨or d¨aremot m˚anga nackdelar. N˚agra av dessa nackdelar ¨ar att det finns f¨arre funktioner, st¨orre s¨akerhetsrisker, fler buggar samt avsaknaden av kontinuerlig underh˚all. PHP 7.0 har n¨astan ingen bak˚atkompatibilitet r¨orande funktioner som har som syfte att kommuni-cera med databaser. Att uppdatera kod skriven i PHP 5.6 till PHP 7.0 skulle d¨arf¨or kr¨ava stora omskrivningar av koden. I PHP 7.0 har man ¨aven fixat till de buggar och s¨akerhetsh˚al som ˚aterfinns i PHP 5.6, vilket g¨or PHP 7.0 en s¨akrare version att anv¨anda i alla avseenden [28].

5 Metod

5.2.2 Databas

All Consodens information g¨allande tidrapportering samt f¨oretagsinformation ¨ar f¨or tillf¨allet lagrat i en MySQL-databas. Detta medf¨or att databasen ¨ar relationsbaserad vil-ket g¨or det enkelt att med hj¨alp av nycklar koppla ihop olika klienter med olika projekt. D˚a Consoden har ett v¨alfungerande system n¨ar det kommer till databashantering valde vi att forts¨atta att utveckla deras databas i MySQL.

5.2.3 Fortnox

Fortnox ¨ar en webbportal d¨ar f¨oretag kan bokf¨ora deras utgifter och inkomster. Fort-nox erbjuder ¨aven m¨ojligheten f¨or f¨oretag att generera fakturor utifr˚an information som f¨oretaget sparat p˚a sitt konto. Information som artiklar, klienter, leverant¨orer, kontopla-ner, projekt och kostnadsst¨allen, se figur 3 nedan. Genom att anropa Fortnox API kan vi synkronisera information mellan Timesheet och Fortnox. API ¨ar det gr¨anssnitt som befinner sig mellan applikationen och biblioteket. I v˚art fall mellan Timesheet och Fort-nox.

Fortnox API ¨ar uppbyggt p˚a ett s¨att att varje underkategori p˚a Fortnox sida har sitt eget API-anrop. Till exempel har klientsidan sina egna anrop f¨or att l¨agga till, ta bort och h¨amta ner en klienten. Samma struktur ˚aterfinns f¨or andra kategorier som projekt och underleverant¨orer. Genom att anropa r¨att API funktioner kan information ¨overf¨oras mellan Timesheet och Fortnox.

5 Metod

5.2.4 Integrering och synkronisering

Systemintegration ¨ar ut¨ovandet av att kombinera ett godtyckligt antal delsystem vare sig det ¨ar mjukvara eller h˚ardvara, i syfte av att skapa ett enhetligt system [19]. Synkro-nisering ¨ar n¨ar ett delsystem kommunicerar ¨andringar i sin data till ett eller flera andra delsystem [30, sida 11].

5.2.5 Enhetstester

I programmering ¨ar enhetstestning en metod f¨or att systematiskt testa mjukvaran. Ge-nom att tillkalla koden man skrivit p˚a olika s¨att g˚ar det att j¨amf¨ora dess resultat med ett f¨orv¨antat resultat [14]. Utifr˚an detta kan man se ifall koden ¨ar l¨amplig f¨or anv¨andning eller om den b¨or skrivas om f¨or att fungera ¨onskv¨art. I mjukvaruutveckling ¨ar enhets-testning av koden viktigt, d˚a den st¨orsta delen av m˚anga programmerares tid g˚ar till att f¨ors¨oka lokalisera och l¨osa buggar [12].

5.2.6 Hypertext Transfer Protocol

Hypertext transfer protocol, f¨orkortat HTTP ¨ar ett internetprotokoll som anv¨ands f¨or att skicka information ¨over internet via HTTP-anrop[27]. Tv˚a basfunktioner vid anv¨andning av HTTP ¨ar REQUEST samt RESPONSE. Request anv¨ands f¨or att kunna skicka en f¨orfr˚agan om information. Response anv¨ands f¨or att ta emot information. Dessa tv˚a funktioner g¨or det m¨ojligt att skicka information fr˚an en punkt till en annan ¨over inter-net.

5.2.7 HTTP-svarskod

N¨ar en server tar emot ett HTTP-anrop returnerar den en svarskod [26]. Svarskoden kommer i spannet 100 till 500 och representerar bland annat om anropet har lyckats, misslyckats eller om servern har problem. Detta anv¨ands f¨or att analysera ifall det skett n˚agon form av komplikation n¨ar information tagits emot eller skickats.

5 Metod

5.2.8 cURL

cURL ¨ar ett mjukvarubibliotek som g¨or det m¨ojligt att skicka data fr˚an en punkt till en annan via bland annat HTTP [31]. cURL g¨or det m¨ojligt att h¨amta information mellan tv˚a program eller tv˚a programmeringsspr˚ak som ej kan kommunicera med varandra. Detta g¨ors genom att cURL skickar en f¨orfr˚agan om information och sedan skriver ut eller sparar svaret som kommer tillbaka. cURL har st¨od f¨or internetprotokollen HTTP och HTTPS med flera.

5.2.9 API

Ett applikationsprogrammeringsgr¨anssnitt ¨aven kallat API ¨ar en samling funktioner f¨or styrning eller kontrollering av ett specifikt program eller system. Ett API g¨or det m¨ojligt att interagera med ett system utan att veta detaljerna kring hur specifika funktioner exe-kveras.

5.2.10 JSON

JavaScript Object Notation, f¨orkortat JSON, ¨ar ett textbaserat format som anv¨ands f¨or att utbyta information mellan exempelvis tv˚a system [2]. F¨or ett exempel p˚a hur ett JSON objekt kan se ut, se figur 4 nedan.

5 Metod

5.2.11 PHPUnit

PHPUnit ¨ar ett testramverket f¨or att skriva enhetstester till PHP-kod [9]. PHPUnit har dokumentation om hur olika tester kan utformas, vilket ¨ar en stor hj¨alp vid framtagning av enhetstester.

PHPUnit har st¨od f¨or att skapa ”mock-objekt”. Dessa objekt kan ses som att en ex-isterande funktion skrivs ¨over och byts ut mot en funktion som i grunden inte g¨or n˚agonting [16, sida 522]. Objekten kan redigeras till att bete sig p˚a olika s¨att. Exempel-vis kan objekten kontrollera att funktionen tillkallas ett ¨onskv¨art antal g˚anger. V¨ardet p˚a dess inparametrar kan ¨aven testas s˚a att de st¨ammer ¨overens med de inparametrar funk-tionen borde f˚a in. Eftersom mock-funkfunk-tionen inte g¨or n˚agonting best¨ammer testaren vad funktionen ska returnera.

Det h¨ar s¨attet att testa ¨ar anv¨andbart n¨ar funktionen som ska testas tillkallar andra funk-tioner, som i sin tur ¨ar beroende av en uppkoppling till ett externt system [16, sida 522]. Med ett mock-objekt g˚ar logiken i funktionen att testas, utan att beh¨ova ta h¨ansyn till dessa beroenden. I figur 5 nedan visas ett exempel p˚a ett enhetstest med mock-objekt.

5 Metod

Figur 5: Exempel p˚a enhetstest med mock-objekt

P˚a rad 5 och 8 tillkallas funktioner som har ett beroende som vill undvikas

P˚a rad 22, 26 och 31 best¨ams vilka funktioner som ska bytas ut till mock-funktioner P˚a rad 27 och 32 kontrolleras att funktionerna f˚ar r¨att inparametrar

6 Systemstruktur

6

Systemstruktur

V˚art system best˚ar av en databas och tv˚a olika webbgr¨anssnitt. Ett f¨or tidsredovisnings-systemet Timesheet och ett f¨or bokf¨oringstidsredovisnings-systemet Fortnox. I denna sektion g˚ar vi in p˚a hur dessa delar av v˚art system ¨ar utformande och hur de kommunicerar med varandra.

6.1

Kommunikationskanaler

I b¨orjan av projektet ˚aterfanns ingen kommunikation mellan Timesheet och Fortnox, utan de var helt frikopplade fr˚an varandra. Genom att anropa Fortnox API lyckades vi skapa en kommunikationskanal mellan Fortnox och Timesheet. Med hj¨alp av den-na kommunikationskaden-nal kan vi h¨amta ner information fr˚an Fortnox och skriva denden-na information till Consodens databas samt skriva information fr˚an Timesheet till Fortnox. En kommunikationskanal mellan databasen och Timesheet fanns implementerad fr˚an projektets start. Den kommunikationskanalen bygger p˚a att Timesheet g¨or PHP anrop inneh˚allande SQL-f¨orfr˚agningar. Illustration ¨over den t¨ankta systemstrukturen kan ses i figur 6 nedan.

6 Systemstruktur

6.2

Gr ¨anssnitt

B˚ade Timesheet och Fortnox hade fr˚an b¨orjan ett webbaserat anv¨andargr¨anssnitt som kunde anv¨andas. I Fortnox fanns ingen m¨ojlighet till att manipulera gr¨anssnittet. I Ti-mesheet kunde vi d¨aremot bygga ut gr¨anssnittet till att passa v˚ara behov. Nya funktioner implementerades i Timesheets gr¨anssnitt f¨or att med hj¨alp av ett knapptryck kunna syn-kronisera klienter och projekt direkt till Fortnox via deras API. En knapp som synkro-niserar all leverant¨orsinformation fr˚an Fortnox till Timesheet har ¨aven implementerats.

6.3

Databas

Till v˚art f¨orfogande fick vi ¨aven en databas skriven i MySQL-motorn myISAM [25]. MyISAM till˚ater ej anv¨andandet av fr¨ammande nycklar, som anv¨ands f¨or att l¨anka samman tv˚a tabeller. Consoden hade i sin kravspecifikation en ¨onskan om att anv¨anda fr¨ammande nycklar. De nya databastabellerna skapades d¨arf¨or i motorn InnoDB som har st¨od f¨or fr¨ammande nycklar [24]. Databasen var fylld med p˚ahittad data p˚a grund av att deras riktiga data ¨ar sekretessbelagd. Datan var f¨ordelad ¨over 28 tabeller. Av dessa tabeller fokuserade vi uteslutande p˚a klienttabellen och projekttabellen. Dessa tabeller ut¨okades med information som ans˚ags vara n¨odv¨andig f¨or att synkronisera Timesheet med Fortnox. Ett exempel p˚a en s˚adan ut¨okning ¨ar en tidsst¨ampel f¨or varje klient i data-basen. Information om n¨ar klienten senast synkroniserades med Fortnox kan d˚a avl¨asas. Vi ut¨okade ¨aven databasen med information som ans˚ags vara viktig f¨or klienter, projekt samt leverant¨orer. Databasen kompletterades med kolumner som organisationsnummer och landskod. ¨Andringar likt dessa kr¨avde uppdatering av Timesheets gr¨anssnitt f¨or att visualisera den nya informationen. Sidor d¨ar man l¨agger till nya klienter och projekt beh¨ovde ut¨okas med st¨od f¨or att hantera informationen som hamnade i de nya kolum-nerna.

6.4

Anv ¨andare

Alla anst¨allda har ett konto kopplat till Timesheet. Anv¨andare utan ett konto kommer allts˚a inte ha n˚agon tillg˚ang till systemet. Detta medf¨or att slutanv¨andarna i v˚art fall uteslutande ¨ar personer som ¨ar anst¨allda p˚a Consoden. Vissa anst¨allda har d¨aremot st¨orre r¨attigheter ¨an andra, som exempelvis administrationsr¨attigheter till Timesheet. Till Consodens konto p˚a Fortnox har endast de ekonomiskt ansvariga p˚a Consonden tillg˚ang.

7 Krav och utv¨arderingsmetoder

7

Krav och utv ¨arderingsmetoder

Under hela projektet har vi kollaborerat med Consoden. D¨arf¨or har f¨oljande krav och utv¨arderingsmetoder framtagits i samarbete med Consoden.

7.1

Funktionella Krav

F¨oljande ¨ar kraven f¨or att projektl¨osningen ska ses som funktionell:

• Kunna erbjuda anv¨andare och utvecklare en funktionell synkroniseringsl¨osning mellan Timesheet och Fortnox, d¨ar funktionell definieras som f¨oljande:

– Ingen data ska korrumperas i ¨overf¨oringen

– Data fr˚an ett informationsf¨alt i Timesheet ska ¨overf¨oras till motsvarande in-formationsf¨alt i Fortnox.

– Om flera objekt synkroniseras och uppkoppling mellan Timesheet och Fort-nox upph¨or ska inga objekt som synkroniserats upp till den punkten korrum-peras eller f¨orsvinna.

– Om ett objekt misslyckas att synkroniseras ska synkroniseringen genast av-brytas.

– Varje synkronisering ska loggas i databasen. • Ha ett sammankopplat system, d¨ar:

– Timesheet ska kunna kommunicera med databasen via SQL-f¨orfr˚agningar. – Timesheet ska kunna g¨ora API-kall till Fortnox och hantera svaret.

• Synkroniseringsfunktionerna ska endast kunna anv¨andas av anv¨andare inloggade i Timesheet

• Alla inskrivningar i databasen ska anv¨anda f¨orberedda p˚ast˚aenden f¨or att ¨oka s¨akerheten.

7 Krav och utv¨arderingsmetoder

Ut¨over de funktionella kraven b¨or f¨oljande krav uppfyllas f¨or att kunna se projektet som lyckat:

• Alla funktioner som ut¨okat funktionaliteten i Timesheet ska dokumenteras enligt den standard som visas i figur 7 nedan.

Figur 7: Kommentarstandard som anv¨ants f¨or funktionskommentarer

7.2

Krav p ˚a relevanta informationsf ¨alt

De klientuppgifter som har krav p˚a synkronisering ¨ar f¨oljande: klientidentifierare, orga-nisationsnamn, organisationsnummer, beskrivning, adress, stad, landskod, postnummer, E-mail, telefonnummer, faxnummer samt hemsida.

De projektuppgifter som har krav p˚a synkronisering ¨ar f¨oljande: projektnummer, pro-jektnamn, beskrivning, startdatum, slutdatum, projektstatus samt projektledare.

De leverant¨orsuppgifter som har krav p˚a synkronisering ¨ar: leverant¨orsnummer, leve-rant¨orsnamn, telefonnummer, E-mail, Consodens referens samt leverant¨orens referens.

7.3

Krav om snabbhet och antal anv ¨andare

Synkroniseringen mellan de tv˚a systemen samt h¨amtningen av data fr˚an Fortnox beh¨over inte vara optimerad f¨or att g˚a fort. Fokus ligger p˚a att datan som ¨overf¨ors ska vara kor-rekt och att ingen information f¨orsvinner vid synkroniseringen. Det finns inga krav p˚a att flera anv¨andare ska kunna utf¨ora en synkronisering samtidigt.

8 Teknisk implementation

7.4

Utv ¨arderingsmetod

Informationen som innefattas av kravspecifikationen har en best¨amd plats i Consodens databas och i Fortnox. N¨ar informationen synkroniseras vet vi vart information kommer ifr˚an och p˚a vilken plats den b¨or skrivas till. D¨armed kan detta kontrolleras manuellt efter utf¨ord synkronisering. Om information korrumperats, f¨orsvunnit eller hamnat p˚a o¨onskad plats ses det som ett misslyckande.

Under en synkronisering av flera objekt kan internet kopplas bort f¨or att kontrollera att de objekt som synkroniserats upp till den tidspunkten inte korrumperats eller f¨orsvunnit. F¨or att unders¨oka ifall synkroniseringen avbryts om ett objekt misslyckas att synkroni-seras kan information som bryter mot Fortnox API l¨aggas till i ett objekt. Ett exempel ¨ar E-mail f¨or klient d¨ar Fortnox API kr¨aver att E-mailen inneh˚aller ett ’@’ tecken. F¨or att kontrollera att varje synkronisering loggas i databasen kommer en klient och ett projekt att l¨aggas till, editeras och tas bort via gr¨anssnittet. Genom databasen kontrolle-ras sedan att allt loggas.

Om de tidigare n¨amnda unders¨okningarna lyckats betyder det att systemen ¨ar samman-kopplade och att Timesheet kan kommunicera med databasen via SQL-f¨orfr˚agningar. Det indikerar ¨aven att Timesheet kan g¨ora API-kall till Fortnox och hantera svaret d¨arifr˚an, eftersom att svaret kan loggas i databasen.

Att alla injektioner i databasen anv¨ander f¨orberedda p˚ast˚aenden kan man utv¨ardera ge-nom att kolla igege-nom koden och kontrollera att det st¨ammer. Med samma metod g˚ar det att kontrollera att alla funktioner ¨ar kommenterade och f¨oljer standarden vi valt.

8

Teknisk implementation

F¨or att lyckas integrera Timesheet med Fortnox m˚aste flertalet tekniska problem l¨osas. All information i Timesheet ¨ar inte anv¨andbar i faktureringssyfte och d¨arf¨or b¨or en-dast relevant information extraheras. Relevant information baseras p˚a den fakturamall som Consoden genererar i Timesheet vid sin manuella fakturering i dagsl¨aget, se fi-gur 8 nedan. F¨or att importera informationen till Fortnox kr¨avs det att den extraherade informationen konverteras till ett passande dataformat, i v˚art fall JSON. Efter att in-formationen konverterats m˚aste den importeras till Fortnox. Det ¨ar av stor vikt att test-funktioner utformas f¨or att se till att ingen information f¨orsvinner eller korrumperas i

9 Implementation

Hela informations¨overf¨oringen ska presenteras som ett API f¨or Consonden. Consonden ska ha m¨ojligheten att anv¨anda dessa funktioner f¨or att generera fakturor baserade p˚a den information de har i Timesheet.

Figur 8: Fakturamall skapad i Timesheet

9

Implementation

F¨or att ˚astadkomma en lyckad implementation av en integration mellan Timesheet och Fortnox arbetade vi systematisk med olika arbetsblock. I denna sektion g˚ar vi igenom alla dessa arbetsblock och beskriver hur arbetet gick till.

9 Implementation

9.1

Bakgrundsarbete

F¨or att kunna synkronisera Timesheet och Fortnox kr¨avs en lista p˚a vilken information som ¨ar relevant f¨or Consoden samt vilken information som Fortnox till˚ater att ¨andra via sitt API. F¨or att ta reda p˚a detta f¨orde vi en diskussion med Consoden i syftet att komma fram med en lista p˚a information de skulle vilja ha i sin databas och i Timesheet. Denna information j¨amf¨ordes sedan med de informationsf¨alt som Fortnox har tillg¨angliga via deras API-kall.

9.2

Uppdatering av Databas

Databasen k¨ordes p˚a MySQL-motorn MyISAM som ej st¨odjer fr¨ammande nycklar, att anv¨anda fr¨ammande nycklar var ett krav fr˚an Consoden. De nya tabellerna skapades d¨arf¨or i SQL-motorn InnoDB genom SQL-f¨orfr˚agan SET default storage engine = In-noDB. Informationsf¨alt som Consoden ans˚ag vara ¨overfl¨odiga togs bort ur databasen med hj¨alp av SQL-f¨orfr˚agningar. Informationsf¨alt som saknades i databasen men som ans˚ags essentiella av Consoden i synkroniseringsarbetet skrevs in i databasen via SQL-f¨orfr˚agningar. Innan vi skrev in de nya informationsf¨alten i databasen unders¨okte vi att Fortnox faktiskt hade st¨od f¨or motsvarande informationsf¨alt i sina API-kall. Annars hade dessa informationsf¨alt varit redundanta i synkroniseringsarbetet.

De informationsf¨alt som Consoden anser vara v¨asentliga f¨or klientuppgifter ¨ar: klient-id som anv¨ands f¨or att klient-identifiera en klient, organisationsnamn, organisationsnummer, beskrivning, adress, stad, landskod, postnummer, E-mail, telefonnummer, faxnummer, sekund¨art telefonnummer, hemsida och sekund¨ar adress.

De informationsf¨alt som Consoden anser v¨asentliga f¨or projektuppgifter ¨ar: projektnum-mer som ¨ar ett internt numprojektnum-mer Consoden anv¨ander f¨or att identifiera projektet, projekt-namn, kommentarer, startdatum, slutdatum, status, projektledare samt kontaktperson till klienten som best¨allt projektet.

De informationsf¨alt som ing˚ar i leverant¨orsuppgifter ¨ar de f¨alt som Consoden anser sig beh¨ova f¨or att m¨ojligg¨ora vidarefakturering n¨ar man anv¨ander sig av en tredjepart i projekt. De kolumner som anv¨ands ¨ar: leverant¨orsnummer som ¨ar ett internt nummer Consoden anv¨ander f¨or att identifiera leverant¨oren, leverant¨orsnamn, telefonnummer, E-mail, Consodens referensperson och leverant¨orens referensperson.

9 Implementation

9.3

Synkronisering av klientuppgifter

En automatisk synkronisering av klientuppgifter mellan Timesheet och Fortnox imple-menterades vid skapande, editering och borttagning av en klient. Det som sker vid syn-kroniseringen ¨ar att en funktion h¨amtar det id som identifierar klienten i Consodens databas. D¨arefter h¨amtas all relevant information tillh¨orande den klienten ner till en ar-ray via SQL-f¨orfr˚agningar. Fortnox kr¨aver specifika rubriker p˚a den information som skall skickas och d˚a Consoden samt Fortnox ej anv¨ander samma rubriker p˚a sina infor-mationsf¨alt m˚aste varje index i arrayen flyttas till en ny array d¨ar varje index ¨ar d¨opt efter Fortnox rubriker. Informationen kodas sedan om till ett JSON-object och skickas till Fortnox via ett cURL-anrop. Om anv¨andaren v¨aljer att skapa en ny klient i Times-heet skrivs informationen f¨orst till databasen f¨or att sedan b¨orja synkroniseringen. Om anv¨andaren v¨aljer att editera en klient i Timesheet kollar en funktion f¨orst att klienten finns i Fortnox. Om klienten inte finns i Fortnox skapas det en ny klient. Om klienten finns i Fortnox editeras den. Vid borttagning kollar en funktion om klienten existerar och tar bort den ifall den finns i Fortnox.

9.4

Synkronisering av projektuppgifter

Vid synkronisering av projektuppgifter sker en liknande process som vid synkronise-ring av klientuppgifter. De funktioner som hanterar en synkronisesynkronise-ring av klientuppgif-ter anropas i samma ordning d˚a funktionerna ¨ar generellt byggda f¨or att kunna hanklientuppgif-tera b˚ade projektuppgifter och klientuppgifter. Det som skiljer de b˚ada ˚at ¨ar att f¨or pro-jektuppgifter h¨amtas informationen fr˚an en annan tabell i databasen och informationen struktureras om annorlunda f¨or att Fortnox hanterar klientuppgifter och projektuppgif-ter annorlunda. Att ediprojektuppgif-tera ett projekt i Timesheet fungerar likadant som att ediprojektuppgif-tera en klient och samma g¨aller borttagning.

9 Implementation

9.5

Synkronisering av leverant ¨

orsuppgifter

Vid synkronisering av leverant¨orsuppgifter anropas en funktion via Timesheets anv¨andar-gr¨anssnitt. Alla leverant¨ors-id som existerar i Fortnox h¨amtas ner genom ett API-kall och sparas i en array. Arrayen med ids loopas igenom och all information tillh¨orande varje id h¨amtas ner som ett JSON-objekt. JSON-objektet avkodas och informationen sparas i en array. Som f¨or klientuppgifter och projektuppgifter har Consoden och Fort-nox olika namn p˚a rubrikerna som h¨or till informationen i leverant¨orsuppgifter. F¨or leverant¨orsuppgifter mappas informationen fr˚an de rubriker som Fortnox anv¨ander till en ny array med de rubriker som Consoden anv¨ander i sin databas.

Tabellen inneh˚allande alla id f¨or leverant¨orer h¨amtas genom SQL-f¨orfr˚agningar. Det id tillh¨orande den h¨amtade leverant¨oren fr˚an Fortnox kontrolleras mot Consodens databas. Om det id existerar i Consodens databas uppdateras informationen med SQL-f¨orfr˚agan UPDATE, om det id inte existerar skrivs en ny leverant¨or in i databasen genom SQL-f¨orfr˚agan INSERT.

9.6

Loggning av synkronisering

All aktivitet i Timesheet som har med synkronisering att g¨ora loggas i en tabell i Conso-dens databas. Det inneb¨ar att varje synkronisering av en klient, ett projekt eller en leve-rant¨or skrivs in till databasen tillsammans med en HTTP-svarskod, id p˚a det synkroni-serade objektet, anv¨andarnamnet i Timesheet p˚a den som gjorde synkroniseringen samt tiden n¨ar synkroniseringen utf¨ordes.

N¨ar Fortnox API anropas ger det tillbaka en HTTP-svarskod. HTTP-svarskoden sparas i en variabel, det id p˚a objektet som synkroniseras sparas i en variabel. Anv¨andarnamnet p˚a den som ¨ar inloggad i Timesheet h¨amtas fr˚an Consodens databas. Tiden n¨ar synkro-nisering gjordes registreras som det klockslaget n¨ar servern utf¨orde SQL-f¨orfr˚agan. All denna information sparas i en egen tabell i databasen.

9 Implementation

9.7

Misslyckad synkronisering

Vid varje anrop till Fortnox API returneras en HTTP-svarskod, om svarskoden ¨ar i span-net 200-299 betyder det att anropet ¨ar lyckat, om svarskoden ¨ar i spanspan-net 400-499 bety-der det att anropet misslyckats.

Svarskoden f¨or varje anrop sparas och analyseras. Om svarskoden ¨ar i spannet 400-499 avbryts synkroniseringen av det ber¨orda objektet. Vid en lyckad synkronisering skrivs HTTP-svarskoden, id, anv¨andarnamn och tid in i Consodens loggtabell. Tabellen ¨ar till f¨or att underl¨atta vid fels¨okning av det objekt som misslyckades att synkroniseras. Om flera objekt ligger i k¨o f¨or att synkroniseras avbryts detta f¨or att f¨orhindra att infor-mationen p˚a n˚agot s¨att korrumperas eller skrivs till en plats som ¨ar ¨amnad f¨or annan information.

9.8

Testning av l ¨

osningen

Till alla funktioner som p˚a ett eller annat s¨att tillkallar Fortnox API eller Consodens databas skrivs enhetstester med mock-objekt f¨or att undvika att inneh˚allet i Fortnox och databasen p˚averkas av testen. Logiken i funktionerna ¨ar det som testas och ett flertal olika test skrivs till varje funktion f¨or att t¨acka upp alla villkorssatser. Funktionerna testas ¨aven f¨or de misslyckade fallen. Testerna k¨ors inte helt automatiskt utan f¨or att k¨ora testerna skrivs kommandot ”phpunit testets filnamn.php” i terminalen.

10 Resultat

10

Resultat

Detta projekt har konkret resulterat i att tidsredovisningssystemet Timesheet har inte-grerats med bokf¨oringssystemet Fortnox. Integreringen har utformats enligt de uppsatta kraven p˚a projektet. Nedan f¨oljer ett mer djupg˚aende resultat av de olika delar som projektet innefattar.

10.1

Synkronisering av Klientuppgifter

Synkronisering av Klientuppgifter fr˚an Timesheet till Fortnox ¨ar implementerat. Figur 9 nedan visar klientinformation i Timesheet f¨ore synkronisering. Figur 10 nedan visar kli-entinformation i Fortnox efter synkronisering. De informationsf¨alt som synkroniseras ¨ar f¨oljande: 1.Klientnamn, 2.Organisationsnummer, 3.Beskrivning, 4.Adress, 5.Stad, 6.Land, 7.E-mail, 8.Telefonnummer, 9.Faxnummer och 10.Hemsida. Dessa f¨alt utg¨or kravspecifikationen f¨or klientuppgifter.

10 Resultat

Figur 10: Klientuppgifter i Fortnox efter synkronisering. * ¨ar ett automatiskt v¨axande kundnummer fr˚an Fortnox

10.2

Synkronisering av Projektuppgifter

Synkronisering av Projektuppgifter fr˚an Timesheet till Fortnox ¨ar implementerat. Fi-gur 11 nedan visar projektinformation i Timesheet f¨ore synkronisering. FiFi-gur 12 nedan visar projektinformation i Fortnox efter synkronisering. De informationsf¨alt som syn-kroniseras ¨ar f¨oljande: 1.Projektnummer, 2.Projektnamn, 3.Beskrivning, 4.Startdatum, 5.Slutdatum, 6.Status och 7.Projektledare. Dessa f¨alt utg¨or kravspecifikationen f¨or pro-jektuppgifter.

10 Resultat

10 Resultat

10.3

Synkronisering av Leverant ¨

orsuppgifter

Synkronisering av leverant¨orsuppgifter fr˚an Fortnox till databasen ¨ar implementerat. In-formationen visas inte i Timesheet. Figur 13 nedan visar leverant¨orsuppgifter i Fortnox f¨ore synkronisering. Figur 14 nedan visar leverant¨orsuppgifter i databasen efter syn-kronisering. De informationsf¨alt som synkroniseras ¨ar f¨oljande: 1.Leverant¨orsnummer, 2.Leverant¨orsnamn, 3. Organisationsnummer, 4.Telefonnummer, 5.E-mail, 6.Consodens referens.

Figur 13: Leverant¨orsuppgifter i Fortnox innan synkronisering

11 Diskussion

10.4

Loggning av synkronisering

Figur 15 nedan visar hur alla synkroniseringar loggas i Consodens databas med HTTP-svarskod, id p˚a det synkroniserade objektet, anv¨andaren som gjorde synkroniseringen samt tid n¨ar synkroniseringen utf¨ordes per kravspecifikation

Figur 15: Loggning av synkronisering

10.5

Enhetstester

Alla funktioner har enhetstester som t¨acker samtliga villkorssatser samt negativa utfall. Alla tester lyckas vid exekvering.

11

Diskussion

Alla v˚ara krav ¨ar uppfyllda per kravspecifikation. Klientuppgifter och projektuppgifter g˚ar att synkronisera fr˚an Timesheet till Fortnox. Leverant¨orsuppgifter g˚ar att synkroni-sera fr˚an Fortnox till Timesheet. Alla f¨alt som Consoden markerat som relevanta och som Fortnox API har st¨od f¨or g˚ar att synkronisera.

Huvudfokus fr˚an v˚ar sida i detta projekt har varit att se till att ingen ¨overf¨ord infor-mation korrumperas i synkroniseringen. Detta har lett till att arbetet med att h˚alla ner exekveringstiden f¨or synkroniseringen medvetet har hamnat ur fokus. Att synkronisera st¨orre m¨angder information ¨ar en tidskr¨avande operation och i dagsl¨aget tar det l˚ang tid att synkronisera klienter, projekt och leverant¨orer. En synkronisering av till exempel 750 projekt tar ungef¨ar 5 minuter. Allts˚a tar synkroniseringen av ett projekt cirka 0,4 sekunder. En synkroniseringstid p˚a under 0,1 sekunder per objekt hade varit att f¨oredra. Trots att inget maxtak g¨allande synkroniseringstiden ˚aterfanns i kravspecifikationen ¨ar

11 Diskussion

Under projektets g˚ang har alla gruppmedlemmar arbetat i olika operativsystem. Anv¨and-andet av Linux-Ubuntu och MacOS har medf¨ort vissa kompatibilitetsproblem. Grund-inst¨allningarna f¨or programmeringsspr˚aket PHP skiljde sig mellan Ubuntu och MacOS. Det tydligaste exemplet p˚a detta var att i Ubuntu kunde man inte b¨orja ett PHP-block med det f¨orkortade skrivs¨attet ”<?”, utan beh¨ovde anv¨anda det f¨orl¨angda skrivs¨attet ”<? php”. Skrivs¨attet anv¨ands n¨ar man ska initiera ett block d¨ar man anv¨ander pro-grammeringsspr˚aket PHP. Detta blev p˚atagligt n¨ar redan existerande kod som anv¨ande det skrivs¨attet skulle modifieras. Vissa l¨osningar som fungerade p˚a MacOS fungerade d˚a inte p˚a Ubuntu och vice versa.

Kompatibilitetsproblem uppstod ¨aven n¨ar Timesheet skrev till databasen. Detta till f¨oljd av att MySQL var olika strikt g¨allande inskrivning av data till databasen beroende p˚a operativsystem. Om en kolumn var satt till att inte ta in n˚agot null-v¨arde tolkades det oli-ka av Ubuntu och MacOS. Tomma inskrivningar till kolumnen, inskrivningar som sak-nade ett v¨arde, till¨ats d˚a inte av Ubuntu. D¨aremot till¨ats denna inskrivning p˚a MacOS:et. Detta ledde till att vi beh¨ovde modifiera stora delar av databasen f¨or att den skulle fun-gera f¨or b˚ada operativsystemen. En smidigare l¨osning p˚a dessa kompatibilitetsproblem hade varit om alla i gruppen hade jobbat i samma operativsystem. En ¨annu b¨attre l¨osning hade varit att fr˚an b¨orjan g˚a igenom alla begr¨ansningar, relaterat till arbetet, inom var-je operativsystem. Utifr˚an den kunskapen hade vi kunnat uppr¨atta en mer universell l¨osningsmetod. Tiden det tog att fels¨oka problem orsakade av kompatibilitetsproblem hade d˚a kunnat minimeras.

Att leverant¨orsuppgifter skulle finnas med i Timesheets gr¨anssnitt ingick inte i kravspe-cifikation. D¨arf¨or ˚aterfinns den informationen endast i databasen.

V˚ar l¨osning f¨or att synkronisera Timesheet och Fortnox ledde oss till en point-to-point integration. Med hj¨alp av l¨osningen kan Timesheet och Fortnox kommunicera med varandra direkt, utan mellanhand. Alternativet hade vart att skapa ett middleware. Att ha ett middleware som ¨overs¨atter informationen som kommer in ¨ar anv¨andbart n¨ar mer ¨an tv˚a system kommunicerar med varandra. Detta g¨or middleware till en mer komplex l¨osning p˚a ett integrationsproblem ¨an vad en point-to-point l¨osning ¨ar. D˚a Consoden enbart hade tv˚a system som skulle integreras s˚ag vi ingen anledning att utveckla en middleware-l¨osning med f¨orm˚agan att kunna hantera fler kommunikationer. Man kan argumentera f¨or att det hade varit en mer framtidss¨akrad l¨osning att implementera en middleware-l¨osning om Consoden i framtiden skulle vilja integrera fler system. Vi har diskuterat detta med Consoden och f˚att svaret att de inte har planer p˚a att integrera fler system i framtiden. Vi ans˚ag d¨arf¨or att en point-to-point-l¨osning var det som passade Consodens behov b¨ast.

12 Slutsats

12

Slutsats

Vi har skapat en l¨osning f¨or att integrera tidsredovisningssystemet Timesheet och fak-tureringssystemet Fortnox. De tv˚a systemen kan kommunicera direkt med varandra ge-nom att anropa de funktioner som vi har skapat. Uppgifter f¨or klienter och projekt g˚ar att synkronisera fr˚an Timesheet till Fortnox. Leverant¨orsuppgifter g˚ar att synkronisera fr˚an Fortnox till Consodens databas. Leverant¨orsuppgifterna g˚ar ej att se i gr¨anssnittet. Synkroniseringen loggas i en databas med anv¨andarens inloggningsnamn, HTTP-svarskod, id p˚a det synkroniserade objektet och tidsst¨ampel f¨or synkroniseringen. Funktionerna som utf¨or all kommunikation mellan de tv˚a systemen testas genom enhetstester.

Projektl¨osningen skapar en automatisk ¨overf¨oring av information mellan tv˚a system d¨ar informationen tidigare f¨ordes ¨over manuellt. Resultatet av detta blir att processen g˚ar snabbare och risken f¨or fel minskar. De funktioner som inneh˚alls i v˚ar l¨osning ¨ar generaliserade f¨or att Consoden ska kunna vidareutveckla dem vid behov.

Den generella problematiken kring synkronisering mellan ett godtyckligt system och Fortnox som projektet har l¨ost ¨ar f¨oljande:

• Identifiera vilken typ av synkronisering som kr¨avs:

V˚art val f¨oll p˚a Point-to-point f¨or att det endast va tv˚a system att synkronisera. • Identifiera vilken information som ska synkroniseras:

I v˚art fall information g¨allande klient, projekt, samt leverant¨orsuppgifter lagrade i en databas och Fortnox system.

• Uppr¨atta en kommunikationskanal mellan de tv˚a systemen:

Vi designade funktioner som anv¨ande sig av HTTP-anrop via cURL. • Kontrollera att informationen som skickas inte korrumperas p˚a v¨agen:

Informationen som skickades kontrollerades med enhetstester samt manuell kon-troll.

V˚art projekt kan anv¨andas av andra f¨oretag som vill synkronisera ett godtyckligt tidsre-dovisningssystem med Fortnox.

13 Framtida arbete

13

Framtida arbete

I nul¨aget ¨ar exekveringstiden g¨allande synkroniseringen mellan Timesheet och Fortnox en l˚angsam process. I framtiden skulle denna process kunna optimeras och dra ner ex-ekveringstiden. Detta skulle leda till en b¨attre upplevelse f¨or anv¨andaren d˚a den slipper on¨odiga v¨antetider. Ett s¨att att l¨osa detta ¨ar att spara uppkoppling till databasen ist¨allet f¨or att uppr¨atta en ny uppkoppling varje g˚ang man extraherar n˚agot ur databasen. En vidareutveckling av systemet ¨ar att l¨agga till en funktionalitet som automatiskt gene-rar fakturor utifr˚an de klient- och projektuppgifter som finns i Timesheet. Detta skulle kunna l¨osas med hj¨alp av Fortnox API d¨ar det finns st¨od f¨or att generera fakturor. Det finns ¨aven en m¨ojlighet att implementera en automatisering av synkroniseringen mellan Timesheet och Fortnox. Det vill s¨aga att systemet kontinuerligt kontrollerar, till exempel tv˚a g˚anger om dagen, om alla klienter och projekt som finns i Timesheet ¨aven finns i Fortnox. Om n˚agon klient eller n˚agot projekt d˚a skulle saknas s¨atts automatisk en synkronisering mellan systemen ig˚ang.

En utbyggnad av synkroniseringen mellan Fortnox och Timesheet ¨ar att h¨amta ner de le-verant¨orsfakturor som finns i Fortnox f¨or att sedan infoga dessa i Timesheet. Anv¨andare av Timesheet skulle d˚a inte beh¨ova logga in p˚a Fortnox f¨or att se vilka leverant¨orsfakturor som finns till f¨orfogande.

Referenser

Referenser

[1] “Entiros,” http://www.entiros.se, [Online; accessed 28/3-17].

[2] “Introducing JSON,” http://www.json.org/, [Online; accessed 20/3-17].

[3] “Sogeti,” https://www.sogeti.se/losningar/systemintegration/, [Online; accessed 28/3-17].

[4] “Trivec,” http://www.trivec.se/fortnox-integration/, [Online; accessed 23/3-17]. [5] “MySQL 5.7 Reference Manual,” MySQL5.7ReferenceManual, 2017.

[6] M. Achour, F. Betz, A. Dovgal, N. Lopes, H. Magnusson, G. Richter, D. Seguy, and J. Vrana, “PHP Manual,” http://php.net/manual/en/, 2017, [Online; accessed 20/4-17].

[7] A. Arasteh, A. Aliahmadi, H. Mahmoodi, and M. Mohammadpour, “Role of in-formation technology in business revolution,” https://link-springer-com.ezproxy. its.uu.se/article/10.1007%2Fs00170-010-2834-9, 2011, the International Journal of Advanced Manufacturing Technology, March 2011, Volume 53, Issue 1, pp 411–420.

[8] F. L. Bauer, L. Bolliet, H. J. Helms, P. Naur, and B. Randell, “Nato soft-ware engineering conference,” http://homepages.cs.ncl.ac.uk/brian.randell/NATO/ nato1968.PDF, 1968, [Online; accessed 20/4-17].

[9] S. Bergmann, “PHPUnit,” https://phpunit.de/index.html, [Online; accessed 11/5-17].

[10] I. Boivie, “A fine balance : Addressing usability and users’ needs in the deve-lopment of it systems for the workplace,” Ph.D. dissertation, Uppsala Universi-ty, Division of Human-Computer Interaction, Human-Computer Interaction, 2005, http://www.diva-portal.org/smash/get/diva2:167026/FULLTEXT01.pdf.

[11] A. Curl and K. Fertalj, “A review of enterprise it integration methods,” in Procee-dings of the ITI 2009 31st International Conference on Information Technology Interfaces, June 2009, pp. 107–112.

[12] M. Fowler, K. Beck, and G. Erich, “Refactoring: improving the design of existing code,” Addison-Wesley, 2000.

Referenser

ne; accessed 20/4-17].

[14] D. Huizinga and A. Kolawa, “Automated defect prevention: Best practices in soft-ware management,” John Wiley & Sons Inc, 2007.

[15] Z. Ives, A. Halevy, and A. Doan, “Principles of data integration,” Elsevier Science, pp. 6–9, 2012.

[16] G. Meszaros, “xunit test patterns: Refactoring test code,” Pearson Education, 2007.

[17] Bj¨orn Westr¨om, “Handledare consoden,” bjorn.westrom@consoden.se. [18] Christo El Morr, “It integration and patient safety: The case of a software tool,”

Procedia computer science, 2016.

[19] D. Richard Kuhn, “On the effective use of software standards in systems integra-tion,” Proceedings of 1st International Conference on Systems Integration. IEEE Computer Society Press, vol. 1, pp. 455–461, 1990.

[20] IBM, “IBM,” http://www-03.ibm.com/software/products/en/category/ connectivity-and-integration, [Online; accessed 8/4-17].

[21] ——, “IBM MQ,” ”http://www-03.ibm.com/software/products/en/ibm-mq. [22] ——, “IBM Case study, Middleware,” https://www-01.ibm.com/

common/ssi/cgi-bin/ssialias?%20%20subtype=AB&infotype=PM&htmlfid= MSC03014USEN&attachment=MSC03014USEN.PDF, December, 2015, [Onli-ne; accessed 6/4-17].

[23] netSuite, “System integration,” http://www.netsuite.com/portal/resource/articles/ software-system.shtml, [Online; accessed 20/4-17].

[24] Oracle, “InnoDB,” https://dev.mysql.com/doc/refman/5.7/en/innodb-introduction. html, [Online; accessed 8/5-17].

[25] ——, “myISAM,” https://dev.mysql.com/doc/refman/5.7/en/ myisam-storage-engine.html, [Online; accessed 8/5-17].

[26] The internet society, “HTTP-responssvar,” https://tools.ietf.org/html/rfc2616# page-39, 1999, [Online; accessed 8/5-17].

[27] ——, “Hyper Text Protocol,” https://tools.ietf.org/html/rfc2616#page-12, 1999, [Online; accessed 8/5-17].

”http://www.php.net/ChangeLog-Referenser

7.php#7.0.0”, 2015, [Online; accessed 11/5-17].

[29] D. Risimi´c, “An integration strategy for large enterprises,” Yugoslav Journal of Operations Research, vol. 17, no. 2, 2007.

[30] V. Stavridou, “Integration in software intensive systems,” The Journal of Systems & Software, 1999, Volym 48, Nummer 2, 1999.

[31] D. Stenberg, “Curl,” https://curl.haxx.se/, [Online; accessed 8/5-17].

[32] B. Wang, H. Liu, and J. Song, “Saas-based enterprise application integration approach and case study,” The Journal of Supercomputing, vol. 72, no. 7, pp. 2833– 2847, 2016. [Online]. Available: http://dx.doi.org/10.1007/s11227-016-1625-y [33] P. Ward and H. Zhou, “Impact of information technology integration and