Mjukvarudokumentation Sambruks eansökan Bistånd

Transkript

1 eansokan_sw_dok_v0_1_ doc 1(8) Mjukvarudokumentation Sambruks eansökan Bistånd Innehåll: Mjukvarudokumentation Sambruks eansökan Bistånd... 1 Inledning... 2 Applikationsarkitektur... 3 Mjukvarustruktur... 4 Lagring... 6 Driftning och konfigurering... 7 Dokumentversioner: Sven-Håkan Olsson Etablering av dokumentet.

2 eansokan_sw_dok_v0_1_ doc 2(8) Inledning eansökan Bistånd är en webbapplikation som syftar till att en medborgare ska kunna ansöka via en e-tjänst till en kommuns socialförvaltning (motsv) om ekonomiskt bistånd / försörjningsstöd. Sambruk började arbeta med dessa tankar redan ca 2003 men det har funnits olika hinder som har gjort att det är först i en nylig omstart som eansökan verkligen har materialiserats. Utvecklingen har skett genom processkartläggning, begreppsdefinitioner, juridikgenomgångar samt skisser och olika prototyper för användargränssnitt och applikationslogik. Den nuvarande applikationen har tillkommit successivt, i början som en prototyp och med tiden mer och mer som en konkret driftbar lösning. Detta successiva utvecklingssätt, tillsammans med en begränsad budget gör att vissa delar av applikationen i den bästa av världar skulle kunna refaktoriseras för att få en elegantare intern struktur. Om en större sådan refaktorisering skulle kunna motiveras, baserat på en avvägning av större nytta relativt behövd kostnads- och tidsinsats, kan naturligtvis diskuteras. Hittills har bedömningen varit att det går att arbeta vidare ett bra tag utan större refaktoriseringar. Leveranser/driftfaser: Under 2011 har eansökan kunnat användas med verkliga ansökningar för att utvärdera funktionen för kommunen och för de sökande. I den fasen har dock inlämningen fått ske genom utskrift och undertecknande på papper. Eftersom ingen lagring av känslig info gjordes i denna fas kunde applikationen enkelt driftas i Amazon EC2 på Irland. Sedan februari 2012 har det funnits en version som gått att använda med elektronisk inlämning av verkliga ansökningar och där handläggare loggar in för att hämta över ärendena elektroniskt till kommunen. Tvåfaktorsinloggning har använts, med SMS-engångskod, förberett för eid. Applikationen driftas numera i Sverige, hos Strongbox, för att slippa diverse säkerhets- och juridikproblem. Kommande versioner planeras vara integrerade med kommunernas verksamhetsapplikationer så att ärendeinformationen automatiskt kan föras över hela vägen. Likaså planeras integration med informationshämtning från centrala myndigheter. Applikationen är skapad för att kunna vara en SaaS-applikation (Software as a Service) i molnet. Den är alltså grundläggande byggd enligt multi-tenant-principerna så att det blir mycket rationellt att hantera en enda instans källkod för många kommuner och att det ändå är tydliga myndighetsgränser inom applikationen.

3 eansokan_sw_dok_v0_1_ doc 3(8) Applikationsarkitektur Lösningen är skapad i Microsofts ASP.NET med VB.NET. Det går bra att använda gratisversionen Visual Web Developer 2008 Express Edition som utvecklingsverktyg. Huvuddelarna använder ASP.NET v2 men några småsaker ur v3.5 behövs också. Arkitekturen är mycket enkel, allt finns i en webb- och applikationsserver på okomplicerat ASP.NET-vis. Ingen SQL-databas behövs heller (se kapitlet Lagring). Lösningen använder masterpages i ASP.NET. Viss Javascriptanvändning finns också framförallt för att öka användarvändligheten. De enda externa beroendena i dagsläget är till en SMS-sändningstjänst (idag via Ballou) och till en SMTP-sändare för e-post. I en framtid tänks applikationen kopplas ihop med komponenter inom Multifråga så att myndighetsdata online kan tas in i ansökningarna. Då blir arkitetkturen mer komplex - se dokumentation om Multifråga. Vissa komponenter är återanvända av eansökan ifrån Multifråga som ju utvecklades före, t ex loggning mm. Inloggning etc har viss återanvändning från ett annat externt projekt.

