Prosessdokumentasjon

Transkript

1

2 2 Prosessdokumentasjon

3 Forord Denne rapporten omhandler utviklingsprosessen til hovedprosjektet Produktkvalitet, visitnorway.com. Prosjektet er gjennomført i samarbeid med Creuna våren Vi beskriver her hvilken metodikk vi har fulgt og hvilke verktøy og teknologier vi har brukt. Videre redegjør vi for hvordan vi har jobbet og hvilke valg vi har tatt underveis, før vi til slutt reflekterer over prosessen og resultatet. Grunnet restriksjoner fra produktleverandører og oppdragsgiver er alle API-nøkler i figurene sensurert. For en full forståelse av prosjektet og produktet, anbefales det å lese produktrapporten i tillegg. Der blir det gitt en beskrivelse av det ferdige produktet i sin helhet. Vedlagt finnes en ordliste som beskriver ord og termer brukt i denne rapporten. 3

4 Innhold Forord... 3 Innhold Innledning Bedriften og oppgaven Gruppen Oppdragsgiver Kunde Oppgaven: Produktkvalitet, Visit Norway Avgrensning av oppgaven: mål og rammebetingelser Planlegging og metode Bli kjent med oppgaven Planlegging Utviklingsmetode Arbeidsfordeling Styringsdokumenter Utstyr og verktøy Utstyr Dokumentasjon Kommunikasjon Rammeverk, verktøy og programmeringsspråk Rammeverk Utviklingsverktøy og programmeringsspråk Utviklingsprosessen

5 4.1 Forberedelser og innhenting av informasjon Dataleverandørene Tellus CBIS Innhenting av informasjon Wireframes Diskusjoner Utvikling av domenemodell Innhold i modellen Ekstern id og produktleverandør Media, åpningstider og tredjepartsinfo Kategorier og fasiliteter Modelldiagrammer Implementeringsdetaljer Innhenting og konvertering Arkitektur for henting og konvertering av data Program CBIS Tellus Kategorier og fasiliteter Sletting Persistering Teknologi og valg Lagring til database

6 4.4.3 Oppdatering Forbedring av lagring og oppdatering Sletting Databaselogging Web API Valg av teknologi Implementering Testing Forbedringer og mulige utvidelser Avslutning og resultat Ferdig produkt Kravspesifikasjonens rolle Endringer underveis Oppfyllelse av krav Refleksjon Oppgaven og gjennomføringen Arbeidsmiljø og samarbeid Egenevaluering Konklusjon Kilder Vedlegg Fremdriftsplan Ordliste

