Erfaringer med tjenesteutvikling i Altinn

Vi har jobbet sammen med Direktoratet for byggkvalitet, KommIT og Altinn med å lage en løsning for innsending av elektroniske byggesøknader. Foreløpig har vi bare tatt for oss en liten del av byggesøknaden, nemlig nabovarsel. Vi har opprettet en innsendingstjeneste i Altinn og gjort det mulig for tredjepartsverktøy å sende inn nabovarsel. Disse nabovarslene blir så tatt vare på av Altinn og de kan hentes ut igjen ved hjelp av Altinns nedlastingsløsning. Det var kort fortalt prosjektet og nå skal jeg ta for meg noen av erfaringene våre underveis i arbeidet med tjenesteutvikling på Altinn-plattformen.

Altinns REST-API

Altinn har lansert et REST-API som gjør det mulig å ta i bruk tjenestene deres fra en ekstern webapplikasjon. APIet aksepterer data på formen application/hal+xml og application/hal+json og det fungerer i grunn veldig bra. Du kan spørre mot meldingsboksen til en bruker og deretter få listet opp meldinger og URL-template for videre navigering.

Respons fra GET https://www.altinn.no/api/my/messages

 { "_links": { "self": { "href": "https://www.altinn.no/api/my/messages" }, "find": { "href": "https://www.altinn.no/api/my/messages/{MessageId}", "isTemplated": true } }, "_embedded": { "messages": [ { "MessageId": "a385107", .... }, { "MessageId": "a385107", .... } ] } } 

Lang roundtrip

For å ta i bruk APIet må du sende inn en søknad for å få tildelt en API-nøkkel og videre må URLen til applikasjonen din bli whitelistet. URLer som ikke er whitelistet blir ikke godkjent og dette gjør at det er tungvindt å gjøre testing mot APIet. Localhost er jo ikke godkjent, så API-kall fra lokalt deployede applikasjoner blir avvist. Dette gjør at du må enten må deploye til produksjon, eller få whitelistet en eller annen utviklingsserver. Uansett så gjør det at det kan bli en litt lengre roundtrip en det som strengt tatt er nødvendig. Vi laget en webapplikasjon med ASP.NET MVC og endte opp med å deploye denne til testserveren hver gang vi hadde gjort en liten endringer. Dette blir tungvidt sammenlignet med å kunne teste lokalt.

Hadde prosjektet hatt en lengre tishorisont hadde vi nok kontaktet Altinn for å se på løsninger på dette problemet. Muligens kunne bruk av xip.io (wildcard dns), sammen med en ekstra whitelisting hos Altinn, løst problemet vårt.

Det hemmelige autentiseringstrikset

Autentisering gjøres vha ID-porten eller brukernavn og passord som er registrert i Altinn. Ved forsøk på å hente meldingsboksen til en bruker uten å være autentisert får du en HTTP redirect som peker til ID-portens påloggingsside. Men etter at brukeren har autentisert seg så blir vedkommende sendt tilbake til URLen til meldingsboksen og ikke din applikasjon. Dette gjør det rimelig håpløst for utviklere av tredjepartsapplikasjoner.

Men det finnes heldigvis et hemmelig triks. Ved å sende brukeren til /Pages/ExternalAuthentication/Redirect.aspx?returnUrl=https://webapp.firma.no/autentisert så kan du bestemme hvor brukeren skal bli sendt etter å ha blitt autentisert. Vi brukte litt tid på å finne ut av dette da det ikke stod noe sted på Altinns dokumentasjonssider.

Vårt tips er å skaffe seg kontakt med minst 1 og gjerne flere løsningsarkitekter fra Altinn. De har god peil på hvordan man kan løse ulike problemstillinger og de hjelper til med å finne frem i mylderet av dokumentasjon for Altinn-plattformen. Det er nemlig ikke et problem at det ikke finnes dokumentasjon, det er bare så mye dokumentasjon at det er vanskelig å finne frem.

SERES og Infopath – ikke for utviklere

