Integrasjoner mot ESA og ephorte

Mange fagsystemer produserer arkivverdig materiale, men mangler funksjoner for arkivering av dette. Vi viser hvilke muligheter som finnes for å bruke ESA og ephorte som arkiv for disse systemene. Ofte er det lite som skal til.

v/Ragnar Sturtzel, EVRY

1

Jeg er sivilingeniør fra NTH, nå NTNU. og begynte allerede før jeg var ferdig med studiene å arbeide med integrasjoner.

De senere årene har jeg arbeidet med utviklingen av ESA. Før det var jeg med på oppstarten av Doculive inkl. spesifikasjonsarbeidet for edbstøttet saksbehandling og ledelse i samarbeid med staten.

Jeg har vært aktivt med i standardiseringsarbeidet rundt sak/arkiv inkl. standardiseringen som er gjort i teknisk sektor for samspill mellom matrikkel, kart, sak og arkiv. En rekke av standardiseringsdokumentene er ført i pennen av meg og jeg kan standardene ut og inn. Eksterne leverandører benytter derfor ofte meg som rådgiver også når de skal koble seg mot andre arkivløsninger enn våre.

2

Vi vil her se på integrasjoner der «eksterne» systemer skal arkivere i et Noarkarkiv.

Både ESA og ephorte utnytter selv integrasjoner, f.eks. for å hente data fra kartet. Men dette er ikke temaet i dag.

Hensikten med nCore i ephorte5 er å kunne integrere inn i en arkivkjerne. Men ephortehar i mange år hatt EIS som integrasjonsgrensesnitt.

ESA har helt siden den kom på Web hatt en arkivkjerne med et tjenestesnitt som er felles for både vårt eget Webgrensesnitt og eksterne. I tillegg støttes standardgrensesnittene.

3

Det finnes to hovedtyper av integrasjoner…

4

Denne måten å integrere på brukes først og fremst i «skjemaintegrasjoner». Skjemaleverandøren, f.eks. DiBK med ByggSøk, tilbyr elektroniske skjemaer som søkere fyller ut. Når skjemaene er ferdig utfylt sendes de enten via e‐post eller de legges på et filområde for import inn i arkivet.

Det er svært varierende hvor mye metadata («data om data») som ligger i skjemaene. Dermed er det svært varierende hvor mye som kan gjøres automatisk ved journalføringen. Skjemaer som følger KS Resultat XML gir best muligheter. Her kan journalføringen helautomatiseres.

Noen fagsystemer som, WebCruiter, benytter denne måten å arkivere på.

Metadata ligger i XML som angir feltnavn og verdi. Mange tror at XML er standard på den måten at hvis et program støtter XML så vil det gå OK å sende en vilkårlig XML. Det blir som å si at fordi en person kan det latinske alfabetet så går det like greit å snakke norsk som fransk med vedkommende.

Siden informasjonen legges på et sted for senere journalføring vil den som sender informasjonen ikke få noen tilbakemelding om OK/ikke OK. Evt. tilbakemelding gis typisk som e‐post, men da gjerne til den som søkte.

5

Hvis det er ønskelig med tilbakemelding og hvis det er ønskelig å kunne styre arkivet mer, benytter man «dialogtjenester».

Dialogtjenestene er tilgjengelig via tjenestesnitt der klienten kan arkivere, oppdatere, samt hente ut igjen arkivert data. Det er normalt disse tjenestene man tenker på når det er snakk om integrasjon og det er denne måten de fleste integrasjoner benytter.

Som for XML finnes det mange forskjellige måter å ha dialogen på, både teknologisk og innholdsmessig. Noen måter er standardiserte slik at de virker uavhengig av hvilken leverandør man skal integrere seg mot, mens andre er laget spesifikt for et bestemt produkt som ESA eller ephorte. Det kan også finnes flere versjoner av en tjeneste.

6

Jeg vil her presentere de standardene som finnes for integrasjoner. Disse er generelt spesifisert av leverandørene i dialog med hverandre og med KS.

