Skip to content
Mikael Svensson edited this page Jun 23, 2014 · 3 revisions

Integration med Aktivitetsbanken

För att de olika applikationerna som omnämns i det här dokumentet ska kunna ha någon information att visa över huvud taget så måste utvecklarna på något sätt få tillgång till den data som i dag finns sparad i Aktivitetsbanken. Detta kan uppnås på ett antal olika sätt.

Alternativ 1: Scouterna publicerar API

Scouterna implementerar ett API, exempelvis REST- eller SOAP-baserat, som ger externa utvecklare (såsom oss i /dev/scout) tillgång till informationen i Aktivitetsbanken.

Detta alternativ skulle ge Scouterna fullständig kontroll över vilken data som ges ut till externa parter. Det skulle också göra arbetet med de föreslagna applikationerna mycket enkelt eftersom behovet av egna servrar och egen databas skulle reduceras kraftigt eller elimineras helt. På samma sätt skulle arbetsinsatsen från Scouternas sida bli avsevärt större.

Om de nya applikationerna blir populära skulle detta alternativ innebär ökade krav på Scouternas servrar.

Alternativ 2: Scouterna publicerar data

Scouternas delar med sig av data utan att bygga ett API. Detta skulle kunna innebära att hela, eller utvalda delar av, Aktivitetsbankens databas regelbundet exporteras och publiceras. Exporterad data skulle, exempelvis, kunna publiceras som ett XML-dokument på en http- eller ftp-server.

Även detta alternativ skulle ge Scouterna fullständig kontroll över vilken data som ges ut till tredje part. Tredje part, såsom /dev/scout, kan ladda ner den publicerade informationen och läsa in den i egna databaser/system. Detta innebär att även om Scouterna har kontroll över vilken information som publiceras så har de relativt lite kontroll över var informationen därefter används.

De som önskar använda publicerad information måste själva tillhandahålla den infrastruktur, exempelvis webbserver och databasserver, som krävs.

Detta alternativ är sannolikt det mest kostnadseffektiva alternativet ur Scouternas synpunkt eftersom det inte kräver speciellt mycket mer än att konfigurera ett schemalagt jobb som regelbundet exporterar information ur databasen. Det är också det mest flexibla alternativet för tredjepartsutvecklare, som har kapacitet att utveckla egna webbtjänster, eftersom det minimerar kraven på online-kommunikation med Aktivitetsbanken.

Alternativ 3: Scouterna tillåter “screen scraping” och extern lagring

Detta alternativ innebär att Scouterna inte gör Aktivitetsbanken mer tillgänglig än den redan är i dagsläget, dvs. via HTML och RSS. Scouterna ger dock, skriftligen, tredje part (ex. /dev/scout) tillåtelse att göra informationen i Aktivitetsbanken tillgänglig via tredje parts egna tjänster och applikationer.

Tredje part kan nu regelbundet “läsa av” HTML-sidor och RSS-flöden i syfte att bygga upp egen kopia av informationen i Aktivitetsbanken. Konkret skulle detta kunna innebära att /dev/scout läser RSS-flödet för Aktivitetsbanken i jakt på uppdateringar. Servern hämtar data från scouternas hemsida via RSS-flödet, eller “screen scraping” av HTML-koden. Data mellanlagras av egen server och egen databas. Systemet kontrollerar regelbundet (en gång per vecka) om nya aktiviteter har lagts till och då hämtas (text)informationen för dessa aktiviteter.

I detta scenario så kan det vara viktigt att skilja på information om hämtats från originaltexten och information som härletts ur densamma (ex. kategorier, länkar eller tidsåtgång) eller som lagts till i efterhand (ex. betyg, kommentarer eller alternativa namn). Det här kan hanteras på flera olika sätt:

  • Den automatiska inläsningen skapar en ny revision av aktiviteten och associerar sedan antingen en speciell “bot-användare” med revisionen.
  • Den automatiska inläsningen skapar en ny revision av aktiviteten och associerar sedan antingen en speciell “bot-referens” med revisionen. Alternativet med en “bot-referens” kan vara fördelaktigare än en “bot-användare” eftersom användaren för revisionen kan sättas till NULL (bättre än någon “fejkanvändare”) samtidigt som “bot-referensen” kan indikera både att revisionen automatgenererats och från vilken URL som informationen hämtats (referenstypen indikerar att informationen hämtats in per automatisk och referensvärdet anger URL:en).
  • Kommentarer/betyg och aktiviteter får en “ursprungskolumn” som innehåller en URI som anger varifrån informationen. Information som hämtats från en webbsida har då dess URL, ex. http://www.scouterna.se/aktiviteter-och-lager/aktivitetsbanken/aktivitet/citronleken, i den här kolumnen. Information som matas in direkt i applikationen får en URI i stil med scoutapp:user-id:123, alternativt så anges användarens id i en egen kolumn.

Att låta ett en automatisk inläsningsfunktion göra nya revisioner istället för att ändra den aktuella har också fördelen att manuellt inskriven information inte går förlorad.

Integration med andra system

I ett senare läge bör även andra system/webbtjänster med lekar och aktiviteter kunna integreras med systemet. Integrationen kommer då förslagsvis att följa en av de tre riktlinjerna som skrivits ovan (öppet API, öppen data eller "screen scrapring").

För att detta ska fungera så smärtfritt som möjligt är det önskvärt att databasschemat inte innehåller scoutspecifika begrepp i stil med "målspår" och "betygsmärke". Begreppet "målspår" kan representeras som en aktivitetskategori och ett "betygsmärke" kan representeras som "en kategori eller ett attribut som applicera på personer".