4 eansokan_sw_dok_v0_1_ doc 4(8) Mjukvarustruktur Den normala Web Forms-strukturen från ASP.NET v2 används. Mönstret med code-behind används: I aspx.vb-filerna ligger fältvalidering, feltexter och grovlogik för varje åtgärd. Aspx.vb-filerna anropar i sin tur kod i olika klasser under App_Code : o Ett antal klasser isolerar lagringsåtkomst, exempelvis InfoStorageApplications. Dels är detta en etablerad och bra grundprincip i sig, dels blir det enklare att anpassa i det fall lösningen byggs ut i framtiden på ett sådant sätt att en SQL-databas skulle kunna motiveras. o Klassen Utils innehåller ett antal behändighetsrutiner, t ex för loggning. Några enstaka programsatser som är GUI-nära använder ASP.NET v1-mönstret och ligger inline. Ambitionen har varit hög vad gäller undantagshantering. En avvägd kombination av exceptions och returkoder används. Loggningen är ambitiös. Möjligen kunde man i en framtid överväga att gå över till det nyare MVC-mönstret i senare ASP.NET-versioner, men av de utvärderingar man finner på Internet så brukar det anses att MVC inte bör användas till mindrelösningar och då det är få utvecklare som arbetar parallellt varför det inte är säkert att en sådan investering skulle löna sig. Möjligen kunde man i en framtid utreda ifall dagens multipla formulär och den hantering för att hålla parallella formulärs inmatade fält samtidigt i minne kunde bli enkare med MVC. Själva formulären är realtivt många till antalet, relativt komplexa och har relativt många fält. Eftersom de byggdes med masterpage-principen så är varje formulär varsin aspxsida. En klar nackdel med sådana kan vara att det är stor risk att användaren klickar sig ifrån sidan på ett sätt så att inmatat data inte sparas. Det fanns även ett uttalat verksamhetskrav på att varje sida explicit måste godkännas av sökanden för att försäkra att kommunen har på fötterna om det skulle bli en tvist kring bedrägeriförsök eller slarv. För att klara dessa saker så lagras alla inmatade formulärssidors fält i sessionsvariabler. För att dessutom ge liknande bekvämlighet som en fetklientlösning så lagras ett halvifyllt formulär automatiskt ner på disk. Så om den användaren återkommer så finns fälten ifyllda som vid förra tillfället, utan att man måste klicka Spara e dyl. Dessa bekvämlighetsskapande åtgärder har uppfattats mycket positivt av användarna men har visat sig relativt krångliga att programmera - och det finns mycket trivialkod som ska utföras för alla fälten. Därför finns det en halvautomatisk genereringsrutin som kan kommenteras bort och som genererar programkod för alla fält, till separata filer. Därifrån får koden klippas in i rätt klasser, men kvaliteten torde öka avsevärt genom att man slipper skriva alla dessa trivialprogramrader manuellt.

5 eansokan_sw_dok_v0_1_ doc 5(8) En variant av fältundanlagringen som nämns ovan är att sökanden ska kunna plocka upp förra månadens ansökan. Ett dokument behövde skapas som sökanden kan granska och godkänna för inlämning som ansökan, liksom för handläggare att kunna ladda ner som original till kommunen. Detta görs genom att specifika html-filer genereras för en viss ansökan. Under ifylland är dessa filer temporära, men då sökanden godkänt och lämnat in så betraktas dessa filer som anhängiggjort original. Då handläggare hämtat över filen/infon till kommunen och försäkrat sig om att hämtningen gått bra markerar handläggaren detta, och originalet anses överfört till kommunen. Filen som finns i tjänsten kan sedan rensas på lämpligt sätt. För alternativet att inte lämna in elektroniskt utan istället skriva ut och underteckna med bläckpenna så används en CSS som har separata definitioner för mediatyperna webbvisning och för printning.