I tillegg kommer proprietære muligheter både for ESA og ephorte («skreddersøm»).

7

KS Resultat XML er en standard for utfylte skjemaer. XML‐en inneholder to typer informasjon, fagdata og arkivdata. I tillegg legges dokumentene inn i XML‐en kodet på samme måte som for e‐post. En KS Resultat XML‐fil inneholder derfor hele søknaden med vedlegg.

Opprinnelig ble det laget standard fagdata for barnehagesøknader. Senere har det kommet fagdataspesifikasjon for ByggSøk.

Standarden ble utviklet i 2008 av KS, Oppad, Sem & Stenersen Prokom, EDB Business Partner (nå EVRY) og Asker kommune i samarbeid med en rekke andre.

Versjon 1 av standarden bygger på Noark 4 Web Services (omtrent identisk feltinnhold).Versjon 2 av standarden, som bygger på GeoIntegrasjon Arkiv, var ute på høring i fjor.

Siden det ligger «komplette» arkivdata i XML‐en er det mulig å arkivere slike søknader automatisk.

Det er definert en del dialogtjenester i tilknytning til KS Resultat XML, men disse er i svært begrenset bruk.

8

Noark 4 Web Services ble laget for å få en standard og enkel måte for fagsystemer å arkivere på. Tjenestene bygger på Noark 4, men er noe forenklet

Tjenestene ble hovedsakelig utviklet av Gecko, Software Innovation og EDB Business Partner (nå EVRY) i samarbeid med KS. Standarden var ferdig i 2006 og benyttes av svært mange fagsystemer.

Tilbakemeldingen fra fagsystemleverandørene var at Noark 4 var altfor komplisert å forstå. Vi ryddet derfor vekk alt som ikke var absolutt nødvendig. Det største forenklingen ble gjort for dokumentobjektene der dokumentlink, dokumentbeskrivelse og dokumentversjon ble slått sammen til ett objekt og der det kun er mulig med ett dokument pr. hoveddokument/vedlegg.

Det ble også lagt inn en utvidelse til Noark: Fagsystemet kan arkivere og gjenfinne med sin egen nøkkel.

Noark 4 Web Services har kun fire tjenester:Ny sakNy journalpost (inkl. dokumenter)Hent sakHent journalpost

Noark 4 Web Services støttes av alle leverandører av generelt sak/arkiv.

Noark 4 Web Services har vist seg å stort sett holde det den lovet, men noen utvidelser og presiseringer har vært ønsket. Det arbeidet ble tatt i prosjektet GeoIntegrasjon…

9

GeoIntegrasjonsprosjektet hadde en egen arbeidsgruppe som arbeidet med forslag til Noark 4 Web Services versjon 2. Før arbeidet var ferdig var dette blitt til Noark 5 Web Services versjon 1 og inkluderte forslag til utvidelser til Noark 5 som tagging med geografisk informasjon for alle saker, fremmednøkkel på saker og journalposter, samt organisasjonsnummer/fødselsnummer for alle avsendere/mottagere.

GeoIntegrasjon var et stort prosjekt som bl.a. involverte KS, Statens Kartverk, Riksarkivet, alle sak‐/arkivleverandørene, alle GIS‐leverandørene og flere kommuner. Dette resulterte i et standard rammeverk, to oppdaterte og to nye standarder:Innsyn i arkiv (utvidelse av Noark 4 Web Services)Oppdatering av arkiv (utvidelse av Noark 4 Web Services, standardverdier)Innsyn i saksbehandling (benyttes bl.a. i plandialog og byggesaksinnsyn)Innsyn i matrikkel (for oppslag i sentral matrikkel og evt. lokale matrikkelkopier)Innsyn i planregister (støtter kravene til digitalt planregister)Samspill mellom saksbehandlingsklient, kartet og andre klienter (utvidelse av Geolok2.0)

Versjon 1.1 av standardene var ferdig 1. februar 2012 og alle sak‐/arkivleverandører har lovet støtte for denne. ESA kom med støtte for denne i versjon 8.0.2 kun en uke etter at standarden var offisiell.