For å lage en innsendingstjeneste i Altinn må du ha en datamodell og et skjema brukeren kan fylle ut. Datamodellen lager du med SERES og skjemaet lager du med Microsoft InfoPath. Har du en liten datamodell så er SERES enkelt og greit. Men har du en stor datamodell så må du regne med å bruke mye tid, klikking og scrolling i SERES Domeneklient. SERES Domeneklient er nemlig listebasert og det blir fort mye skrolling og klikking frem og tilbake for å få oversikt over alle objektene. Har du en litt kompleks modell som du allerede har en UML-modell eller klassediagram over så er det veldig fort å miste tråden inne i listene i domeneklienten.

For domeneeksperter så er nok kombinasjonen SERES Domeneklient og InfoPath gull verdt. Sett opp datamodellen og deretter sett opp skjema i noe som nesten ligner på word, og du har en fiks ferdig tjeneste i Altinn. Skal du inne og legge til et felt så gjøres dette veldig raskt uten å måtte dra inn IT-avdelingen eller noen andre eksterne konsulenter.

Når du så har fått ordnet deg en datamodell (XSD) så er det på tide å lage skjemaet. Synes du formatering kan være knotete å få til i Word, kan du glede deg til å jobbe med InfoPath. Jeg slet med å endre en kursiv tekst i skjemaet, det var rett og slett ikke mulig å få fjernet formateringen:

infopath-kursiv

Jeg mistenker at noe av årsaken til problemet ligger i grunnmuren under InfoPath, XSLT. InfoPath sitt lagringsformat (.xsn) er egentlig en CAB-fil, Microsoft sin gamle arkivformat. Der ligger det blant annet en XSLT. En slik fint formatert XSLT produsert av InfoPath kan f.eks se slik ut:

</p><div class="xdSection xdRepeating" style="margin-bottom: 0px; width: 100%; border: 0pt;" tabindex="-1" title="" align="left"><div>
Med så mye hardkodede stiler rundt omkring på diverse elementer så er det ikke så rart at formatering av skjemaet er utfordende. XSLT transformasjonen kjøres ved visning av skjemaet i Altinn og ved f.eks generering av utskriftsversjon av skjemaet. XSLT er greit nok det, men slike formateringsproblemer kan gi mange grå hår.Kort fortalt er ikke SERES og InfoPath egnet for utviklere. Det er egnet for domeneeksperter, men ikke for oss kontrollfreaker.SnarveienMen du kan ta en snarvei og droppe SERES, lage din egen XSLT og bare la InfoPath være noe du har hørt om. Det gjorde vi.
  • Ta datamodellen din (XSDen) og opprett et tomt skjema i InfoPath – lagre skjemaet.
  • Bytt filendelse fra .xsn til .cab og pakk opp fila.
  • Åpne view1.xsl og sett igang med å skrive din egen XSLT.
  • Når du er ferdig med skjemaet pakker du sammen filene du pakket ut, sammen med den oppdatert xslt-fila.
  • Bytt filendelse tilbake til .xsn og sjekk at du får åpnet fila i InfoPath (høyreklikk og velg Utform).
  • Last opp InfoPath-fila til Altinn.
Du har nå laget ditt første skjema Altinn uten å få nevneverdig ekstra med grå hår.Triks for å blidgjøre InfoPathapplytemplates with modeAlle xsl:apply-templates og xsl:template tagger må ha med mode-attributtet, hvis ikke blir InfoPath misfornøyd. Dette gjelder uansett om du bare har en template som matcher et enkelt objekt.
 ... 
Riktig standardverdier og eksempeldatatemplate.xml som ligger inne i InfoPath-fila må være oppdatert med riktige xml-felter og inneholde standardverdier for alle felt i skjemaet. Når du oppdaterer xml-skjemaet må du passe på å holde template.xml i synk slik at feltene stemmer og at alle felt har standardverdier. sampledata.xml inneholder eksempeldata knyttet til skjemaet, men jeg vet ikke hvor viktig det er å holde denne i synk. Men når du uansett oppdaterer template.xml er det fort gjort å gjøre det samme med sampledata.xml.KildekodenKildekode inkludert Altinn-skjema og datamodell finner du her: https://github.com/Arkitektum/ebyggesoknad-poc
Kode
Beskrivelse
 
Tags:

Adresse

Arkitektum AS
Postadresse:
Postboks 4
3833 Bø i Telemark

Besøksadresse:
Hellandtunet
Kyrkjevegen 6
3800 Bø i Telemark

Kontakt

Tlf: 35 59 59 00
Epost: post@arkitektum.no
Orgnr: 914 994 780 MVA