7 1 Innledning 1.1 Bedriften og oppgaven Gruppen Gruppen består av Christina Kihlstrøm, Michael Arvanitidis og Gry Siri Eggen. Medlemmene har jobbet sammen tidligere, og kjenner til hverandres styrker og svakheter. Gruppen fant sammen på bakgrunn av gode erfaringer fra tidligere samarbeider, samt felles interesse for hva oppgaven skulle inneholde Oppdragsgiver Creuna er Nordens største digitale byrå med over 300 medarbeidere. De kombinerer strategi, design og teknologi for å skape spennende og innovative løsninger, og har hovedkontor på Skøyen i Oslo. Creuna stiller til disposisjon all program- og maskinvare som trengs for å gjennomføre prosjektet, samt to veiledere; Christian Hochlin og Pelle Bjerkestrand Kunde Kunden i dette prosjektet er Innovasjon Norge, som eier Visit Norway ( Innovasjon Norge arbeider blant annet for å profilere norsk næringsliv og Norge som reisemål, og har som visjon å gi lokale ideer globale muligheter. På Visit Norway, som er Innovasjon Norges turistinformasjonsside og Norges offisielle reiseguide på nett, presenteres informasjon om lokale virksomheter rundt om i hele Norge. Creuna overtok ansvaret for og videreutvikling av Visit Norway i 2013 (Creuna, 2013). Gruppen vil ikke ha noen direkte kontakt med kunden gjennom dette prosjektet; alt foregår via oppdragsgiver Oppgaven: Produktkvalitet, Visit Norway Visit Norway er en av Norges mest besøkte nettsider, og den baserer seg på at lokale virksomheter landet rundt selv produserer presentasjonsmateriale. Innovasjon Norge og Visit Norway fikk tidligere all produktinformasjon fra én ekstern leverandør. Produkter i denne sammenhengen omfatter alt av aktiviteter, arrangementer, hotellopphold, utflukter og lignende som er tilgjengelige via Visit Norway. Disse produktene har forskjellige produkteiere og blir levert gjennom en produktleverandør. Visit Norway har nå fått flere produktleverandører å forholde 7

8 seg til, og ønsker å standardisere formatet på produktdataene som mottas for å lettere kunne håndtere og presentere forskjellige produkter fra forskjellige kilder på likt vis. All relevant produktdata som hentes fra produktleverandørene, ønskes samlet i ett system, som deretter kan være kilde for både nettstedet Visit Norway, Visit Norway-mobilapplikasjon og eventuelt andre eksterne og interne systemer. Prosjektet i sin helhet vil ha behov for Ny domenemodell for produkter Systemarkitektur Persisteringsløsning Produkt-API Integrasjon mot eksisterende løsning Klient for administrasjon av produktdata Sluttbrukerklient for presentasjon av produktdata Prosjektet er hovedsakelig ment som en utforskning av muligheter rundt problemstillingen som resulterer i et forslag på hvordan problemet kan løses, og det er ikke meningen at produktet skal kunne settes direkte i drift etter prosjektets slutt Avgrensning av oppgaven: mål og rammebetingelser I samarbeid med oppdragsgiver har vi avgrenset oppgaven noe, basert på tiden vi har til rådighet. Sammen har vi satt følgende mål: En ny domenemodell for produkter Konvertering av produktdataene fra leverandørene En persisteringsløsning Et produkt-api Oppdragsgiver er åpen for research rundt og bruk av rammeverk, plattformer og produkter, og kunden, Innovasjon Norge, kan tenke seg å ha et åpent API. Vi ble rådet til å la noe av valget rundt teknologier skje under selve prosessen. 8

9 Systemet skal: Hente produktdata fra leverandørene Omgjøre produktdata i henhold til den interne domenemodellen Lagre dataene Gjøre datasettet tilgjengelig via et API Systemet bør: Ha en domenemodell som er basert på den produktinformasjonen som leverandørene har til felles Unngå for mye hull i dataene Kunne kjøres automatisk uten administrator 9

10 2 Planlegging og metode Dette kapittelet presenterer planleggingen av prosjektet, inkludert hvordan vi gikk fram for å bli kjent med oppgaven og rammene rundt. Det inneholder beskrivelse av utviklingsmetode, arbeidsfordeling og hvilke styringsdokumenter som ble brukt i prosessen. 2.1 Bli kjent med oppgaven Oppgaven var fra starten av løst definert av Creuna. De ønsket å se nærmere på produktkvaliteten på visitnorway.com, Innovasjon Norges turistinformasjonsside. Innholdet på siden leveres av flere forskjellige, eksterne leverandører, og på forskjellige formater. Disse dataene ønsket Innovasjon Norge å få over på et standardisert format for å lettere kunne håndtere og presentere produkter fra forskjellige kilder på likt vis. Førsteinntrykket vi hadde var at oppgaven virket svært omfattende, eksisterende løsninger og integrasjon mot eksterne systemer måtte kartlegges og forstås før vi i det hele kunne begynne å jobbe på vår egen løsning. I tillegg var det teknologier vi hadde liten kjennskap til fra før, som for Figur 1 Arbeidstavle fra tidlig i prosessen, med overblikk over forskjellige aktørers rolle i systemet 10

11 eksempel.net Web API, så læringskurven så ut til å måtte bli veldig bratt. På et av de første møtene vi hadde med veilederne fra Creuna etter nyttår fikk vi et overblikk over situasjonen og avklaring på begreper som produkt og produktleverandører. 2.2 Planlegging I første omgang jobbet vi med å få en oversikt over hele prosjektet og bli enige om det praktiske rundt arbeidet fremover. Creuna bisto med lokaler og alt nødvendig utstyr; vi ønsket derfor å utnytte ressursene vi hadde til rådighet så godt som mulig og ble enige om å sette av en kjernetid, hver dag, fem dager i uken til prosjektarbeidet. Denne tiden skulle settes av til å være hos Creuna; deltidsjobber og andre aktiviteter skulle settes utenfor denne tiden. Vi ble også enige med veilederne våre om å ha ukentlige statusmøter hver onsdag morgen, der vi skulle holde dem oppdatert på hvordan vi lå an i forhold til planen vår og om det var noen store utfordringer vi hadde støtt på siden sist Utviklingsmetode Vi har valgt å utvikle ved hjelp av en egendefinert metode som vi føler bruker det viktigste i smidig utvikling, uten at fokus på metode tar for mye tid og ressurser. Basert på evaluering av dette prosjektets omfang har vi hentet elementer fra sentrale smidige utviklingsmetoder, og kuttet ut andre elementer som vi mener ikke er nødvendige. Vi valgte å dele prosjektet inn i fem faser, fire utviklingsinkrementer og en periode med fokus på ferdigstilling av dokumentasjon og presentasjon, se vedlagt fremdriftsplan. Vi lagde en oversikt over milepælene og estimerte hvor lang tid vi så for oss at hver oppgave ville ta. Inspirert av Kanban brukte vi prosjektstyringsprogrammet Jira til å fordele oppgaver, og sørget for at ikke for mange oppgaver var under utvikling om gangen. Fra Extreme Programming ville vi bruke ideen om sømløs integrasjon, som vil si at vi kontinuerlig la til ny kode direkte i prosjektet for å forhindre integrasjonsproblemer. Dette gjorde vi ved å ha en master-gren i versjonshåndteringssystemet som vi hele tiden benyttet oss av og la til kode i. Vi tok også til oss ideen om «collective code ownership», slik at alle står ansvarlige for koden og alle kunne i utgangspunktet gjøre endringer i alle deler av programmet. 11

12 Til slutt benyttet vi oss av daglig standup, eller statusmøter, slik som i Scrum. Her orienterte vi hverandre om hva vi drev med, hva vi var ferdig med, hva vi hadde problemer med og hva vi eventuelt trengte hjelp til. I disse møtene kunne vi også fordele og omprioritere oppgavene, dersom vi så at det var nødvendig Arbeidsfordeling I starten av hver fase delte vi inn det forestående arbeidet i hovedansvarsområder. Deretter fant vi ut av hvor vi burde starte, og tildelte hver person oppgaver. Denne tildelingen skjedde på bakgrunn av både hva man ville jobbe med, hva man hadde jobbet med før og hvor god tid man hadde. Etter hvert som man ble ferdige med sine arbeidsoppgaver, begynte man på det neste som stod på planen i Jira. Videre fordeling og oppgaveprioriteringer snakket vi om på statusmøtene hver morgen Styringsdokumenter Gjennom prosjektet benyttet vi ulike styringsdokumenter for å støtte utviklingsprosessen. I starten av prosjektperioden utarbeidet vi en risikoplan for å være forberedt på eventuelle hindringer som kunne dukke opp underveis. I løpet av de første ukene laget vi også en fremdriftsplan der vi delte prosjektperioden inn i faser med milepæler ved hver faseslutt, og en arbeidsplan som beskrev fasene og hva vi skulle ha klart når disse var ferdige. Videre utarbeidet vi en kravspesifikasjon basert på samtaler med oppdragsgiver og veiledere. 12

13 3 Utstyr og verktøy Dette kapittelet beskrives verktøy, utstyr, programmeringsspråk og rammeverk vi har brukt i løpet av prosjektperioden. Disse vil bli oppsummert hver for seg og forklart hvilken rolle de spilte i prosessen. Vi går også inn på de fysiske arbeidsforholdene og det praktiske rundt jobbingen som kommunikasjon gruppen imellom og opp mot veiledere fra Creuna og Høgskolen i Oslo og Akershus. 3.1 Utstyr Alle tre fikk utdelt hver sin laptop, ferdig oppsatt med brukerkonto og epost. Dette ga også tilgang til bedriftens ressurser og programvare, samt tilgang til Microsoft Developer Network, MSDN, der vi kunne laste ned ulike Microsoft-programmer som for eksempel Visual Studio. Vi fikk også en fast plass ved hver vår pult i det åpne kontorlandskapet til Creuna, samt nøkkelkort som ga oss fri adgang til kontoret både i og utenfor vanlig arbeidstid. På pultene hadde vi i tillegg dockingstasjon til laptopen, stor skjerm, tastatur og mus. 3.2 Dokumentasjon Dokumentasjonsarbeidet har blitt gjort parallelt med utviklingsprosessen. Vi har notert hver dag hvilke deler vi jobber med og eventuelle utfordringer vi har støtt på, i tillegg har vi ukentlig oppsummeringer av arbeidet. Vi har brukt Microsoft Word for dokumentskriving, og vi valgte å bruke Dropbox for synkronisering mellom oss. Dropbox har ikke spesielt god støtte for samtidige brukere, men det var ikke et hovedfokus at flere skulle kunne jobbe i samme dokument samtidig, så vi valgte Dropbox grunnet deres brede støtte av plattformer og systemer. Vi ble derfor ikke avhengige av å bruke en spesifikk plattform eller være koblet til et spesifikt system for å jobbe med dokumentasjonen. 3.3 Kommunikasjon For å kommunisere oss imellom brukte vi primært Microsoft Lync. Lync er en lynmeldingstjeneste for bedrifter der man kan sende meldinger og ha lyd- og videosamtaler. Her 13

14 logget vi oss inn våre som har en global kontaktliste slik at alle Creunas ansatte var lett tilgjengelig dersom vi måtte kontakte noen i bedriften. Øvrig kommunikasjon, blant annet med våre veiledere i bedriften, skjedde via mail med Creunakontoene våre. Til dette brukte vi Microsoft Outlook. Outlook ble også brukt til å sette opp møter og avtaler i forbindelse med prosjektet. For fordeling av oppgaver og oversikt over hva som måtte gjøres benyttet vi Jira. 3.4 Rammeverk, verktøy og programmeringsspråk Creuna jobber hovedsakelig med utvikling i Microsoft-verktøy, blant annet er hele det eksisterende Visit Norway-systemet i.net/microsoft, og det var derfor naturlig for oss å benytte oss av de samme teknologiene og rammeverkene som bedriften bruker ellers. Under forklares disse i nærmere detalj Rammeverk.NET.NET er et rammeverk utviklet av Microsoft. Første versjon,.net 1.0, ble først introdusert i 2002 og har siden da vært i kontinuerlig utvikling. Vi har basert vår løsning på versjon 4.5.1, som ble lansert høsten NET bygger i bunn (figur 2) på Common Language Runtime (CLR), dette er en plattform med støtte for flere språk, som for eksempel C++, C# og Visual Basic. Dette gir mulighet for å kunne lage prosjekter i forskjellige programmeringsspråk og fortsatt få de forskjellige språkene til å Figur 2 Oppbygningen av.net-rammeverket (Wikipedia, 2014). 14

15 «snakke sammen». Man kan da kalle på en funksjon skrevet i Visual Basic fra C# uten særlige utfordringer (CodeProject, 2001). Videre består rammeverket av en rekke biblioteker og pakker for blant annet utforming av brukergrensesnitt, databasetilknytning og utvikling av web-applikasjoner. ASP.NET ASP.NET har vært en del av.nets standardbibliotek siden.net 2.0. Biblioteket gir muligheter for å programmere dynamiske websider, webapplikasjoner og webtjenester (Microsoft Developer Network, 2013a). I vår løsning bruker vi ASP.NET for Web API-et vårt. Vi har fokusert på programmeringsgrensesnittet; det som vises i nettleseren når man besøker API-et er autogenerert. ADO.NET ADO.NET, også en del av.nets standardbibliotek siden.net 2.0, tilbyr rammeverk for å aksessere data fra ulike kilder, deriblant relasjonsdatabaser (Microsoft Developer Network, 2014). Brukes sammen med Entity Framework som forklares under. Entity Framework Entity Framework (EF) er et ORM-rammeverk (Object Relational Mapping) for ADO.NET. EF er ikke et alternativ til ADO.NET, men det baserer seg på ADO.NET for å aksessere data. Vi som utviklere slipper å skrive ADO.NETmetoder og klasser for å jobbe med de underliggende dataene, men EF gjør dette for oss (CodeProject 2012). EF konverterer data mellom objekter og en relasjonsdatabase, noe som gir oss muligheten til å skrive programmeringslogikk Figur 3 Oppbygningen av Entity Framework (Codeproject, 2012). 15

16 fremfor SQL når vi arbeider med data. På den måten kan man behandle data som objekter, og man slipper å forholde seg til SQL-setninger når man skal gjøre innsettinger, lesinger, oppdateringer og slettinger fra databasen. Uten en ORM vil man måtte selv bygge opp SQLsetningene, noe som fort kan føre til feil. Skriver man SQL manuelt i Visual Studio får man ikke hjelp underveis mens man skriver, verken IntelliSense eller Resharper vil plukke opp syntaksfeil fordi SQL-setningene oppfattes som egenkomponerte strenger, og kompilatoren vil heller ikke finne feil dersom det skulle være syntaksfeil eller kall mot ikke-eksisterende tabeller eller rader. Dette er noe ADO.NET og EF løser ved å gi oss muligheten til å definere modeller av dataen vår i koden, og rammeverket vil da holde orden på koblingen mot databasen. Med Entity Framework har man tre måter å mappe data på: Database First. Hvis man har en eksisterende database som skal gjøres om til en objektmodell har Entity Framework verktøy for å utføre «reverse engineering». Man bruker da et designer-view for å kunne redigere forholdet mellom entitetene. Model First. Dette lar deg selv bygge opp en modell av objekter og deres relasjoner ved hjelp av et visuelt verktøy i Visual Studio. EF lager så en database for dette. Code First. Code first er fremgangsmåten vi har valgt å bruke ved oppretting av våre modeller og databaser. Som navnet Figur 4 - Bruk av Data Annotations og Code First. tilsier starter man med koden, man definerer objekter og relasjonene mellom dem i kode, og EF oppretter tabeller og databasen ut i fra det man har bestemt i koden (Entity Framework Tutorial, 2014). Ved hjelp av Data Annotations kan man konfigurere og bestemme hvordan databasen skal 16

17 håndtere modellen man har kodet. Figur 4 viser bruk av Data Annotations for å definere et felt som primærnøkkel og instruerer også databasen til å generere en verdi. Dette lar oss ta utgangspunkt i domenemodellen vår og rammeverket ordner opprettelse av database og tabeller. Gjør man endringer i modellen vil rammeverket gi feilmelding om at modellen og databasen ikke lenger stemmer overens. For å unngå problemer rundt dette kan man bruke migrations, som holder oversikt over endringer gjort i modellen og lar oss kjøre kommandoer for å oppdatere databasen til å matche den endrede modellen. Uten bruk av migrations vil man måtte slette alle tabellene og opprette på nytt for hver endring man gjør i modellen Utviklingsverktøy og programmeringsspråk Gruppens medlemmer fikk hver sin utviklerkonto av Creuna. Dette ga tilgang til en rekke verktøy fra Microsofts utviklerportal MSDN. Utviklingen har i all hovedsak skjedd i C# og Visual Studio Professional 2013 med noen tilleggsbiblioteker, men også i annen programvare og språk. Visual Studio Visual Studio (VS) er et integrert utviklingsmiljø fra Microsoft og brukes for å utvikle systemer og programmer med blant annet.net-rammeverket. VS tilbyr støtte for en rekke språk, deriblant C#, som er det språket vi har jobbet i. I VS har man full oversikt over løsningen man jobber med, der alt fra mapper med kodefiler og tilkoblede databaser er lett tilgjengelige. Den innebygde tekstbehandleren bruker IntelliSense, Microsofts verktøy for syntaksmerking og kodefullføring. VS har også integrert støtte for versjonskontroll, enten via Microsofts Team Foundation Server, eller via Git. Vi har valgt å bruke et eksternt program for kildehåndtering, SourceTree, som forklares nærmere i et eget avsnitt. 17

18 Figur 5 - Standard oppsett i Visual Studio. Resharper Resharper er et tillegg til VS som gir ekstra funksjonalitet utover hva den innebygde IntelliSense gir. Verktøyet analyserer kode mens den skrives og kommer med forslag til endringer og restrukturering i sanntid. I tillegg får man tilbakemeldinger om eventuelle feil direkte i teksteditoren før man kompilerer og man får også beskjed hvis variabel- og metodenavngiving ikke er konsistent. Lisens for bruk av Resharper ble lånt til oss av Creuna. Microsoft SQL Server Management Studio Som del av utviklerkontoen vi fikk var også databasehåndteringsprogrammer tilgjengelige. Som tidligere forklart baserer Entity Framework seg på å lagre objekter og relasjoner i databaser, som persisteres i en SQL Server. Management Studio lar oss administrere dataene i databasene våre, og inneholder også verktøy for å overvåke aktiviteten som skjer i databasene når vi leser fra og skriver til tabellene. SQL Server Migration Assistant for MySql Oversikt over postnumre, poststeder, kommuner og fylker ble hentet fra et åpent tilgjengelig datasett (David Steinsland, 2012). Dette er laget for MySql og lar seg derfor ikke settes inn i en Microsoft SQL (MsSQL)-database helt uten videre. SQL Server Migration Assistant lar oss flytte over eksisterende tabeller og tilhørende data til ønsket format. 18

19 MySQL Workbench Brukt for å opprette database med postnumre, poststeder, kommuner og fylker. Kilden for dataene var kun tilgjengelige for MySql, så vi måtte derfor først opprette MySql-database med tilhørende tabeller og senere migrere over til MsSQL. GIT Når man samarbeider på store kodebaser er det viktig å ha et versjonskontrollsystem som kan spore endringer på tvers av brukere. Git er et open source versjonskontrollsystem som siden lanseringen i 2007 har blitt svært populært og kan brukes på både store og små prosjekter, enten alene eller i grupper. Git er et såkalt distribuert versjonskontrollsystem hvor alle utviklere kan få en lokal kopi av kildekoden og historikken til de enkelte filene. Blir det gjort endringer lokalt hos en utvikler vil ikke endringene gi utslag for de andres kode før endringene er dyttet, pushet, til de andre. Resten av teamet må så hente (pulle) endringene for å få de kopiert over til sin lokale kodebase. Man kan også dele utviklingen over flere grener. Man kan for eksempel grene ut (branche) fra hovedgrenen slik at det man jobber med er adskilt fra hovedgrenen de andre utviklerne har tilgang til. Hver gren har sin egen historikk og kan smeltes (merges) sammen med andre grener etter hvert som de blir ferdigstilt. Slik kan man jobbe distribuert over flere maskiner, på samme filer, uten å «være i veien» for hverandre eller overskrive hverandres kode. For å kunne dele filer via Git må det være et sentralt repository som utviklerne kan dytte og hente kode til og fra. Dette regnes som hovedgrenen (master branch) og er ofte tilgjengelig via en webbasert tjeneste, slik som GitHub eller BitBucket. Vi gikk for Git kontra Microsofts Team Foundation Server (TFS) fordi vi ønsket mer fleksibilitet og uavhengighet enn hva TFS tilbyr. Bruker man TFS må man sjekke ut filer for å kunne gjøre endringer, utsjekkede filer vil da være utilgjengelige for andre utviklere frem til filen er sjekket inn igjen. En annen fordel med Git er at man har filene liggende lokalt på hver utvikler sin maskin med fullstendig historikk. Vi kunne derfor jobbe utenfor Creunas lokaler og også jobbe med koden hvis vi ikke hadde tilgang til internett. 19

20 BitBucket BitBucket.org er tjenesten vi benyttet oss av for å kunne distribuere kode mellom oss. BitBucket støtter flere versjonskontrollsystemer, deriblant Git. Fordelen vi fant med BitBucket over andre alternativer, som for eksempel GitHub, er at BitBucket gir oss ubegrenset antall private repositories, både personlige og for team. GitHub gir oss kun offentlige repositories for team. SourceTree Som nevnt har Visual Studio støtte for både Team Foundation Server og Git. Den innebygde Gitklienten er noe tungvint å bruke og gir ikke den fulle fleksibiliteten som Git tilbyr. Vi tok derfor i bruk en Git-klient som heter SourceTree. Denne er utviklet av Atlassian, de samme som driver BitBucket. SourceTree gir oss en mer ryddig oversikt over forskjellige grener og enklere navigering mellom versjoner enn hva Visual Studios innebygde verktøy gir. Figur 6 - Flere grener i Git, vist i SourceTree. 20

21 4 Utviklingsprosessen Dette kapittelet beskriver utviklingsprosessen fra start til slutt, med hovedfokus på det produktet vi skulle skape. Først presenterer vi det vi har å jobbe med. Vi forteller så hvordan vi innhentet informasjon, hva vi diskuterte og hvordan vi løste ulike problemer som vi kom over underveis i prosessen. 4.1 Forberedelser og innhenting av informasjon Dataleverandørene Visit Norway består av, i tillegg til redaksjonelt innhold, en rekke produkter - dette kan eksempelvis være hoteller, restauranter, severdigheter eller busselskaper. Disse produktene blir levert av eksterne produktleverandører, som sitter på flerspråklig informasjon, bilder og annen relevant data knyttet til hvert produkt. Denne dataen blir hentet inn og presentert på Visit Norways nettsider via et API (Application Programming Interface) som kommuniserer med produktbiblioteket. Per i dag har Visit Norway to hovedleverandører; Tellus og CBIS Tellus Om Tellus Tellus er den ene leverandøren av produktinformasjon til Visit Norway, og de var inntil nylig også eneste tilbyder av produktdata. De har jobbet med reiseliv og destinasjoner siden 1994, og er et globalt selskap (Tellus Blogg, udatert). Om Tellus API Tellus sitt API finner man på og dataene er tilgjengelig for planlagte nedlastninger dersom man har en lisensnøkkel (Tellus Feed, udatert a). Dette vil si at man ikke kan benytte dataene direkte i for eksempel en nettside, men at dataene kan lastes ned og lagres for deretter å kunne brukes i ulike løsninger. Produktene kommer som en lang XML-streng, og strukturen er definert i et eget skjema (Tellus, udatert). 21

22 Ved prosjektets start i januar benyttet Creuna Tellus API versjon 2.3, men Tellus hadde allerede lansert versjon 2.4. Vi valgte derfor å benytte oss av den nyeste versjonen. Creuna hadde også planer om å oppgradere Visit Norway til å benytte v2.4. Underveis i prosjektperioden lanserte Tellus en ny versjon, v2.5. Grunnet våre tidsbegrensninger valgte vi å fortsette med versjon 2.4, da oppdateringen blant annet inneholdt endringer i XML-skjemaet og måten informasjonen ble levert på. Utfordringer Tellus har noen krav til hvordan API-et skal brukes (Tellus Feed, udatert b). Blant annet skal innhenting av produkter skje én gang i døgnet, mellom midnatt og kl Dersom et produkt da er oppdatert, skal alt av tidligere lagret produktdata slettes og legges inn på nytt. Produkter som står som slettet skal umiddelbart slettes fra databasen. En gang i måneden skal også alle data slettes og legges inn på nytt igjen. Dette er selvfølgelig noe vi må ta hensyn til CBIS Om CBIS CBIS (City Break Information System) er et API-distribuerende system levert av Citybreak (City Break, udatert) Firmaet startet opp i 1999 og har hovedkontor i Gøteborg, Sverige. Visit Norway har ganske nylig tatt i bruk CBIS som leverandør, og omfanget av prosenten produkter som blir presentert fra disse er derfor foreløpig mye lavere enn antall produkter fra Tellus. CBIS API Web-API et til CBIS finner man på Her kreves det en gyldig lisensnøkkel for å hente ut informasjonen, som blir presentert som en lang XML-streng. Dette API-et er i likhet med Tellus, ikke åpent for allment bruk. Utfordringer Under hele perioden har linken til API-dokumentasjonen vært død, så vi har ikke hatt tilgang til denne. Vi fikk tilsendt noe materiale om CBIS av en av våre eksterne veiledere tidlig i prosessen, blant annet et par sider tekstdokument som inneholder generell informasjon om dataoppsett og 22

23 språkkoder, men vi vet ikke om dette er den samme dokumentasjonen som mangler på websiden. Når det kommer til regler for bruk av API-et, som sannsynligvis skulle ha ligget under dokumentasjonen, har vi heller ikke funnet noe om dette. Vi valgte derfor å ta utgangspunkt i de samme reglene og retningslinjene som Tellus har oppgitt. Vi fikk heller ikke tilgang til den API-nøkkelen for CBIS som skulle gi oss tilgang de reelle produktene som ble brukt på Visit Norway. Derimot fikk vi nøkkelen til test-databasen, som inneholdt betydelig mindre og ufullstendig informasjon Innhenting av informasjon For å bli kjent med informasjonsbehovet og Visit Norway, valgte vi først å analysere produktene slik de presenteres på visitnorway.com i dag. Vi navigerte oss rundt på nettsiden og plukket ut mer eller mindre tilfeldige produkter. Vi fant raskt fram til de sentrale elementene som de fleste produktene inneholdt: - Navn - Kontaktinformasjon - Beskrivelse - Kategori(er) - Fasilitet(er) - Bilder - Anmeldelser fra TripAdvisor - Informasjon om hvilken lokal organisasjon produktet tilhørte I tillegg hadde mange av produktene disse elementene: - Transport - Åpningstider - Koordinater på kart 23

24 Vi sammenlignet så informasjonen på visitnorway.com med produktinformasjon på andre lands turistsider, for eksempel Visit Denmark (2012) og Visit Ukraine (2013). Vi fant ikke her noe informasjon som vi følte manglet hos Visit Norway, snarere tvert imot. For eksempel viser ikke Visit Ukraine et kart hvor de ulike produktene er lokalisert, slik som Visit Norway gjør. For å kunne lage en ny domenemodell for produktene var det viktig å finne ut hvilke data vi faktisk hadde tilgjengelige fra produktleverandørene og kvaliteten på disse dataene. Vi brukte mye tid på å gå gjennom produkter på visitnorway.com og sammenligne dem opp mot den bakenforliggende informasjonen som ble levert fra leverandørene. Figur 7 - Visningen av et produkt på visitnorway.com sammenlignet med informasjonen fra leverandøren (Tellus i dette tilfellet) 24

25 I starten var det mye data vi så for oss at vi ønsket å ha med videre for å kunne tilrettelegge for mer avansert søkefunksjonalitet. For eksempel ønsket vi muligheten til å søke på egenskapene til et produkt, eksempelvis alle kafeer med wi-fi eller alle restauranter som serverer asiatisk mat. Mange av disse ideene var det vanskelig å få gjennomført fordi datagrunnlaget fra produktleverandørene ofte var mangelfullt og inkonsistent. I tillegg var det veldig lite struktur i måten et produkts fasiliteter ble registrert på, mer om dette forklares under avsnittet «utvikling av domenemodell» Wireframes Videre jobbet vi med wireframing for å kartlegge hva vi mente ville være viktig informasjon dersom vi skulle konsumere API-et vårt. Vi tegnet hver våre wireframes av hvordan vi så for oss en presentasjon av data ville se ut. Da vi sammenlignet de forskjellige løsningene til slutt så vi at vi hadde tegnet selve oppsettet forskjellig, men når det kom til informasjonsblokkene var vi jevnt over enige om hva som var viktig. 25

26 Figur 8 - Ulike wireframes med stort sett samme informasjon Diskusjoner Selv om vi stort sett var enige om hva slags informasjon vi burde ha med i datamodellen, var det noen uenigheter til hvordan vi skulle løse enkelte problemstillinger. Den viktigste diskusjonen omgikk rundt språk og hvordan produktene skulle lagres flerspråklig. Språk Vi var innom muligheten på å lagre hver språkavhengig attributt (f.eks. produktnavn- og produktbeskrivelse) flere ganger i én produkttabell. Dette hadde ført til svært brede tabeller fordi man må lage tabeller for hvert tilgjengelige språk ganget med antall oversettelige attributter. Det kunne potensielt vært lettere å oppdatere produkter på denne måten, og muligens gitt bedre ytelse fordi man slipper å søke etter mange varianter av et produkt i databasen. Dersom løsningen kun hadde bestått av to eller tre språk hadde dette derfor vært en god løsning. Men, siden vår løsning skulle støtte et vesentlig høyere antall språk ville tabellbredden blitt svært stor og vanskelig å vedlikeholde. Vi var også redde for eventuelle 26

27 problemer som kunne oppstått hvis nye språk skulle blitt lagt til, da hele produktmodellen da måtte ha blitt oppdatert. Vi valgte derfor å forkaste denne ideen. En annen løsning vi var innom var å lage produkter flere ganger per språk. Dette ville være en enklere løsning der vi koblet hvert produkt mot en språkkode. Ulempen med dette ville være at de delene av produktet som ikke trengte å oversettes ville bli lagret flere ganger, og kunne potensielt bli inkonsistente. Hvis et produkt for eksempel endret mailen på svensk, måtte det samme bli gjort i alle de tilsvarende produktene i de andre språkene. Det ville også bli vanskelig å finne en god løsning for å samle de produktene som hørte sammen, og bytte mellom dem når språket ble skiftet, på en god måte. Denne ideen ble også delvis forkastet, men vi bearbeidet den videre til å bli den løsningen vi har i dag. Pris Lenge vurderte vi om vi skulle ha med pris i modellen vår. På dagens løsning av Visit Norway er det noen av produktene som har oppgitt en fra-pris, men enda flere har prisnivå som fasilitet. Siden vi allerede hadde lyst til å endre på måten man brukte fasiliteter på, valgte vi å heller benytte oss av prisnivå som en fasilitet enn å ha et eget felt til pris som ofte ville stått tomt. 4.2 Utvikling av domenemodell Innhold i modellen Etter å ha sammenlignet utkast og wireframes, fant vi fram til hva vi ville ha med av produktdata: - Produktnavn - Beskrivelse - Kategorier - Media - Geolokasjon - Transport - Fasiliteter - Åpningstider 27

28 - Kontaktinfo - Miljøsertifisering - Anmeldelser Noe av denne informasjonen er som nevnt språkavhengig, som for eksempel beskrivelse, mens annen informasjon vil være lik på alle språk. Etter en diskusjon om forskjellige modell-løsninger kom vi frem til at vi kunne dele opp produktene ved å ha et språkavhengig objekt per språk for hvert produkt, og et språkuavhengig produkt som inneholdt informasjon som ikke krevde oversettelse. Slik ville vi unngå dobbeltlagring av en del informasjon og redusere inkonsistent informasjon. Figur 9 - Products: felles for alle språk, ProductInfoes: Oversettbar prosa Ekstern id og produktleverandør For å kunne holde styr på produktene og hvor de kom fra, noe som virket nyttig til senere oppdatering av dataene, la vi til to felt i modellen som skulle holde styr på dette. I ExternalId skulle id-en fra CBIS eller Tellus lagres, mens hvilken av leverandørene det kom fra skulle bli satt i ExternalProvider. Vi opprettet en enum med ExternalProviders, da vi så dette som mest hensiktsmessig. I en enum kan vi enkelt legge til flere produktleverandører dersom det blir nødvendig i fremtiden. 28

29 4.2.3 Media, åpningstider og tredjepartsinfo Noe informasjon, som media, åpningstider og tredjepartsinfo, er så komplekse at de bør være egne klasser. Da et produkt kan ha flere av disse, bør produktene ha lister eller samlinger av objektene. Siden tredjepartsinfo og åpningstider ikke har noe språkavhengig informasjon, valgte vi å la det språkuavhengige objektet ha samlinger av disse. Media, derimot, kan ha språkavhengig informasjon i form av beskrivelse av et bilde eller språk på en video. Vi syntes derfor at dette hørtes hjemme ut under ProductInfo, og opprettet en samling av Media-objekter der Kategorier og fasiliteter Vi fant også ut at vi ville ha faste kategorier og fasiliteter, da dette gjør det enklere å for eksempel søke innenfor en kategori eller sortere på produkter som innehar en bestemt fasilitet. Konvertering til faste kategorier og fasiliteter virker vanskelig, ettersom datagrunnlaget fra produktleverandørene er mangelfulle, uregelmessige og svært inkonsistente. Kategorier og fasiliteter fra Tellus ser ikke ut til å følge et fast oppsett. Det virker veldig tilfeldig hva som blir kategorisert som hva og bruken av fasiliteter for å beskrive et produkts egenskaper varierer veldig, noe som gjør det vanskelig å få automatisert en måte å hente ut spesifikke fasiliteter på. Fasiliteten «toalett» kan for eksempel komme fra leverandørene som «wc», «do», «toalett», «sanitæranlegg» eller «antall rom uten bad og/eller toalett», for å nevne noen. Fra Tellus alene var det over 1600 kategorier og enda flere fasiliteter ( ), og det blir kontinuerlig lagt til flere. Det virker som om de som registrerer produktene står fritt til å enten velge kategorier/fasiliteter, eller skrive egne, noe som fører til mye dobbellagring og dårlig forfattede fasilitetsnavn. Eksempelvis er «rom m/høyhastighets internettilgang», «internett på rommet», «rom m/internett-tilgang» og «værelse med hurtig internettforbindelse» ført opp som forskjellige fasiliteter på tross av at de i bunn og grunn betyr akkurat det samme. Mer om fasiliteter og kategorier beskrives under delkapittelet Innhenting og konvertering. 29

30 4.2.5 Modelldiagrammer Etter en rekke iterasjoner med modellering kom vi til slutt frem til en modell vi bestemte oss for å implementere. Figur 10 Modellen implementeringen tok utgangspunkt i. Denne modellen fungerte mer som en veiledning enn en fasit etter hvert som vi begynte å implementere klassene. Da vi programmerte klassene dukket det opp forslag til endringer og forbedringer som vi tok tak i der og da. Veilederne våre kom også med innvendinger om oppsettet av klassene. Som det fremgår av figur 11 endret modellen seg noe fra den 30

31 opprinnelige planen. Figur 11 er dog på et mer detaljert nivå enn figur 10 så de er ikke direkte sammenlignbare. Figur 11 Modell etter fullført implementasjon 31

32 4.2.6 Implementeringsdetaljer Id Siden alle klasser skulle ha en id, valgte vi å lage en abstrakt klasse DomainBase med variabel Id som alle de andre klassene arver fra. Dette gjør også at man kan sende alle typer objekter samlet i for eksempel en Collection av DomainBase. Denne id-en tenkte vi at skal settes automatisk når man lagrer objektene i databasen. Åpningstider Siden åpningstider kan være enten generelle eller spesielle, valgte vi å opprette to forskjellige klasser til dette: OpeningTimes for vanlige åpningstider, og SpecialOpening for åpningstider med et datointervall definert, typisk for sesonger og høytider. Vi opprettet også en enum av ukedager for senere å enkelt kunne sortere ut hvilke dager som hadde hvilke åpningstider, og for eksempel gi mulighet til at man kunne dynamisk sjekke om et produkt hadde åpent akkurat nå. Media Vi vurderte lenge hvordan vi skulle lagre media-objekter, siden bilder fra Tellus som regel kommer i tre forskjellige størrelser. Vi syntes det var dumt å ikke ta vare på alle størrelsene, spesielt siden API-et kan tenkes å skulle brukes mot både nettstedet og mobilapplikasjoner, og det da kan være hensiktsmessig å skulle bruke henholdsvis de største og de minste bildene. Til slutt fant vi ut at vi ville ha en klasse Media (figur 12), der alle detaljer som navn, type fil og beskrivelse ligger, samt en klasse MediaInstance (figur 13) som inneholder filstørrelse og URL-en til den faktiske fila. Figur 12 Klassen Media 32

33 Figur 13 Klassen MediaInstance 4.3 Innhenting og konvertering Arkitektur for henting og konvertering av data Produktdataene henter vi fra to produktleverandører, Tellus og CBIS. Fra Tellus får vi tilbake en XML-string, mens fra CBIS får vi objekter via et klientbibliotek levert av CBIS. Vi har derfor laget to konverteringsklasser, en for hver av tilbyderne, som tar dataene inn og sender samling av våre domeneprodukter tilbake. Vi vurderte å lage et konverteringsinterface som disse klassene kunne implementere, men siden dataene vi får inn er såpass forskjellige, fant vi ikke det hensiktsmessig. Konverteringsklassene må uansett kodes for å matche de ulike servicene til produktleverandørene. For å separere innhenting, konvertering og lagring, delte vi inn koden i forskjellige prosjekter og klasser. Prosjektet Gatherer er det som tar seg av innhenting og konvertering. Vi laget først en klasse, Start, som kaller på servicene og sender dataene til riktig konverteringsklasse. Men etter hvert som spesielt Tellus krevde mange spørringer for å få ut de dataene vi trengte, valgte vi å dele opp også datainnsamlingen. Oppdelingen skaper også mulighet for å utvide programmet senere til å kjøre innhentingen parallelt i to tråder. Klassen Start kaller nå altså på to innsamlingsklasser, TellusCollector og CbisCollector, som kaller på servicene fra henholdsvis Tellus og CBIS. Dataene disse får inn, sender de videre til konverteringsklassene TellusConverter og CbisConverter, som konverterer produktene til vår domenemodell og returnerer disse. Når Start har fått tilbake domeneproduktene som en Collection av DomainBase, sendes disse videre til klassen Saver i prosjektet SaveToDb, som har ansvaret for å lagre dataene i databasen. Vi vurderte en liten stund å la Converter-klassene 33

34 sende produktene direkte til lagring, men fant ut at dersom det måtte gjøres endringer i koden senere, var det bedre å separere de ulike delene så mye som mulig. Det er likevel enkelt å separere lagringen av dataene fra de to ulike leverandørene ved å kalle på lagringsmetoden i Saver fra de to Collector-klassene istedenfor fra Start, dersom man finner det mer hensiktsmessig Program Program-klassen lagde vi som en konsollapplikasjon for at vi kunne kontrollere og overvåke innhenting av data fra de ulike produktleverandørene. Dette ga oss et felles system for å kunne administrere innhenting fra ulike kilder. I starten av utviklingsfasen måtte vi kalle rett på de tilkoblede servicene for å få data ut fra dem. Dette var før vi hadde en måte å lagre det vi hentet inn på og det ble utført svært mange unødvendige kall til begge servicene selv om vi bare skulle teste funksjonalitet koblet til en leverandørs data. Det var ikke noe mål for oppgaven å ha et grafisk grensesnitt for denne delen av programmet, vi brukte derfor en konsollapplikasjon for å kunne styre innhentingen. Figur 14 Bruk av konsollapplikasjon for å se på dataene fra CBIS. Konsollapplikasjonen vår startet først som et sted vi kunne skrive ut strukturen på dataene vi fikk hentet inn, sammen med annen informasjon, som for eksempel antall produkter som matcher 34

35 visse kriterier. Dette ble mye brukt under utviklingen av konverteringsmetodene, da vi ikke hadde noe system for persistering på plass og derfor brukte konsollvinduet som et sted å sammenligne data levert fra leverandørene med slik de så ut etter konvertering til vår modell. Videre la vi også inn funksjonalitet for å kunne velge hvilken produktleverandør vi skulle hente fra. Tellus hadde også mulighet for å vise produktdata i nettleser via et API på feed.tellus.no. CBIS leverte produktene som objekter og for å kunne se de i klartekst brukte vi konsollapplikasjonen vår. Vi brukte også applikasjonen for å se etter sammenhenger mellom produkter, kategorier og fasiliteter, samt lagre disse til fil. Etter hvert som løsningen vår vokste og persisteringsløsningen var under utvikling fikk konsollapplikasjonen et annet bruksområde. Vi la til funksjonalitet for å manuelt hente inn produkter fra henholdsvis CBIS og Tellus, manuelt i den forstand at man selv måtte velge hvilken leverandør man skulle hente fra og hvilke innhentingsmetoder man skulle kjøre. Tanken har vært at konsollapplikasjonen skal kjøres automatisk og selv velge hvilke metoder den skal kjøre basert på tidspunktene for de forrige innhentingene og oppdateringene. Det er lagt til funksjonalitet for automatisk kjøring av metoder, men programmet må startes opp manuelt. Det er mulig å sette applikasjonen opp som en Windows Service for helautomatisk kjøring, men dette er ikke noe vi har brukt tid på siden det faller noe utenfor omfanget av oppgaven CBIS Innhenting For å hente inn data fra CBIS skrev vi klassen CbisCollector, som hadde i oppgave å koble til en service og hente ut lister av produkter, organisasjoner, kategorier og alt annet vi trengte fra CBIS. Videre skulle disse listene sendes gjennom metoder i CbisConverter for å omforme dataene slik at den passet vår datamodell. Til skulle vi stå igjen med forskjellige lister av konverterte objekter som skulle sendes til persisteringsprosjektet SaveToDb. 35

36 For å få ut alt vi trengte måtte vi bruke to forskjellige referanser se figur 15. Den ene var en SOAP-basert service som ble koblet direkte mot CBIS API via Gatherer-prosjektet. Den andre var et internt hjelpeprosjekt (Visit.CbisAPI) som vi fikk tilsendt av våre veiledere på Creuna. Dette hjelpeprosjektet er utviklet av CBIS og henter data fra samme referanse, men omformer i tillegg flere av de vanligste attributtene for å gjøre dem enklere å hente ut. Vi prøvde i begynnelsen å kun bruke en av delene, men fant etter hvert ut at de begge var nødvendige fordi de hadde forskjellige bruksområder. Det hadde vært mulig å kun bruke den direkte referansen til den eksterne servicen, men vi hadde da måttet bruke mye mer tid og krefter på å hente ut ønsket informasjon fra noen av kildene. Figur 16 viser hvordan et produkt ser ut når det kommer direkte fra Figur 15 - De to referansekildene CBIS bruker servicen. Tekst som for eksempel «produktbeskrivelse» vil ligge som et objekt under «Attributes», og er mindre trivielt å hente ut da det videre må sammenlignes mot et verdi- og typebibliotek for å få hentet ut riktig type attributtverdi. Figur 16 - Slik ser produktene ut direkte fra servicen. Ingen enkel oppgave å hente ut produktbeskrivelsen. 36

37 Det er her det interne hjelpeprosjektet kom inn. Som nevnt over henter dette prosjektet informasjon fra den samme servicen, men på veien konverterer den også informasjonen mot en mer brukervennlig datamodell slik at man enklere kan hente ut de vanligste attributtene. Vi kunne dermed hente ut produktbeskrivelsen uten å måtte bruke avanserte sammenligningsmetoder for å sortere ut riktige attributter se figur 17. Figur 17 - Ved å hente ut produktene via hjelpeprosjektet blir de lettere å arbeide med. Men - selv om hjelpeprosjektet hjalp oss med produktene, så leverte den ingenting om organisasjoner eller produkteiere. Dette er fordi disse objektene, i motsetning til produktene, ikke er problematiske å hente direkte fra den eksterne servicen. De trenger med andre ord ikke omforming for å gjøres lettere å bruke. Dette er grunnen til at vi trengte å bruke begge kildene. Her, i figur 18, henter vi organisasjoner via ekstern service uten hjelp av hjelpeprosjektet: Figur 18 - Innhenting av et organisasjonsobjekt fra den eksterne service-referansen. I motsetning til produkt, er dette helt uproblematisk å hente ut. 37

38 Nedenfor, i figur 19, viser vi en grov oversikt over hvilke data som blir hentet fra de to forskjellige servicealternativene, samt hvilke variabler vi ender opp med etter at listene er sendt gjennom konverteringsklassen CbisConverter. Merk at «getproductowners» inneholder både organisasjoner og produkteiere, men blir sortert ut i CbisConverter. Figur 19 - Dataflyt mellom intern og ekstern service, CbisCollector og CbisConverter Først hentet vi informasjonen via en SoapClient, enten direkte fra Gatherer.CbisServiceReference, eller «omveien» gjennom hjelpeprosjektet Visit.CbisApi. Resultatene kom som en liste av objekter som vi sendte videre til CbisConverter. Her hadde vi skrevet forskjellige metoder for å plukke ut og omforme den informasjonen vi trengte slik at den passet til den datamodellen vi selv har skrevet. Siden de fleste produktene finnes på forskjellige språk, og SoapServicen krever en språkkode som parameter, måtte vi hente inn en gruppe produkter fra et og et språk om gangen. Vi hadde en liste i form av array med språkkoder, basert på de språkkoder CBIS bruker, som vi gikk gjennom med en foreach-løkke. Språkkoden ble dermed sendt med som parameter når vi gjorde kall på klienten. Se figur

39 Figur 20 - Innhenting av produkter på forskjellige språk Gjennom variabelen _products hentet vi en liste av produkter på for eksempel norsk (språkkode 5) fra API et. Fra dette ønsket vi å dele disse objektene opp i to klasser: Product, som ville inneholde den informasjon om et produkt som ikke er språk-avhengig. Denne typen skulle KUN lagres én gang, for å spare plass i databasen vår, og unngå dobbeltlagring. ProductInfo skulle inneholde den informasjonen om et produkt som var oversatt til flere språk. Disse skulle lagres flere ganger, per språk produktet eksisterte med. Variabelen _productlist skulle da inneholde en liste med objekter av typen «Product». Neste gang det ble byttet språk i foreach-løkka ville det bli sjekket om det aktuelle produktet allerede fantes i lista i så fall skulle ingenting gjøres. Fantes det ikke fra før skulle det bli lagt til. Variabelen _inactivelist ville bli fylt opp med inaktive produkter etter hvert som de blir funnet under konverteringen. Når det gjelder _productinfolist ville denne for hver gang bli fylt opp med språkavhengig produktinformasjon som hørte til det aktuelle språket. I denne itereringen, hvor vi har norsk (språkkode 5) som aktiv parameter, ville listen derfor bestått av norske produktinfoer. Denne listen måtte senere bli lagt til en annen liste, _productinfolistalllang, som inneholdt alle produktinfoene fra de forskjellige språkene. Denne samme prosedyren måtte gjentas med media, siden også den inneholder språkavhengig informasjon. 39

40 Listene _productlist, _inactivelist, _productinfolistalllang og _medialistalllang vil dermed være de listene man senere kan ta i bruk til persisteringsløsningen, sammen med _localorglist og _ownerlist. Konvertering Fra CbisCollector sendte vi data gjennom CbisConverter som så skulle sortere og omforme alle objektene vi fikk inn fra CBIS til å passe vår egen datamodell slik at det i CbisCollector står igjen seks lister som kan brukes videre i prosjektet, som nevnt i slutten av forrige delkapittel. Organisasjoner ble konvertert gjennom GetLocalOrgs og GetOwner ved at Organisasjonens OrganizationType ble hentet ut. Organisasjoner av type Operator eller MultiOperator ble kjørt gjennom GetLocalOrgs. Var typen definert som Owner ble den kjørt gjennom GetOwner. Innkommende produkter ble kjørt gjennom både GetProductList og GetProductInfoList dette fordi vi som nevnt ønsket å skille produktet i språkavhengig og ikke-språkavhengige deler for å spare diskplass og hindre at samme informasjon blir lagret flere ganger. I GetProductInfoList ble felter som navn og beskrivelse alt som var oversettelig, konvertert og returnert som ProductInfo-objekt. GetProductList skulle samle og konvertere telefonnumre, adresse, epostadresser og websider ting som er det samme på alle språk. Fordi det kun skulle lagres én instans av hvert produkt måtte denne metoden også sjekke om det aktuelle produktet fantes i lista fra før av. Koden vi brukte for å legge til et enkelt produkt la vi i en egen metode AddOneProduct fordi vi måtte aksessere denne koden flere steder i GetProductList. Først sjekker vi nemlig om Produktlisten er tom hvis ikke blir alt lagt til. Senere, når vi kjører mot en liste det finnes produkter i, må vi sjekke om produktet finnes fra før hvis ikke blir det éne produktet lagt til. Konverteringen av media skjedde i GetMediaList der det ble sjekket hva slags media som skulle behandles (video, bilde etc.) og dermed bli konvertert ut fra dette. Et mediaobjekt skulle kunne bestå av en eller flere MediaInstances, for eksempel hvis man hadde flere størrelser av det samme bildet. Når objektet ble definert som et bilde ville størrelsen bli sjekket slik at den ble passende lagret med enum Thumbnail, Small, Large eller Unknown. CBIS leverer ikke flere 40

41 versjoner av samme bilde, men siden Tellus gjør dette bestemte vi oss for at den felles datamodellen skulle inneholde denne muligheten. Utfordringer Arbeidet mot CBIS bød på et par problemstillinger som vi måtte jobbe oss rundt, både med tanke på innhentingen av data, og dataene i seg selv. Den første store utfordringen var at vi kun fikk tilgang til CBIS sin test-database. Produktene der var verken aktuelle eller fullstendige. Stort sett var det kun de vanligste feltene som produktnavn, beskrivelse og veibeskrivelse som var fylt ut, og dersom man for eksempel ønsket å hente ut litt sjeldnere attributter som aldersgrense, var det få eller ingen produkter som inneholdt dette. Det gjorde det vanskeligere å vite om vi gjorde noe feil i koden, eller om det rett og slett ikke var noe å hente ut. Listen over kategorier var også svært smal, og neppe representativ for den faktiske kategorilisten - se figur 21. Via den ene veilederen i bedriften henvendte vi oss til City Break og spurte om vi kunne få en fullstendig liste over de kategorier som ble brukt mot Visit Norway, men dette fikk vi ikke tilgang til. På grunn av at vårt interne datasett, som består av en statisk liste med kategorier som man manuelt måtte konvertere hver og en ekstern kategori til, ble vi derfor nødt til å ta utgangspunkt i test-databasen. Dette har medført at det må en del implementering til for å få konvertert alle kategoriene som skal være med, dersom vår løsning skal tas i bruk med CBIS reelle database. Figur 21 Oversikten over kategoriene som kommer inn med CBIS test-database. En annen stor utfordring var å få ut verdier fra «multi-attributter» - det vil si felter som inneholdt flere verdier enn én. Via hjelpeprosjektet var det enklere å få ut de vanligste attributtene som navn og beskrivelse. Det var også gjort godt til rette for å hente ut medias som også var en type 41

42 multi-attributt. Løsningen var dog ikke fullstendig, og ga oss ikke den samme hjelpen for å få ut blant annet produktets fasilitetskategorier og fasilitetene som lå herunder. Vi måtte derfor få ut disse verdiene manuelt, det vil si uten å bruke hjelpeprosjektet. Dette krevde mer kode, samt sammenligning av produktets attributt-type og verdi mot et attributtbibliotek. Til slutt klarte vi fint å hente ut de enklere attributtene på denne måten, men ikke de dype multi-attributtene som vi egentlig var på jakt etter. Som nevnt tidligere var det også å vanskelig å forholde seg testdatabasen fordi vi ikke visste om det i det hele tatt var noe å finne. Til slutt ble tiden så knapp at dette arbeidet måtte nedprioriteres, etter mange og lange forsøk Tellus Henting av data Vi laget en egen klasse, TellusCollector, for å håndtere innhenting av produktdata fra Tellus. Denne oppretter en forbindelse til Tellus Feed v2.4 Soap Client (Tellus Feed, udatert b) og kaller på metoder for å hente inn dataene. For å få inn all informasjon vi trenger til domenemodellen vår, trengs det i tillegg til kall på GetProductList også GetDBOwnerList for å få ut detaljer om de lokale organisasjonene og GetCustomerList for å få ut detaljer om produkteierne. GetDBOwnerList er språkuavhengig, og vi trenger derfor kun å kalle på denne én gang. De to andre metodene må derimot kalles på for hvert språk man skal hente fra. Dessuten er det begrenset for hvor stort område man kan hente produktdata fra om gangen, og vi må derfor kalle på GetProductList og GetCustomerList for hvert fylke eller kommune. For å løse dette laget vi to lister med henholdsvis alle språk og alle fylker, som vi itererer igjennom. Konverteringsverktøy All data vi får tilbake fra Tellus Soap-klienten kommer som XML i en lang string. Siden Tellus har publisert skjemaet for XML-koden som returneres, forsøkte vi å bruke XML Schema Definition Tool (Microsoft Developer Network, 2012) for å konvertere XML-koden til C#-klasser. Dette fikk vi ikke til, da XSD-filen ikke var fullstendig og blant annet manglet enkelte tagger. Etter litt research fant vi XDocument (Microsoft Developer Network, 2014), som forenklet oppdelingen og søkingen av XML-koden. Vi valgte derfor å bruke XDocument til å dele opp og hente ut dataene fra responsstrengen. 42

43 XDocument-klassen inneholder alt man trenger for å ha et gyldig XML-dokument og har på lik linje med XML støtte for å ha underelementer, eller tagger. Disse underelementene, XElement, vil være tilgjengelige egenskaper på XDocumentet man har opprettet. På den måten får vi hentet ut verdier ved å gå gjennom et XDocument og lete etter XElementer med et bestemt navn eller verdi. Figur 22 Sjekk om Xdocument "address" inneholder elementet "street" Konvertering av data For å gjøre om dataene til objekter av vår egen datamodell lagde vi klassen TellusConverter for å håndtere konverteringen. Vi startet med å lage metoder for å konvertere dataene fra GetDBOwnerList og GetCustomerList, da disse er mindre komplekse enn produktdataene. Metodene, kalt GetLocalOrgs og GetOwners, tar inn den relevante strengen med XML-kode som parameter, konverterer stringen til en instans av XDocument, oppretter nye domeneobjekter for hver av underobjektene i XDocument-instansen, og henter ut de dataene vi vil ta vare på dersom de finnes. Deretter returnerer vi en Collection av domeneobjektene til TellusCollector fra hver av metodene. 43

44 Figur 23 Metode i TellusConverter som konverterer en XML-string til en XDocument-instans, itererer igjennom underobjektene som i XML har tagen «product» og forsøker å hente ut id-en. Siden kall på GetCustomerList krever parametere som språk og område, mens vi ikke behandler våre Owners som språkavhengige, valgte vi å opprette en Collection av Owners i TellusCollector som vi sender med til TellusConverter. For hver nye Owner vi får ut av dataene, sjekker vi så om den allerede finnes i vår Collection basert på Id-en fra Tellus. Dersom den ikke allerede finnes, legges den til. Vi koblet også LocalOrgs og Owners sammen i GetOwners på samme måte. Siden vi har to forskjellige klasser som holder produktinformasjon, nemlig Product og ProductInfo, laget vi først to forskjellige konverteringsmetoder: GetProduct og GetProductInfo. Disse tok begge inn den samme stringen fra GetProductList, samt Collections av Product, ProductInfo, Owners og LocalOrgs opprettet i TellusCollector. Metodene konverterte stringen til et XDocument-instans, hentet ut de dataene vi trengte til våre respektive domenemodeller, og koblet objektene sammen med eksisterende objekter i Collectionene. Siden Product-objektene som inneholder den språkuavhengige delen av produktinformasjonen ville bli duplisert på grunn av innhentingen på forskjellige språk, sjekkes det om den allerede finnes i Collectionen før den eventuelt legges til. Etter hvert fant vi ut at det var unødvendig å konvertere og gå igjennom den samme responsstrengen to ganger. Vi skrev derfor om de to metodene slik at TellusCollector kun kaller på GetProductInfo. Denne lager så en instans av ProductInfo, og sjekker om det finnes et 44

45 tilhørende Product-objekt. Dersom Product-objektet finnes, kobles disse sammen, og dersom det ikke finnes, kalles metoden ConvertToProduct som oppretter dette. Metoden GetProductInfo i TellusConverter returnerer en Collection av ProductInfoer til TellusCollector. Siden vi inne i denne metoden koblet objektene sammen med tilhørende objekter som for eksempel Owners, inneholdt til slutt Collectionen av ProductInfoer, kalt productinfos, koblinger til alle andre objekter vi har tenkt til å lagre. Vi trenger derfor bare å sende denne Collectionen videre til lagringsprosjektet. Senere gjøres dette om til å sende en liste av Products isteden; mer om det i kapittelet om persistering. Bruk av HTMLAgilityPack HTMLAgilityPack er et tredjepartsverktøy for parsing av HTML-filer. Verktøyet er veldig fleksibelt og stiller ikke strenge krav til formatteringen av dokumentet. Dette gir mulighet for å hente ut HTML-tagger eller elementer fra en tekstbolk selv om det ikke oppfyller kravene til riktig formattert HTML-dokument. Som beskrevet tidligere leverer Tellus sin klient en lang XML-streng med produktinformasjon, denne måtte vi manuelt dele opp og hente informasjon ut av. Noen av feltene vi ønsket å ha med oss videre til vår nye modell var ikke alltid tilgjengelig som ren tekst fra leverandørene av informasjonen. Eksempelvis var linker til mediainnhold, som YouTube og Vimeo, ikke lagt i egne elementer i XML-en, men under et felleselement for både tekst og video. Dette elementet inneholdt både ren tekst og lenker til der mediainnholdet lå. Lenkene til innholdet måtte derfor isoleres fra resten av teksten rundt. I utgangspunktet bestemte vi oss for å sette opp en RegEx for å hente ut url-en, men dette viste seg å være tungvint ettersom formatet på url-ene varierte fra tjeneste til tjeneste, og i tillegg er det tungvint å bruke RegEx til dette (Coding Horror, 2009). Etter noe research fant vi ut at HTMLAgilityPack kan gjøre dette på en mer effektiv måte, den lar oss sile ut lenker fra ren tekst ved å lete etter html-attributter i en tekst. 45

46 Figur 24 Eksempel på bruk av HTMLAgilityPack for å isolere ekstern lenke Kategorier og fasiliteter Vi ønsket i utgangspunktet å ha et fast sett med kategorier og fasiliteter. Siden vi slet med å hente ut fasilitetene fra CBIS, grunnet veldig kompleks datamodell som hjelpeprosjektet ikke kunne hjelpe oss med, blir vi nødt til å basere denne delen av oppgaven på dataene vi fikk fra Tellus. Alle kategorier og fasiliteter vi får inn fra Tellus har en id, så vi regnet med at det fantes en oversikt over disse. Via ansatte i Creuna fikk vi dessverre vite at Tellus ikke vil gi fra seg noen oversikt, verken over kategorier eller fasiliteter. For å i det minste få en viss oversikt, utformet vi derfor et lite program som hentet inn alle produkter i Norge på norsk, og hentet ut alle kategorier og fasiliteter hvert enkelt produkt hadde, for så å skrive disse til en fil. Utskriften formaterte vi slik at alle kategorier ble sortert på id-en, i tillegg til at alle underkategorier og fasiliteter havnet under tilhørende kategori eller fasilitet med innrykk for å lette lesbarheten. Resultatet viste at det i Tellus per var 1660 kategorier og nærmere 1900 forskjellige fasiliteter. Det var langt fra så strukturerte data som vi hadde håpet på. Det virket som om det en 46

47 gang i tiden hadde vært god struktur i kategoriene og fasilitetene, og toppen av hierarkiet fungerer fortsatt med hovedkategorier og -fasiliteter, men brorparten av underkategoriene og fasilitetene så ut som de tilsynelatende er lagt til fordi man ikke fant en passende fasilitet eller kategori blant de eksisterende, og dermed ble veldig spesifikke. Id-ene var heller ikke unike. Vi ble rådet til å være pragmatiske av veilederne, og valgte derfor å lage en enkel kategoristruktur for å forsøke å konvertere i det minste noen av de 1660 kategoriene til enklere og senere lettere søkbare kategorier. Dette gjorde vi ved å lage en statisk samling av forhåndsbestemte kategorier (se figur 25), og en konverteringsklasse, TellusConverterHelpers.Categories, som manuelt sjekker kategorien som kommer inn opp mot visse kriterier (figur 26). Slik fikk vi i hvert fall konvertert en del av kategoriene over i en egen struktur. Resultatet ble selvfølgelig ikke like bra som vi skulle ønsket, men å manuelt gå igjennom alle kategorier ville tatt for lang tid i forhold til hvor liten del av oppgaven dette er. Kategoriene fra Tellus kan også forandre seg fra dag til dag, da det kommer an på hvilke produkter som er tilgjengelige. Figur 25 - Konstruktøren i den statiske klassen DomainCategories som oppretter en samling av kategorier og underkategorier 47

48 Figur 26 - Utsnitt av TellusConverterHelpers.Categories, som sammenligner først forelderkategoriens id for å finne riktig hovedkategori, for deretter å sjekke opp mot underkategorienes id Når det gjelder fasiliteter, vurderte vi lenge å lage en lignende løsning, men fant ut at det ville tatt altfor mye tid. Vi prioriterte derfor å gå videre med prosjektet, og lagrer nå derfor bare fasilitetene slik de kommer. En viktig del av oppgaven handler jo nettopp om det å kartlegge og dokumentere vanskelige områder, noe dette absolutt kan klassifiseres som Sletting Tellus har, som nevnt tidligere, en del regler rundt sletting av data. Produktene som er slettet hos Tellus skal også slettes fra vår database. I følge Tellus vilkår kan vi ikke sette produktet som inaktivt eller utilgjengelig; dataene må fjernes helt fra databasen. CBIS hadde ingen spesifikke regler rundt dette, så vi har behandlet sletting av data fra dem på samme måte som fra Tellus. For å få en oversikt over slettede produkter fra Tellus er man nødt til å sende med et tidspunkt som parameter i kallet på servicen. Man vil da få en oversikt over produkter som er lagt til, endret eller slettet siden tidspunktet man har definert i kallet. Tidspunktet vi sender med som parameter er tidspunktet vi har logget for siste innhentingen i vår loggedatabase. 48

49 Vi laget metoden TellusDeleted i TellusCollector-klassen, som har som hensikt å liste ut produkter som er slettet siden forrige innhenting. Metoden sjekker om det er registrert noen dato for tidligere innhenting, hvis det finnes kaller den på GetProductList mot Tellus-servicen med datoen som parameter. Resultatet fra Tellus-servicen, en XML-streng med produkter, sendes til TellusConverter-klassen sin DeletedProducts-metode. Her traverseres det gjennom XMLen og id-en til de slettede produktene hentes ut og legges i en collection kalt deletedproductscollection. Denne collectionen vil da inneholde oversikt, i form av deres eksterne id, over alle produkter som skal slettes fra databasen, og vil bli sendt videre til persisteringsløsningen som vil håndtere selve slettingen. Dette beskrives nærmere under delkapittelet Persistering. 4.4 Persistering Teknologi og valg Det var stor enighet i at vi skulle bruke databaser som persisteringsløsning for å lagre de konverterte dataene våre. Siden vi allerede hadde skrevet datamodellen vår i Code First, var det en enkel sak å koble den mot en database. Vi bestemte oss for arbeide mot lokale databaser, da det var det enkleste i forhold til å gjøre separate testoperasjoner. Med hjelp av Microsoft SQL Server opprettet vi hver vår lokale database på maskinene våre, og endret tilkoblingsparameterne i løsningen vår til å peke på den lokale basen Lagring til database Vi laget et eget prosjekt, kalt SaveToDb, for å lagre dataene våre til en database. Siden dette prosjektet ikke er ment å tas i bruk slik som det er, lagrer vi til lokale MS SQL-databaser på datamaskinene våre. Vi benyttet oss av Code First for oppretting av tabellene. 49

50 Figur 27 DbContext-klassen vår som gjør at vi kan opprette en database Code First Først laget vi lagringsmetoder som baserte seg på en samling av de språkavhengige ProductInfoene, itererte gjennom disse og lagret de og tilhørende objekter i tabellene. Via et ProductInfo-objekt har vi enkelt tilgang til de andre tilhørende entitetene. For hvert objekt sjekker vi om det allerede finnes, og hvis det finnes, sjekker vi om modifiseringsdatoen er nyere enn datoen til objektet vi allerede har lagret. Dersom objektet allerede finnes og ikke er modifisert, hopper vi videre til neste ProductInfo-objekt. Hvis det ikke finnes, henter vi først tilhørende entiteter fra databasen, dersom de eksisterer, for å hindre dobbeltlagring. Dette gjelder Categories, LocalOrgs, Owners og Postal. Deretter lagres hele ProductInfo-objektet og alt som henger sammen med det. Dersom produktet er modifisert, må vi oppdatere alle eksisterende felter i databasen. Vi logger også hvilke objekter vi legger til og oppdaterer i en egen loggingsdatabase. 50

51 Figur 28 Lagringsmetoden slik den var i begynnelsen Det viste seg at å bruke domenemodellen vår som databasemodell ikke gikk helt smertefritt. Blant annet ble det laget koblinger fra kategoriene til produktene, noe vi ikke ville ha. Etter å ha gjort noen små endringer på domenemodellen som å legge til virtuelle samlinger av objekter der vi ville ha hjelpetabeller, for eksempel mellom kategorier og produkter, fungerte det hele mye bedre. Figur 29 - Klassen Category har fått en virtuell samling av Products for å kunne generere riktige tabeller med Entity Framework Code First Oppdatering På bakgrunn av reglene til produktleverandøren Tellus, som sier at alle felt skal oppdateres dersom et produkt har blitt oppdatert og at alle produkter skal overskrives en gang i måneden, laget vi to forskjellige oppdateringsmetoder. Den ene metoden, UpdateProduct, går igjennom et ProductInfo-objekt, tar vare på Id-en, og sletter eller overskriver all annen data. Den andre 51

52 metoden, UpdateAll, kjøres dersom all data skal oppdateres, og kaller på den første metoden for hvert ProductInfo-objekt vi får inn. UpdateAll-metoden tar ikke hensyn til eventuelle objekter som bør bli slettet; dette fordi den tar utgangspunkt i dataene som kommer inn, og ikke dataene som allerede ligger i databasen. Slettede produkter håndterer vi heller i en egen metode som skal kalles daglig, og som sjekker hvilke produkter som har blitt slettet siden sist vi kjørte denne metoden. For å teste metodene våre, hentet vi alle produkter fra testdatabasen til CBIS, og alle produkter i Oslo på engelsk, tysk, spansk og norsk fra Tellus. Dette er i overkant av 1900 produkter og omtrent 7600 ProductInfoer. Innhentingen tok rundt tre kvarter. Så kjørte vi en full oppdatering av disse dataene. Som vist i figur 30 under, tok dette i overkant av 19 timer, noe som er altfor lang tid. 52

53 Figur 30 Full oppdatering, eller reset, av databasen basert på 1948 produkter, noe som tok over 19 timer Forbedring av lagring og oppdatering For å få kuttet ned på tiden, skrev vi om lagrings- og oppdateringsmetodene i Saver-klassen. Vi forsøkte å kutte ned på antall spørringer til databasen, og hvor mye som skulle være lagret i minnet mens det kjørte. Den viktigste forskjellen var kanskje likevel at vi istedenfor å lagre for hvert ProductInfo, forandret dette til å lagre for hvert Product. Product-dataene ble nemlig overskrevet flere ganger, en gang for hvert ProductInfo-objekt. Ved å isteden få inn en samling av produkter, og lagre og overskrive disse dataene kun en gang, for så å overskrive og lagre dataene for hvert av produktets ProductInfo, ville databasen spares for mye arbeid. For å få til dette måtte vi gjøre en liten endring i modellen vår, nemlig at produkt må ha en samling av 53

54 ProductInfoer, i tillegg til at vi forandret returverdiene til Collector-klassene til Collections av Products istedenfor ProductInfos. Figur 31 Lagringsmetoden etter omskriving Etter omskrivingen tok innhenting og lagring av nye objekter en halvtime, og full oppdatering av alle objekter var nede i ni timer. Dette er en stor forbedring, men absolutt ikke bra nok. Etter å ha tittet litt på koden, fant vi ut at det muligens var loggingen som stjal mye tid. For hvert objekt vi la til eller oppdaterte, åpnet vi en ny tilkobling til databasen for å logge dette. Vi har derfor foreløpig valgt å kommentere ut loggingen. I tillegg gjennomførte vi andre enkle grep som å gjøre om de fleste try-catch til if-sjekker, siden dette tar mindre ressurser. Vi kjørte også en veldig enkel sjekk på UpdateAll-metoden, hvor vi istedenfor å kjøre oppdatering for hvert produkt som skulle oppdateres, kjørte en simpel metode som telte antall produkter den loopa igjennom. Dette gikk radig, og bekrefter at det er i UpdateExistingProduct flaskehalsen ligger. Vi fikk også tips fra veilederne om at det å caste fra DomainBase til Product i UpdateAll når vi visste at det var en liste av products vi fikk inn, var unødvendig og kunne også stjele litt ressurser. Vi forandra derfor metoden til å ta inn en liste av produkter, og returnerer også en samling av produkter fra Collector-klassene istedenfor samling av DomainBase. Alt dette så ut som det hjalp litt på tida, men ikke nok. 54

55 Gjennombrudd Gjennombruddet fikk vi da vi flyttet tilkoblingen til databasen, det vil si «using(var db = new ProductContext()», til inni foreach-løkka som går igjennom hvert produkt som skal oppdateres, istedenfor å ha den på utsiden (se figur 32). Dette gjør at vi oppretter en ny tilkobling for hvert produkt, og ikke bruker samme tilkobling gjennom hele lista. Total tid på innhenting og oppdatering av 1971 produkter og 7770 ProductInfoer tok nå kun 8 minutter. Vår logikk om at en tilkobling er kjappere enn flere tilkoblinger, stemte tydeligvis ikke. Etter denne oppdagelsen gjorde vi også om på de andre lagrings-metodene i Saver slik at de følger samme metode. Figur 32 Ny opprettelse av forbindelse til databasen for hvert nytt produkt Figur 33 Graf over hvor lang tid innhenting, konvertering og lagring tok opprinnelig, og etter første og andre optimalisering 55

56 4.4.5 Sletting I utgangspunktet var det en del usikkerhet rundt hvordan vi skulle håndtere slettede produkter, vi kom frem til at dette kunne gjøres på flere måter. En av løsningene vi vurderte var å kunne «flagge» produkter som inaktive, altså sette en boolean på hvert produkt som sier om det er aktivt eller ikke. Etter å ha gått gjennom reglene fra produktleverandørene fant vi ut at Tellus setter krav til at data rundt produkter som ikke lenger er i bruk må slettes fra vår database. Dette førte da til at vi lagde Deleter-klassen i SaveToDB-prosjektet. Denne klassen skulle ha som oppgave å håndterere slettingen av produkter i databasen vår, uansett fra hvilken produktleverandør de har kommet fra. Vi valgte å behandle sletting likt for alle produktleverandører for å holde vår egen database ryddigere i tillegg til å gi våre APIkonsumenter trygghet i at data rundt produkter som ikke lenger er aktive ikke vil være mulig for dem å få tak. For å få til dette startet vi med å slette oppføringer basert på produktenes interne id, den som er i vårt system. Denne id-en viste seg å ikke være helt hensiktsmessig å gå ut i fra, fordi det vil innebære at produktene først må lagres i databasen vår, bli tildelt en id av systemet og så slettes etterpå. For å gjøre dette mer effektivt baserte vi slettingen på informasjon levert av produktleverandørene. Alle produkter som skal slettes har en id fra systemet det ble levert fra, enten CBIS eller Tellus, denne id-en har vi beholdt i vår modell som et produkts eksterne id. Denne eksterne id-en kan være lik på tvers av ulike produktleverandører, vi har ingen kontroll på hvordan deres nummereringssystem og logikk fungerer. Derfor endte vi opp med å opprette en modell for slettede produkter med to egenskaper, ekstern id og ekstern leverandør, disse verdiene sendes med som parameter fra der Delete()-metoden kalles. Deretter kobler metoden til databasen og fjerner produktet samt dets tilhørende data fra andre tabeller Databaselogging Etter hvert som vi fikk på plass databasen begynte vi å vurdere behovet for en separat database som logget hva slags oppdateringer vi gjorde mot den. Selv om dette ikke var medberegnet i tidsplanen, bestemte vi oss for å lage en. Denne databasen skulle logge hva slags oppdateringer 56

57 som ble gjort, hvor mange produktinfoer som ble lagt til og hvor mange produkter som er oppdatert eller slettet. Loggedatabasen fikk en svært enkel datamodell der man kun skulle lagre et «merke» på hvert produkt eller produktinfo som ble påvirket per oppdatering. Ingen av tabellene har noen direkte relasjoner til hverandre, men blir sammenlignet per dato for å knytte oppdateringene (ExecutedUpdates) mot de øvrige tabellene. Figur 34 - Klassediagram over logge-databasen Vi lagde også en metode for å skrive ut en enkel oversikt over alle oppdateringer som var blitt gjort, hva slags type oppdatering det var samt hvor mange objekter som hadde blitt påvirket. I figur 35 under er den skrevet ut i konsollvinduet inne i Gatherer: Figur 35- Konsollvisning av logginger som er blitt utført 57

58 Feltet «ResponseTime» i tabellen ExecutedUpdates fikk en viktig rolle for innhentingen fra Tellus. «ResponseTime» inneholder tidspunktet for forrige suksessfulle innhenting av produkter fra servicen til Tellus. Dette tidspunktet blir sendt med som parameter for å kunne hente ut produkter som er slettet i tidsintervallet mellom forrige innhenting og det nye kallets tidsstempel. Dette er forklart nærmere under kapittelet Innhenting og konvertering. 4.5 Web API Valg av teknologi Web API-et vårt skal brukes direkte av nettstedet Visit Norway, appen VisitNorway og eventuelt andre klienter dersom API-et skal være åpent. Det er derfor et krav at det skal være raskt og enkelt å bruke. REST For at API-et skal være så raskt som mulig, valgte vi å bruke REST, en type Web Service som er tilstandsløs, har enkle operasjoner og er plattformuavhengig. REST er kjappere og enklere å implementere enn for eksempel SOAP (SearchSOA, 2013). API-et skal dessuten kun gi ut data; de skal ikke manipuleres på noen som helst måte. URL-oppbygning Basert på REST-retningslinjer (Learn REST, udatert), valgte vi logiske URL-er i API-kallene, det vil si API/Kontroller/Parameter istedenfor API/kontroller-parameter.xml. OData Vi valgte å implementere OData, en REST-basert web-protokoll anbefalt av Microsoft som definerer en standardisert måte å gi ut data på (ASP.NET, 2014a). AutoMapper Siden vi ikke ville eksponere alle dataene, og derfor laget en egen API-modell, trengte vi å konvertere dataene fra domenemodellen til API-modellen. Til dette valgte vi å bruke AutoMapper, et verktøy som gjør det enklere å konvertere objekter fra en type til en annen (AutoMapper, 2014) og som er mye brukt hos oppdragsgiver. 58

59 4.5.2 Implementering API-modell Vi fant fort ut at vi burde lage en egen visningsmodell for dataene som skulle eksponeres. For eksempel trenger ikke API-konsumentene tilgang til alle id-ene som brukes til å holde styr på alle objektene som henger sammen i databasen vår, og de trenger heller ikke vite hvilken leverandør dataene kom fra originalt eller den eksterne id-en til produktene. I tillegg burde variabler som i domenemodellen er DateTime-objekter eller enumer omgjøre til stringer for økt lesbarhet. Vi tenkte først at produktene i API-modellen skulle arve id av ProductInfo-objektene, men innså at hvert produkt da ville ha forskjellig id på forskjellig språk. Derfor var det bedre å la APImodellens produkter arve fra Product-objektet, og heller kreve at det alltid skulle presiseres hvilket språk man ville ha dataene på. På denne måten er nøkkelen til produktet både språk og id. Figur 36 Generert UML-diagram over API-modellen 59