Når versjon 2 av standarden kommer er det et krav om at versjon 1.1 skal støttes i minst tre år etter at den nye versjonen er klar.

GeoIntegrasjon er en del av standard ESA 8. Den leveres som tillegg til ephorte5.

10

Riksarkivet i samarbeid med KS, arkivleverandører, fagsystemleverandører og kommuner har påbegynt et prosjekt for å definere standard tjenestesnitt for en Noark 5 kjerne (p.t. «indre kjerne»).

Dette arbeidet vil resultere i justeringer av Noark 5 datamodell da de samtidig vil sementere denne i sterkere grad enn dagens krav til avlevering har gjort. Målsetningen er at arbeidet skal være ferdig til påske med siste prosjektmøter 10. og 11. april. Men det tar nok lenger tid…

11

Her ser vi hvordan kartleverandørene Norkart Geoservice og NorconsultInformasjonssystemer utnytter Arkiv innsyn og Sak innsyn i tillegg til oppslag i planregister / matrikkel.

Både Norkart og Norconsult var aktive deltagere i GeoIntegrasjonsprosjektet og sørget for at arkivtjenestene inneholdt de metodene de trengte i sine fagsystemer. Begge leverandørene har en uttalt policy at de ikke skal utvikle egen arkivfunksjonalitet, men at de vil utnytte standardarkivet.

12

Fagsystem fra Norconsult Informasjonssystemer som benytter GeoIntegrasjonoppdatering for å arkivere.

Det er få fagsystemer som benytter GeoIntegrasjon i dag siden det har drøyet med støttet i arkivsystemene. Norconsult er blant de selskapene som har basert seg på standardene i GeoIntegrasjonsfamilien. Norkart benytter fortsatt hovedsakelig Noark 4 Web Services i sine løsninger.

13

Bør jeg velge et standardsnitt eller gå for skreddersøm?

14

Fordeler:Samme grensesnitt uavhengig av sak/arkivsystem (eller uavhengig arkivkjerne)Løsningen kan utvikles og testes ett sted og så driftssettes mange stederEnkelt å bruke, enkelt å komme i gang

Ulempe:Minste felles multiplumIngen støtte for møter, utvalgsmedlemmer

Anbefaling:Løsninger som skal leveres til mangeLøsninger med enkle (standard) behov (arkivet kun som arkiv)

15

Fordel:Utnytte alle mulighetene i det systemet man har

Ulempe:Må tilpasses for hver kunde / hvert systemLite «gratishjelp» av forenklede grensesnitt med standardverdier

Anbefales når det skal lages løsning for én kunde og det er behov for mer enn ren arkivering.Må brukes for løsninger standardene ikke støtterEksempler: Politikerportal og «mine oppgaver»

Noark 5 kjerne med grensesnitt blir en hybrid, samme løsning kan brukes flere steder, men man må ha god arkivkunnskap.

16

Info om møter, utvalgsmedlemmer, utvalgssaker etc. finnes kun som proprietært grensesnitt

Standardene dekker kun arkivering og gjenfinning, samt innsyn i saksprosessen

Grensesnitt mot «SRU» er absolutt en kandidat for standardisering, men det finnes ingen konkrete forslag om dette.

17

Her tilskuddssak i ephorte, en sakstype som ikke Noark standardiserer og som det da heller ikke finnes standard grensesnitt for.

Generelt må man bruke de proprietære grensesnittene hvis man skal arbeide med fagdata i saksbehandlingssystemet. Unntaket er en del informasjon innen byggesak, delingssak (matrikkelen) og plansak der GeoIntegrasjon har standardisert en rekke opplysninger.

18

Hva er utfordringene når det skal lages integrasjoner?

19

Mange tror at integrasjoner er vanskelig teknisk. Vår erfaring er at denne delen stort sett går glatt.

Utfordringen er derimot at de som skal lage integrasjoner ikke har arkivfaglig forståelse. Derfor går det galt.

Noark er komplisertArkivet har sitt stammespråk, de som skal integrere seg et helt annetBruk konsulenter som også kan arkiv