6 eansokan_sw_dok_v0_1_ doc 6(8) Lagring För att hålla ner både kostnader och komplexitet så används ingen SQL-databas i lösningen, utan allt lagras som vanliga filer, delvis med inspiration från klassisk Unix. Fillagringen motiveras också av att nästan alla persistensbehov är av hierarkisk karaktär i den här typen av applikation varför SQL:s alternativa uppslagningsmöjligheter inte tillför speciellt mycket. Några viktiga lagringsytor: Konfigurationsparametern SB_BE_Applications_DataDir pekar ut var inlämnade ansökningar lagras. SB_BE_Participants_internal_DataDir pekar ut var info om användare lagras (t ex mobilnummer för SMS-engångskod). SB_BE_CF_LoggFilsPlats pekar ut var loggar läggs. Vidare dokumentation om hur filytorna används återfinns i XML-kommentarer i de klasser som kapslar in datalagringen, t ex App_Code\ InfoStorageApplications.vb. Lagringen måste ges adekvat åtkomstskydd eftersom hög sekretess gäller för information som lagras i samband med socialärenden.

7 eansokan_sw_dok_v0_1_ doc 7(8) Driftning och konfigurering Typiskt driftas lösningen i Windows Server Huvuddelarna av applikationen använder ASP.NET v2 men några småsaker ur v3.5 behövs också. De normala serverrollerna för ASP.NET-lösning används. AD behövs inte. Möjligen går det att använda Windows Server 2003 också men det är inte utprovat. Inga ytterligare komponenter än som finns direkt i Windows Server 2008 behövs. Ingen SQL-databas används utan alla datastrukturer lagras på enklaste vis direkt i filsysytemet. Driftkraven blir därmed att filsystemet ska lagras speglat för att skydda mot diskkrasch. För att skydda mot programfel och operatörsmisstag ska säkerhetskopia tas periodiskt, minst varje dygn. För att ge katastrofskydd ska säkerhetskopia lagras på annan geografisk plats än driftserverns. Applikationen är inte tung, vid mindre last räcker t ex virtuell server på 2,5 GHz och 2 GB RAM. När användningsfrekvensen och lasten ökar får förstås prestanda utvärderas och större server anordnas. Kluster med lastdelning på http-nivå går utmärkt, men s.k. sessionsaffinitiet behövs (dvs om en användare har börjat sin session på en klustermedlem så ska den fortsätta där), detta beror på att ASP.NET:s sessionsparametrar lagras i primärminne i servern. Vid kluster ska naturligtvis samma filyta kunna nås från alla klustermedlemmar. Som brukligt ligger ett antal konfigurationsparametrar för applikationen i web.config. Stor aktsamhet måste iakttas vid installation av ny applikationsversion så att inte en web.config från utvecklingsmiljön skriver över driftsversionen, ett vanligt ASP.NETproblem. Parametrarna i web.config är ganska utförligt dokumenterade i kommentarer i filen. Några parametrar kan särskilt nämnas: Olika lagringsytor som applikationen använder pekas ut så att anpassning till olika driftsscenarios kan ske. Multitenant-hantering för olika kommuner som använder lösningen sker via ett system av konfigurationsparametrar vars namn börjar på organisationsnumren hos kommunerna. Viss verksamhetslogik styrs också av parametrar per kommun. Verbosity hos händelseloggningen i applikationen kan styras. Ett demoläge kan ställas in där data mm fejkas. Normalt kör lösningen i Default App-pool vilket innebär att lagringsytorna som pekas ut i web.config typiskt ska ha Modify-rättighet för den speciella pseudoanvändaren IIS AppPool\DefaultAppPool. Applikationen behöver både möjlighet till sändning av SMS och e-post. I dagsläget används Ballous SMS-gateway och en vanlig standard SMTP-sändare för e-post. Dessa har specifika parametrar i web.config.

8 eansokan_sw_dok_v0_1_ doc 8(8) Driftningen måste ges adekvat skydd eftersom hög sekretess gäller för information som lagras i samband med socialärenden. Se t ex Datainspektionens råd och riktlinjer.