Home
Fiks Arkiv er en modernisering av GI Arkiv 1.1 og det nye grensesnittet som anbefales brukt når kommunen skal sette opp kommunikasjonen mellom et fagsystem og en arkivløsning.
Fiks Arkiv støtter meldinger for både arkivering og spørring mot arkivet. Grensesnittet er sentralt i forhold til å støtte opp under kravene i den nasjonale produktspesifikasjonen for plan- og byggesak. Grensesnittet tilrettelegger for at andre leverandører enn de tradisjonelle sak/arkivleverandørene kan tilby denne type fagsystem.
Grensesnittet støtter en rekke ulike behov som saksbehandler i et fagsystem vil ha, ikke bare fagsystem som eByggeSak og ePlanSak, men også andre fagsystem/klientløsninger på andre fagområder som har behov for å hente ut eller legge informasjon i kommunens arkiv.
Datamodellen for Fiks Arkiv baserer seg på Noark 5, men er en egen standard. Noark 5 er dokumentert her: Noark 5-standarden
Skjema og andre definisjoner for denne protokollen ligger i github prosjektet fiks-arkiv-specification som denne Wikien også henger sammen med.
KS leverer også bibliotek for Java og .NET som inneholder skjemaene, meldingstyper.json filen, hjelpeklasser og genererte modeller fra skjema.
Maven Central: https://central.sonatype.com/artifact/no.ks.fiks/fiks-arkiv
Nuget.org: https://www.nuget.org/packages/KS.Fiks.Arkiv.Models.V1
Her er detaljert dokumentasjon for protokollen
For mer dokumentasjon om Fiks Arkiv i sammenheng med Fiks-Protokoll og mer implementasjonsdetaljer anbefaler vi også å se på sidene for Fiks Arkiv protokollen og Fiks-Protokoll på developers.fiks.ks.no. Der finner man også flere lenker til Github prosjekter som kan være relevante.
Hos arkivverket finner man også nyttige ressurser som dokumenterer f.eks. Noark standarden og forklaring på ord og begreper.
Datamodellen er som nevnt tidligere basert på Noark 5-standarden, med tilpasninger.
Her følger en kort forklaring på noen av hovedobjektene. For mer utdypende informasjon, se gjerne dokumentet "Noark 5 v. 5.0 Standard for elektronisk arkiv" i pdf eller word format.
Mappe er det overordnede objektet for å samle saker i. Det er mulig å ha mapper i mapper.
Saksmappe er en spesialisering av mappe og er den som brukes i saksarkiver. Ved blanding av mapper og saksmapper må saksmappe være nederste nivå. Oftest vil det kun være saksmappe.
Registrering er det overordnede objektet for å samle et sett med dokumenter som hører sammen, eller for å angi en hendelse.
Journalpost er en spesialisering av registrering og brukes for hendelser som skal inn i journalen, en oversikt over all korrespondanse til og fra organisasjonen, samt interne notater og rapporter. Oftest vil det kun være journalposter registrert i saksmapper.
Dokumentbeskrivelse inneholder info om hoveddokument og vedlegg knyttet til registreringen/journalposten.
Dokumentobjekt inneholder info om "filer". En dokumentbeskrivelse kan ha mange dokumentobjekt: Utkast arkivert og versjonert, formatvarianter som formater for tekstbehandling og visning, sladdet versjon m.m.
Noarks datamodell er hierarkisk med fire nivåer over mappe. Disse inngår dels som referanser fra mappe/saksmappe i Fiks Arkiv:
Arkiv er øverste nivå og samler alt som en organisasjon arkiverer.
Arkivdel er en del av arkivet som er ordnet på samme måte (f.eks. etter gårds- og bruksnummer, eller etter en arkivkode). Det kan også lages arkivdeler for en tidsperiode. Det er vanlig at det emne-/funksjonsordnede arkivet har ny arkivdel for hver kommunestyreperiode i kommunene eller hvert 5. år for andre. Arkivdel er referert fra (saks-)mappen for å angi hvilken arkivdel denne ligger i.
Klassifikasjonssystem angir hvordan sakene i en arkivdel er ordnet, f.eks. om det er et objektarkiv/seriearkiv med gårds- og bruksnummer, lønnsnummer, klientnummer e.a., eller om det er et emnearkiv/funksjonsordnet arkiv etter en fast arkivnøkkel.
Klasse er selve arkivkoden som i et eiendomsarkiv normalt er gårdsnummer/bruksnummer, evt. kommunenummer-gårdsnummer/bruksnummer. I et emne-/funksjonsordnet arkiv kan det være en kode som A40, 001 eller 2.5.13. En saksmappe vil normalt ha en primær klasse som inngår i hierarkiet, men kan også ha sekundære klasser. I GeoIntegrasjon brukes objektet klasse knyttet til (saks-)mappe som inneholder informasjon om både klassifikasjonssystemet og klassen. Mappen kan ha flere klasser. Den første er da den primære og er den som styrer ordningen inn i arkivdelen, men de øvrige er tilleggsinformasjon.
Fiks Arkiv baserer seg på asynkron meldingsutveksling via Fiks Protokoll plattformen. Dette vil si at avsender ikke kan forvente at det vil utføres en handling på bakgrunn av sendt melding med det samme, men at handlingen vil skje en gang i fremtiden.
Fiks Protokoll plattformen er et sett med tjenester, hvor Fiks IO er tjenesten som sørger for den asynkrone maskin-til-maskin meldingsutvekslingen. I tillegg til meldingsutveksling via Fiks IO sørger Fiks Protokoll for validering av meldingstyper innenfor protokollen, godkjenning av avsender-system osv. Se mer om dette lenger nede eller les dokumentasjonen for Fiks Protkoll her.
Asynkron meldingsutveksling medfører at avsender må håndtere at sendte meldinger ikke nødvendigvis blir utført med en gang, men at man får svar på meldingen på et senere tidspunkt. Det vil være 4 mulige utfall av en melding:
- Svar som bekrefter at handlingen meldingen skulle utføre var vellykket
- Svar som inneholder en feilmelding
- Meldingens levetid utløper (TTL). Avsender må avgjøre om dette håndteres med re-sending eller på annen måte
- Du får svar som sier at meldingen er mottatt, men mangler bekreftelse på at handlingen ble utført. Gitt at mottaker har bekreftet å mottatt meldingen er ansvaret for handling nå overført til mottaker.
Fiks Arkiv vil ha meldinger både for arkivering og spørring mot arkivet. For avsendersystem som ikke har behov for å sende all informasjon en komplett arkivmelding inneholder vil det utvikles forenklede klienter som fyller ut nødvendige felter for å skape en gyldig arkivmelding.
Her vises prinsippet for meldingsutveksling mellom fagsystem og arkiv. Merk at tegningen er forenklet mtp sending og mottak av meldinger, da sending av melding vil gå via et Fiks IO http api, mens mottak av meldinger gjøres via AMQP på en kø.
Fiks Arkiv bruker en meldingstjeneste som Fiks Protokoll (sammen med Fiks IO) til å sende meldinger asynkront mellom to systemer.
Siden hver bruker av Fiks Protokoll kopler opp til Fiks Protokoll som står sentralt, vil det kun være nødvendig med åpning mot Fiks Protokoll for alle som bruker Fiks Arkiv.
Hvert system må autentisere seg for å få tilgang til en konto i Fiks Protokoll. Dette gjelder både for å sende meldinger via API og subscribe på meldinger i sin kø. Autentisering foregår med maskinporten og Fiks autentisering. se developers.fiks.ks.no for mer detaljer.
Hver konto kan velge hvilke andre kontoer den vil motta meldinger fra, eller sende en forespørsel fra forvaltningssidene om å få lov til å sende meldinger til en annen konto. Mottakende konto av forespørsel kan da velge å godkjenne eller avvise forespørsel. Hvis man ikke trenger godkjenning av avsendere kan man velge å ha en "åpen" konto som alle får lov å sende til. Fiks Protokoll vil også bare godta meldingstyper innenfor protokollen kontoen er satt opp med. F.eks. vil en Fiks Arkiv protokoll konto bare kunne motta meldinger innenfor denne protokollen. Unntaket er standard feilmeldingstyper fra Fiks Protokoll (Fiks IO).
Fiks Arkiv vil ha asynkrone meldinger, dette betyr at meldingene kan komme fram en tilfeldig tid i fremtiden. En bør sette fornuftige Time to live verdier på meldinger. Hvis en søker etter data vil kanskje 10-30s være en fornuftig timeout, mens arkivering av f.eks en journalpost kan ta 3 dager. Hvis en setter Time to live høyt kan systemer gå ned og komme opp igjen før den utfører oppgaven. Fiks Protokoll garanterer heller ikke at meldingen kommer fram eller at de kommer fram i den rekkefølgen de ble sendt, så klienten må da ha en egen sjekk på om det er kommet svar og eventuelt prøve på nytt hvis det er fornuftig.
Protokollen Fiks Arkiv har et gitt antall meldingstyper som støttes.
Alle meldinger som har en xml-payload som er standardisert innenfor protokollen har et tilhørende skjema med eventuelle fellesskjema som inneholder felles datatyper.
Les mer om meldingstypene her.
Skjema som tilhører en meldingstype sin payload har tilsvarende navn som meldingstypen.
F.eks. har meldingstypen no.ks.fiks.arkiv.v1.arkivering.arkivmelding.opprett et tilhørende skjema med navn no.ks.fiks.arkiv.v1.arkivering.arkivmelding.opprett.xsd som inkluderer skjemaet metadatakatalog.xsd med felles datatyper.
Oversikt over skjema og hvilke felles skjema som er inkludert hvor:
For å se hele bildet i full størrelse gå direkte her til SVG-filen for alle skjema