20

Hvilket ansvar skal fagsystemet ha? Hvilket ansvar skal arkivet ha? Noark 4 Web Services og GeoIntegrasjon arkiv gir begge muligheter til å legge det meste av ansvaret over på arkivet. Forslaget til Noark 5 kjerne legger mye av ansvaret på fagsystemet.

Utfordringene er bl.a.:Saker skal klassifiseresSaker skal avsluttesJournalposter skal avskrivesDokumenter skal ferdigstillesArkivformat (PDF/A)?

Har man ikke gjort forarbeidet godt nok er resultatet at‐ fagsystemet setter ikke obligatoriske felt‐ koder gis feil verdi‐ sensitive opplysninger blir ikke skjermet‐m.m.

21

Noen gode råd om en fremdrift som sørger for at man kommer i mål til rett tid og med rett resultat.

22

I stedet for å starte med det tekniske, start med hva dere ønsker å oppnå.

Hvis de samme sakene, journalpostene og dokumentene skulle legges i arkivet, hvordan ville du ha arkivert dem?Arkivdel, ansvarlig, koder, skjerming, …

Skal dokumenter og journalposter under arbeid ligge i arkivet, eller skal arkiveringen skje når de er ferdige?Men ikke vent til sakene er ferdige – husk offentlig journal!

Skal sakene saksbehandles kun i fagsystemet eller også i sak/arkivsystemet?Hvem (om noen) skal ha innsyn via sak/arkivsystemet?

23

Når fagkonsulenten og arkivet er ferdig med sin jobb er tiden kommet til å se på hvordan det skal løses teknisk.

Kan fagsystemet og arkivet snakke sammen?Er det behov for skreddersøm eller går det greit med standard grensesnitt?Hvilke kall skal gjøres og i hvilken rekkefølge?Skal fagsystemet hente ut igjen data? Hvordan?

24

Om en utvikler fra EVRY trengs avhenger av konklusjonen til arkitekten. Hvis det benyttes standard grensesnitt vil fagsystemleverandøren ofte kunne gjøre jobben selv med støtte fra EVRY. Husk å avtale med EVRY, det lønner seg.

EVRY har en egen konsulentavdeling med god kompetanse på integrasjoner. I en del tilfeller kan derfor samme konsulent gjøre både fagkonsulent‐, arkitekt‐ og utviklingsjobben.

25

Den delen som alle tror er vanskeligst…

Så lenge installasjonsdokumentasjonen er oppdatert slik at installatøren vet adresser, påloggingsinformasjon etc. går denne delen greit. Noen ganger må det installeres noe programvare, ofte er det nok å konfigurere. Og er det «skjemaintegrasjoner» gjør normalt fagkonsulenten alt.

Er det benyttet standard grensesnitt og samme integrasjon har vært utført et annet sted, holder det med fagkonsulent (det er normalt litt konfigurering i arkivet) og installatør (konfigurere det tekniske).

26

Vi har kostnader både med spesifikasjonsarbeid, utvikling, vedlikehold og dialoger (selv om ikke vi utfører konsulenttjenester er vi «alltid» involvert og til alle døgnets timer).

Det er derfor lisens på bruk av tjenestesnittet.

27

Og så er det «tur og kjør»…

28

Vi har vært gjennom …

29

Det finnes enveis (XML) og toveis integrasjoner

Det finnes en rekke standarder for integrasjon. De viktigste er KS Resultat XML, Noark 4 Web Service og GeoIntegrasjon

Skal løsningene leveres til mange med forskjellige arkivsystemer, eller hvis det er enkel arkivering, anbefales standard grensesnitt.Skal mulighetene som ligger i ESA eller ephorte utnyttes, bruker man proprietært grensesnitt. Det gjelder bl.a. for alt rundt styrer/råd/utvalg.

Utfordringene er sjelden tekniske, heller arkivfaglig forståelse. Men det trengs kompetanse.

Ta kontakt, dette har vi gjort mange ganger før! Og du kontakter oss på …

30

Lykke til med integrasjonene!

31