Integrasjoner esa og ephorte
Upcoming SlideShare
Loading in...5
×
 

Integrasjoner esa og ephorte

on

  • 333 views

Presentasjon på EVRY Sak- og Portaldagene 2014-04-03 ang. integrasjoner mot ESA og ephorte med disse som arkivkjerne

Presentasjon på EVRY Sak- og Portaldagene 2014-04-03 ang. integrasjoner mot ESA og ephorte med disse som arkivkjerne

Statistics

Views

Total Views
333
Views on SlideShare
332
Embed Views
1

Actions

Likes
0
Downloads
7
Comments
0

1 Embed 1

http://www.slideee.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Integrasjoner esa og ephorte Integrasjoner esa og ephorte Document Transcript

  • 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 ephorte har 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 sak Ny journalpost (inkl. dokumenter) Hent sak Hent 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 Geolok 2.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 Norconsult Informasjonssystemer 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 GeoIntegrasjon oppdatering 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 steder Enkelt å bruke, enkelt å komme i gang Ulempe: Minste felles multiplum Ingen støtte for møter, utvalgsmedlemmer Anbefaling: Løsninger som skal leveres til mange Lø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 system Lite «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øtter Eksempler: 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 komplisert Arkivet har sitt stammespråk, de som skal integrere seg et helt annet Bruk 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 klassifiseres Saker skal avsluttes Journalposter skal avskrives Dokumenter skal ferdigstilles Arkivformat (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