Forum Sak fra SIP til DIP
15 April 2010 11:50
Sigve Espeland, IKA Rogaland.
Bevaringsprosjektet rettet mot det gamle og avsluttede sak/arkivsystemet Forum Sak som Sola kommune brukte i perioden 1993 – 2000 var en krevende sak. Det er prosessene omkring dette bevaringsarbeidet vi skal fortelle om her.
Forum Sak i Sola kommune
Forum Sak var Sola kommune sitt første saksbehandlingssystem, eller sak/arkivsystem som vi kaller det i dag. Systemet ble levert av et selskap som den gang i 1993 het Alliance Informasjonssystemer AS. Systemet ble brukt til saksbehandling, arkiv og utvalgsbehandling i kommunen fra mars 1993 og fram til mai 2000 da kommunen tok i bruk det KOARK/NOARK-3 baserte sak/arkivsystemet Kontor2000. Forum Sak var et relativt utbredt sak/arkivsystem i kommunal sektor før NOARK-3/KOARK-baserte systemer slo igjennom.
Da Sola kommune tok i bruk Kontor2000 valgte de å la være å konvertere dataene fra Forum Sak inn i Kontor2000 som en historisk database for oppslag der. De valgte å beholde Forum Sak i sin opprinnelige form i sitt opprinnelige miljø. I nesten 10 år etter dette surret og gikk derfor den gamle serveren og ble stadig eldre, og ble kun brukt til oppslag av sentralarkivet.
Mislykkede forsøk på bevaring – får vi lov til å slette det?
De siste årene har det vært en økende fokusering på bevaring av eArkiv. Interkommunalt Arkiv i Rogaland (IKAR) har på lik linje med sine søsterorganisasjoner rundt om i landet fokusert på denne utfordringen overfor kommunene. Arkivleder i Sola kommune til 2009, Astrid Askø, var klar over denne utviklingen og forsto at kommunen i samarbeid med IKAR måtte få til en bevaring av Forum Sak før den gamle serveren brøt sammen. Vi forsøkte derfor å finne mest mulig ut om Forum Sak og den Informix-platt formen som systemet lå på i Sola kommune. I denne pro sessen forsøkte vi også å gjøre et uttrekk med verktøyet Pervasive Dataintegrator Pro, noe som vi ikke lyktes med fordi vi ikke klarte å koble uttrekksverktøyet opp mot den gamle Informix-databasen.
Da bevaringsverktøyet DEX ble markedsført av Sysco AS i 2008 kom Sola kommune og IKAR i en dialog med Sysco som endte med at vi fikk lov å teste DEX på Forum Sak før Sola kommune kjøpte en eventuell lisens. Også dette forsøket på å produsere et bevaringsuttrekk av Forum Sak mislykkes i første omgang, og grunnen var følgende: I proprietær form ble Forum Sak kjørt på en Informix 4-plattform i Sola kommune, og kommunen hadde ikke brydd seg med å oppgradere Informix-miljøet sitt etter at de tok i bruk Kontor2000. Vi fant relativt raskt ut at DEX manglet en JDBCdriver som fungerte opp mot Informix 4-teknologi. Vi fant også ut at slike JDBC-drivere ikke eksisterer for så gammel Informix-teknologi. I tillegg fant IKT-avdelingen i Sola kommune ut at hvis de skulle bevare systemet og produsere uttrekk fra det, måtte de oppgradere databaseplattformen sju ganger fra Informix 4 til Informix 11. Dette ville bli svært kostnadskrevende, og vi hadde ingen garanti for at dataene ville overleve en så omfattende oppgradering. IKAR informerte samtidig om at systemet må bevares selv om kommunen har et godt papirarkiv for denne perioden skapt i interaksjon med Forum Sak. Dette er en naturlig konsekvens av § 3-20e i arkivforskrifta. De fikk samtidig vite at hvis de ville forsøke å slette systemet måtte de søke Riksarkivaren om dette. IKAR informerte samtidig om at de trolig ville få avslag på en slik søknad, men at de godt kunne forsøke. De søkte Riksarkivaren om å få lov til å slette systemet med begrunnelse om at det ville bli for dyrt å bevare systemet, og at kommunen har et godt papirarkiv for denne perioden. Sola kommune fikk avslag på søknaden.
En litt uformell samtale - et alternativt løp tar form
Ganske tidlig i den prosessen som er skissert ovenfor hadde rådgiver fra IKAR og driftpersonale i IKT-avdelingen i Sola kommune en uformell samtale over en kaffekopp hvor vi diskuterte hva vi kunne gjøre hvis alle forsøk på å produsere avleveringsuttrekk til kommunalt arkivdepot fra originaldatabasen strandet, og kommunen fikk avslag på søknaden sin til Riksarkivet. IKAR informerte i denne sammenheng om at hvis kommunen klarte å produsere et dump av data fra Informix 4-basen som flate filer og deretter importere disse inn i for eksempel en MySQL-database sammen med koblinger til tilhørende fulltekstdokument, så kunne vi deretter kjøre avleveringsuttrek ket til arkivdepot fra denne teknologien. Dette var en alternativ løsning, den er ikke helt optimal ut fra et provenienssyns punkt, men en løsning som IKAR kan produsere et arkivuttrekk fra for Sola kommune. Da Sola kommune fikk avslag på søknaden sin fra Riksarkivet ble denne siste løsningen valgt.
Fra Informix via datalab til SIP – et OAIS-løp starter
Migreringen av databasen fra de flate filene som ble dumpet ut av Informix og over til MySQL ble gjort av en ekstern konsulent, Roy Olsen i ErgoGroup Vest AS, ved hjelp av en datalab. ErgoGroup leverte deretter MySQL-kopien av Forum Sak direkte til IKAR. Nå kunne vi ved IKAR starte arbeidet med å produsere et avleveringsuttrekk for Sola kommune, en såkalt SIP.
Sola kommune er en av IKAR sine 23 eierkommuner i Rogaland. I tillegg til at IKAR er Sola kommune sin faginstans på arkiv, ivaretar IKAR også arkivdepotfunksjonen for kommunen med hjemmel i arkivforskriften §5-1 for eldre og avslutta arkiv både på papir og på digitale formater. I IKAR sitt arbeid med å bevare eldre og avsluttet digitalt arkivmateriale står følgende dokument sentralt: «Metodebeskrivelse for håndtering av
digitalt arkivmateriale i kommunal sektor». Denne metodebeskrivelsen ble ferdigstilt i en rapport av det såkalte «eArkivsamarbeidet i kommunal sektor» i 2007. I dette prosjektet var blant annet IKAR representert. Sentralt i denne metodebeskrivelsen står den såkalte OAIS-modellen (ISO 14721: 2002 Reference Model for an Open Archival Information System). Dette er en ISO-standard, en arbeidsmodell, for bevaring av eArkiv. Sentralt i OAIS-modellen står forkortelsene SIP (Software Information Package), AIP (Archival Information Package) og DIP (Data Information Package) hvor en SIP er det datauttrekket en arkivskaper avleverer til en arkivdepotinstitusjon, en AIP er den gjennomgåtte og godkjente versjonen av avleveringen som arkivdepotinstitusjonen vedlikeholder over tid. En DIP er tilrettelagte kopier av data basert på en AIP i forbindelse med en innsynforespørsel rettet til en arkivdepotinstitusjon, altså arkivformidling.
Før vi ved IKAR startet produksjon av en SIP på bakgrunn av den MySQL-kopien av Forum Sak som vi hadde fått, foretok vi en del testing av MySQL-databasen i følgende program XAMPP, DEX og Pervasive Dataintegrator Pro. Vi fant feil i 6 av 62 tabeller hvorav feilene i 5 av tabellene var relativt enkle å rette opp. Disse 5 feiltypene var knyttet til datoformat i en del felt i disse tabellene, det vil si tabellene inneholdt datofelt som var fylt ut med 00.00.000 i stedet for NULL slik MySQL krever for tomme felt. Dette ble rettet opp med relativt enkle UPDATE-kommandoer i SQL.
Når det gjaldt tilhørende fulltekstdokument var problemet større. Etter mye prøving og feiling fant vi ut at i tilknytning til de ca. 47.000 fulltekstdokumentene som inngikk i Forum Sak i Sola kommune knyttet det seg et sammensatt problem som måtte løses for at vi skulle klare å produsere et bevaringsuttrekk hvor vi også fikk bevart fulltekstdokumentene. Disse dokumentene var opprinnelig produsert i tekstbehandleren Word Perfect 5.0 og skulle ha hatt et filnavn/filnummer og fil-ekstensjonen WPD (*.wpd), både i databasen og i den fysiske mappen hvor fulltekstdokumentene lå, for at DEX skulle kunne gjen kjenne dem og konvertere dem til PDF/A. Slik var det ikke. Både i databasen og i mappen hvor dokumentene lå hadde dokumentene et navn/filnummer og en ekstensjon A (*.A).
I tillegg fant vi ut at koblingen mellom database og fulltekst dokument var sammensatt og lå i tre felt i en tabell
som heter spi_poin. Koblingen lå skjult i to av disse feltene og var vanskelig å finne, mens i et av feltene var koblingen intuitiv, logisk og lett å finne. Disse utfordringen betydde at vi måtte gjøre følgende:
• Vi måtte endre ekstensjon på ca. 47.000 fulltekst dokumenter fra *.a til *.wpd. Dette ble gjort ved hjelp av en smart og enkel rename-kommando i DOS.
• For å oppdatere tabellen spi_poin hvor koblingene mot fulltekstdokumentene lå måtte vi igjen i dialog med ErgoGroup og Roy Olsen. Han skrev så to relativt sammensatte SQL-kommandoer som oppdaterte tabellen spi_poin slik at DEX med tilhørende PDFkonverter (Open Office) kunne finne, gjenkjenne og konvertert fulltekst dokumentene til PDF/A og samtidig koble de konverterte fulltekstdokumentene opp mot tilhørende XML-file i databaseuttrekket.
Det tok ca. en uke med prøving, feiling og søking for å avdekke og løse disse problemene.
SIP hos IKAR
Nå kunne vi endelig starte produksjonen av en SIP fra Forum Sak, da kom neste lærdom, og den er litt komisk. Et eArkiv i form av en database med tilhørende fulltekstdokument som har vært brukt til saksbehandling i en kommune over flere år er ofte relativt stor, og den blir bort i mot fire ganger så stor når man bruker DEX til å produsere en SIP. Noen tabeller kan være svært store og det tar tid å få en kopi ut av databasen til XML-format, men det er spesielt konverteringen av tilhørende fulltekstdokument som tar tid. Det er derfor ikke lurt å starte et slikt uttrekk kl. 14.45 en fredag ettermiddag slik vi gjorde. Du ødelegger lett litt av helga da. I andre sammenhenger har vi ved IKA Rogaland også erfart at det er lurt å starte et uttrekk tidlig om morgenen, da har du en mulighet for å bli ferdig før arbeidsdagens slutt. Men i tilfellet Forum Sak for Sola kommune, som var et vanskelig kasus, var det vanskelig å la vær å starte uttrekket når vi skimtet suksess like om hjørnet. I forbindelse med produksjon av en SIP er det verd å merke seg at et uttrekk fra et stort system fort kan gå i over 12 timer. Dette har vi for eksempel erfart i forbindelse med at vi gjorde et uttrekk fra fagsystemet Profil i Karmøy kommune. I tilfeller som dette er det viktig at det også planlegges i forhold til nattlige operasjoner som kjøres på den serveren uttrekket gjøres fra. Men vi lykkes altså med uttrekket fra Forum Sak til Sola kommune selv om vi ødela den første kvelden av ei helg. I fila INFO.TXT logget DEX følgende tekniske data om uttrekket:
Overordnet informasjon om arkivskaper og arkivversjonArkivId: 1124_2
ArkivNavn: Sola kommune
SystemId: 1124_2
Systemnavn: Forum Sak
Startdato for utrekk (yyyy.mm.dd): 1993.03.03
Sluttdato for utrekk:(yyyy.mm.dd): 2000.05.05
Utført av: SIES
Utført dato/klokkeslett: 2009.10.02 02:45:37
Ferdig dato/klokkeslett: 2009.10.02 06:13:51
Tidsforbruk: 3 timer 28 min. 14 sek.
Antall tabeller lest: 62
Antall rader lest: 219549
Antall eksterne dokumenter: 47186
Antall lese/konverteringsfeil: 4
Produksjon av AIP - godkjenningDa SIP-en var i boks startet en prosess som er en av primær oppgavene til en arkivdepotinstitusjon i forbindelse med bevaring av eldre og avsluttet eArkiv. Nemlig det å gjøre en SIP om til en AIP, «Archival Information Package», det er i form av slike pakker at et eldre og avsluttet eArkiv langtidsoppbevares og vedlikeholdes i en offentlig arkivinstitusjon. Ved IKAR vil dette på det nåværende tidspunkt i den faglige og tekniske utviklingen knyttet til eArkiv si:
• Å gå igjennom avleveringen og sjekke at den tilfreds stiller de (juridiske) kravene som stilles til en avlevering. Mye av denne befaringen gjør vi ved IKAR i dag ved hjelp av programmet Altova XMLSpy. Samtidig har vi også laget en sjekkliste som vi bruker i dette arbeidet. Denne sjekklisten danner et viktig grunnlag for det godkjen nings brevet som sendes arkiveier/kommunen etter fullført gjennomgang og testing.
• Vi sjekker at påkrevd systemdokumentasjon følger avlever ingen/deponeringen hvis slik er tatt vare på i kommunen eller i det hele tatt eksisterer. Hvis arkivskaper ikke har systemdokumentasjon forsøker IKAR å skaffe slik via sitt faglige nettverk ved andre kommunale arkivinstitusjoner (KAI).
• Vi lager også fila INNHOLD.TXT hvis denne ikke følger av leveringen. (DEX lager ikke denne filen.)
• Vi foretar også en del testing av XML-filene som inne holder tabelldata. Blant annet importerer vi XML-filer fra databaseuttrekket til en database på en proprietær databaseplattform. Ved IKA Rogaland gjør vi i dag mye slik importering mot MySQL.
Etter en gjennomgang og testing som skissert i punktene ovenfor sendte vi godkjenningsbrev til Sola kommune den 13. november 2009 (IKAR sak/arkivreferanse: 09/164 – 18).
Sola kommune ønsker en DIP
Etter at Sola kommune hadde mottatt godkjenningsbrevet ble det fra arkivtjenesten i kommunen ytret ønsket om å få tilbake fra IKAR en kopi av dataene som ble reddet ut fra Informixmiljøet for oppslag i ennå noen år. Arkivleder i kommunen oppfattet tross alt ikke Forum Sak som et særlig gammelt system. Dette åpnet en mulighet for for midling for IKAR. Vi kunne lage en DIP for Sola kommune som arkivtjenesten kunne bruke på en lokal pc eller sette opp på kommunens intranett for oppslag. IKAR foreslo for Sola kommune å sette dette opp på kommunens forslag til arbeidsplan for IKAR for 2010. Som sagt så gjort. I februar 2010 laget IKAR en DIP (Data Information Package) for Sola kommune hvor vi gjorde følgende:
• Reimporterte de 4 XML-filene inn i en MySQL database ved hjelp av Altova XMLSpy og kontrollerte feltformatene i henhold til filen METADATA.XML i avleveringen.
• Deretter brukte vi programmet PHP-Runner til å designe oppslagsdatabasen bestående av nevnte MySQL-database og PHP-filer som kan kjøre i alle nettlesere vi kjenner til.
• Denne oppslagsdatabasen ble presentert for arkivtjenesten og IKT-avdelingen i Sola kommune den 2. mars 2010. De likte det de så og vil sette denne DIP-en opp på en virtuell server på kommunen sitt intranett i løpet av våren 2010.
Slik endte historien om Forum Sak i Sola kommune.
Hva har vi lært?
Når elektronisk arkivmateriale som skal bevares ligger på en gammel proprietær teknologisk plattform som tiden er i ferd med å løpe fra, kan utfordringene for å få til en vellykket bevaring være krevende både arkivfaglig, teknologisk og økonomisk. Ofte må ekstern kompetanse hentes inn for å lykkes. Man må i tillegg være tålmodig og bruke nødvendig tid for å lykkes. Som dette eksemplet viser så lar selv vanskelige utfordringer seg løse. Eksempelet med Forum Sak i Sola kommune viser også hvor viktig det er å få til en tidlig avlevering/deponering av et eldre og avsluttet elektronisk arkiv. Venter vi for lenge vokser problemet fordi den proprietære teknologien vokser fra en forlatt server med et eldre og avsluttet eArkiv på. Derfor heter det følgende i «Forskrift om offentlege arkiv» § 3-17: «Ein elektronisk kopi av basen for ein avslutta periode skal klargjerast for deponering i arkivdepot. [...]. Deponering skal skje straks, jf. elles føresegnene for avlevering frå statlege organ til Arkivverket, kap. V. Kommunar og fylkeskommunar skal følgje den same prosedyren eller eit anna opplegg som på fullgod måte ivaretek omsynet til langtidslagring og framtidig dokumentasjon.»
Bevaringsprosjektet rettet mot det gamle og avsluttede sak/arkivsystemet Forum Sak som Sola kommune brukte i perioden 1993 – 2000 var en krevende sak. Det er prosessene omkring dette bevaringsarbeidet vi skal fortelle om her.
Forum Sak i Sola kommune
Forum Sak var Sola kommune sitt første saksbehandlingssystem, eller sak/arkivsystem som vi kaller det i dag. Systemet ble levert av et selskap som den gang i 1993 het Alliance Informasjonssystemer AS. Systemet ble brukt til saksbehandling, arkiv og utvalgsbehandling i kommunen fra mars 1993 og fram til mai 2000 da kommunen tok i bruk det KOARK/NOARK-3 baserte sak/arkivsystemet Kontor2000. Forum Sak var et relativt utbredt sak/arkivsystem i kommunal sektor før NOARK-3/KOARK-baserte systemer slo igjennom.
Da Sola kommune tok i bruk Kontor2000 valgte de å la være å konvertere dataene fra Forum Sak inn i Kontor2000 som en historisk database for oppslag der. De valgte å beholde Forum Sak i sin opprinnelige form i sitt opprinnelige miljø. I nesten 10 år etter dette surret og gikk derfor den gamle serveren og ble stadig eldre, og ble kun brukt til oppslag av sentralarkivet.
Mislykkede forsøk på bevaring – får vi lov til å slette det?
De siste årene har det vært en økende fokusering på bevaring av eArkiv. Interkommunalt Arkiv i Rogaland (IKAR) har på lik linje med sine søsterorganisasjoner rundt om i landet fokusert på denne utfordringen overfor kommunene. Arkivleder i Sola kommune til 2009, Astrid Askø, var klar over denne utviklingen og forsto at kommunen i samarbeid med IKAR måtte få til en bevaring av Forum Sak før den gamle serveren brøt sammen. Vi forsøkte derfor å finne mest mulig ut om Forum Sak og den Informix-platt formen som systemet lå på i Sola kommune. I denne pro sessen forsøkte vi også å gjøre et uttrekk med verktøyet Pervasive Dataintegrator Pro, noe som vi ikke lyktes med fordi vi ikke klarte å koble uttrekksverktøyet opp mot den gamle Informix-databasen.
Da bevaringsverktøyet DEX ble markedsført av Sysco AS i 2008 kom Sola kommune og IKAR i en dialog med Sysco som endte med at vi fikk lov å teste DEX på Forum Sak før Sola kommune kjøpte en eventuell lisens. Også dette forsøket på å produsere et bevaringsuttrekk av Forum Sak mislykkes i første omgang, og grunnen var følgende: I proprietær form ble Forum Sak kjørt på en Informix 4-plattform i Sola kommune, og kommunen hadde ikke brydd seg med å oppgradere Informix-miljøet sitt etter at de tok i bruk Kontor2000. Vi fant relativt raskt ut at DEX manglet en JDBCdriver som fungerte opp mot Informix 4-teknologi. Vi fant også ut at slike JDBC-drivere ikke eksisterer for så gammel Informix-teknologi. I tillegg fant IKT-avdelingen i Sola kommune ut at hvis de skulle bevare systemet og produsere uttrekk fra det, måtte de oppgradere databaseplattformen sju ganger fra Informix 4 til Informix 11. Dette ville bli svært kostnadskrevende, og vi hadde ingen garanti for at dataene ville overleve en så omfattende oppgradering. IKAR informerte samtidig om at systemet må bevares selv om kommunen har et godt papirarkiv for denne perioden skapt i interaksjon med Forum Sak. Dette er en naturlig konsekvens av § 3-20e i arkivforskrifta. De fikk samtidig vite at hvis de ville forsøke å slette systemet måtte de søke Riksarkivaren om dette. IKAR informerte samtidig om at de trolig ville få avslag på en slik søknad, men at de godt kunne forsøke. De søkte Riksarkivaren om å få lov til å slette systemet med begrunnelse om at det ville bli for dyrt å bevare systemet, og at kommunen har et godt papirarkiv for denne perioden. Sola kommune fikk avslag på søknaden.
En litt uformell samtale - et alternativt løp tar form
Ganske tidlig i den prosessen som er skissert ovenfor hadde rådgiver fra IKAR og driftpersonale i IKT-avdelingen i Sola kommune en uformell samtale over en kaffekopp hvor vi diskuterte hva vi kunne gjøre hvis alle forsøk på å produsere avleveringsuttrekk til kommunalt arkivdepot fra originaldatabasen strandet, og kommunen fikk avslag på søknaden sin til Riksarkivet. IKAR informerte i denne sammenheng om at hvis kommunen klarte å produsere et dump av data fra Informix 4-basen som flate filer og deretter importere disse inn i for eksempel en MySQL-database sammen med koblinger til tilhørende fulltekstdokument, så kunne vi deretter kjøre avleveringsuttrek ket til arkivdepot fra denne teknologien. Dette var en alternativ løsning, den er ikke helt optimal ut fra et provenienssyns punkt, men en løsning som IKAR kan produsere et arkivuttrekk fra for Sola kommune. Da Sola kommune fikk avslag på søknaden sin fra Riksarkivet ble denne siste løsningen valgt.
Fra Informix via datalab til SIP – et OAIS-løp starter
Migreringen av databasen fra de flate filene som ble dumpet ut av Informix og over til MySQL ble gjort av en ekstern konsulent, Roy Olsen i ErgoGroup Vest AS, ved hjelp av en datalab. ErgoGroup leverte deretter MySQL-kopien av Forum Sak direkte til IKAR. Nå kunne vi ved IKAR starte arbeidet med å produsere et avleveringsuttrekk for Sola kommune, en såkalt SIP.
Sola kommune er en av IKAR sine 23 eierkommuner i Rogaland. I tillegg til at IKAR er Sola kommune sin faginstans på arkiv, ivaretar IKAR også arkivdepotfunksjonen for kommunen med hjemmel i arkivforskriften §5-1 for eldre og avslutta arkiv både på papir og på digitale formater. I IKAR sitt arbeid med å bevare eldre og avsluttet digitalt arkivmateriale står følgende dokument sentralt: «Metodebeskrivelse for håndtering av
digitalt arkivmateriale i kommunal sektor». Denne metodebeskrivelsen ble ferdigstilt i en rapport av det såkalte «eArkivsamarbeidet i kommunal sektor» i 2007. I dette prosjektet var blant annet IKAR representert. Sentralt i denne metodebeskrivelsen står den såkalte OAIS-modellen (ISO 14721: 2002 Reference Model for an Open Archival Information System). Dette er en ISO-standard, en arbeidsmodell, for bevaring av eArkiv. Sentralt i OAIS-modellen står forkortelsene SIP (Software Information Package), AIP (Archival Information Package) og DIP (Data Information Package) hvor en SIP er det datauttrekket en arkivskaper avleverer til en arkivdepotinstitusjon, en AIP er den gjennomgåtte og godkjente versjonen av avleveringen som arkivdepotinstitusjonen vedlikeholder over tid. En DIP er tilrettelagte kopier av data basert på en AIP i forbindelse med en innsynforespørsel rettet til en arkivdepotinstitusjon, altså arkivformidling.
Før vi ved IKAR startet produksjon av en SIP på bakgrunn av den MySQL-kopien av Forum Sak som vi hadde fått, foretok vi en del testing av MySQL-databasen i følgende program XAMPP, DEX og Pervasive Dataintegrator Pro. Vi fant feil i 6 av 62 tabeller hvorav feilene i 5 av tabellene var relativt enkle å rette opp. Disse 5 feiltypene var knyttet til datoformat i en del felt i disse tabellene, det vil si tabellene inneholdt datofelt som var fylt ut med 00.00.000 i stedet for NULL slik MySQL krever for tomme felt. Dette ble rettet opp med relativt enkle UPDATE-kommandoer i SQL.
Når det gjaldt tilhørende fulltekstdokument var problemet større. Etter mye prøving og feiling fant vi ut at i tilknytning til de ca. 47.000 fulltekstdokumentene som inngikk i Forum Sak i Sola kommune knyttet det seg et sammensatt problem som måtte løses for at vi skulle klare å produsere et bevaringsuttrekk hvor vi også fikk bevart fulltekstdokumentene. Disse dokumentene var opprinnelig produsert i tekstbehandleren Word Perfect 5.0 og skulle ha hatt et filnavn/filnummer og fil-ekstensjonen WPD (*.wpd), både i databasen og i den fysiske mappen hvor fulltekstdokumentene lå, for at DEX skulle kunne gjen kjenne dem og konvertere dem til PDF/A. Slik var det ikke. Både i databasen og i mappen hvor dokumentene lå hadde dokumentene et navn/filnummer og en ekstensjon A (*.A).
I tillegg fant vi ut at koblingen mellom database og fulltekst dokument var sammensatt og lå i tre felt i en tabell
som heter spi_poin. Koblingen lå skjult i to av disse feltene og var vanskelig å finne, mens i et av feltene var koblingen intuitiv, logisk og lett å finne. Disse utfordringen betydde at vi måtte gjøre følgende:
• Vi måtte endre ekstensjon på ca. 47.000 fulltekst dokumenter fra *.a til *.wpd. Dette ble gjort ved hjelp av en smart og enkel rename-kommando i DOS.
• For å oppdatere tabellen spi_poin hvor koblingene mot fulltekstdokumentene lå måtte vi igjen i dialog med ErgoGroup og Roy Olsen. Han skrev så to relativt sammensatte SQL-kommandoer som oppdaterte tabellen spi_poin slik at DEX med tilhørende PDFkonverter (Open Office) kunne finne, gjenkjenne og konvertert fulltekst dokumentene til PDF/A og samtidig koble de konverterte fulltekstdokumentene opp mot tilhørende XML-file i databaseuttrekket.
Det tok ca. en uke med prøving, feiling og søking for å avdekke og løse disse problemene.
SIP hos IKAR
Nå kunne vi endelig starte produksjonen av en SIP fra Forum Sak, da kom neste lærdom, og den er litt komisk. Et eArkiv i form av en database med tilhørende fulltekstdokument som har vært brukt til saksbehandling i en kommune over flere år er ofte relativt stor, og den blir bort i mot fire ganger så stor når man bruker DEX til å produsere en SIP. Noen tabeller kan være svært store og det tar tid å få en kopi ut av databasen til XML-format, men det er spesielt konverteringen av tilhørende fulltekstdokument som tar tid. Det er derfor ikke lurt å starte et slikt uttrekk kl. 14.45 en fredag ettermiddag slik vi gjorde. Du ødelegger lett litt av helga da. I andre sammenhenger har vi ved IKA Rogaland også erfart at det er lurt å starte et uttrekk tidlig om morgenen, da har du en mulighet for å bli ferdig før arbeidsdagens slutt. Men i tilfellet Forum Sak for Sola kommune, som var et vanskelig kasus, var det vanskelig å la vær å starte uttrekket når vi skimtet suksess like om hjørnet. I forbindelse med produksjon av en SIP er det verd å merke seg at et uttrekk fra et stort system fort kan gå i over 12 timer. Dette har vi for eksempel erfart i forbindelse med at vi gjorde et uttrekk fra fagsystemet Profil i Karmøy kommune. I tilfeller som dette er det viktig at det også planlegges i forhold til nattlige operasjoner som kjøres på den serveren uttrekket gjøres fra. Men vi lykkes altså med uttrekket fra Forum Sak til Sola kommune selv om vi ødela den første kvelden av ei helg. I fila INFO.TXT logget DEX følgende tekniske data om uttrekket:
Overordnet informasjon om arkivskaper og arkivversjonArkivId: 1124_2
ArkivNavn: Sola kommune
SystemId: 1124_2
Systemnavn: Forum Sak
Startdato for utrekk (yyyy.mm.dd): 1993.03.03
Sluttdato for utrekk:(yyyy.mm.dd): 2000.05.05
Utført av: SIES
Utført dato/klokkeslett: 2009.10.02 02:45:37
Ferdig dato/klokkeslett: 2009.10.02 06:13:51
Tidsforbruk: 3 timer 28 min. 14 sek.
Antall tabeller lest: 62
Antall rader lest: 219549
Antall eksterne dokumenter: 47186
Antall lese/konverteringsfeil: 4
Produksjon av AIP - godkjenningDa SIP-en var i boks startet en prosess som er en av primær oppgavene til en arkivdepotinstitusjon i forbindelse med bevaring av eldre og avsluttet eArkiv. Nemlig det å gjøre en SIP om til en AIP, «Archival Information Package», det er i form av slike pakker at et eldre og avsluttet eArkiv langtidsoppbevares og vedlikeholdes i en offentlig arkivinstitusjon. Ved IKAR vil dette på det nåværende tidspunkt i den faglige og tekniske utviklingen knyttet til eArkiv si:
• Å gå igjennom avleveringen og sjekke at den tilfreds stiller de (juridiske) kravene som stilles til en avlevering. Mye av denne befaringen gjør vi ved IKAR i dag ved hjelp av programmet Altova XMLSpy. Samtidig har vi også laget en sjekkliste som vi bruker i dette arbeidet. Denne sjekklisten danner et viktig grunnlag for det godkjen nings brevet som sendes arkiveier/kommunen etter fullført gjennomgang og testing.
• Vi sjekker at påkrevd systemdokumentasjon følger avlever ingen/deponeringen hvis slik er tatt vare på i kommunen eller i det hele tatt eksisterer. Hvis arkivskaper ikke har systemdokumentasjon forsøker IKAR å skaffe slik via sitt faglige nettverk ved andre kommunale arkivinstitusjoner (KAI).
• Vi lager også fila INNHOLD.TXT hvis denne ikke følger av leveringen. (DEX lager ikke denne filen.)
• Vi foretar også en del testing av XML-filene som inne holder tabelldata. Blant annet importerer vi XML-filer fra databaseuttrekket til en database på en proprietær databaseplattform. Ved IKA Rogaland gjør vi i dag mye slik importering mot MySQL.
Etter en gjennomgang og testing som skissert i punktene ovenfor sendte vi godkjenningsbrev til Sola kommune den 13. november 2009 (IKAR sak/arkivreferanse: 09/164 – 18).
Sola kommune ønsker en DIP
Etter at Sola kommune hadde mottatt godkjenningsbrevet ble det fra arkivtjenesten i kommunen ytret ønsket om å få tilbake fra IKAR en kopi av dataene som ble reddet ut fra Informixmiljøet for oppslag i ennå noen år. Arkivleder i kommunen oppfattet tross alt ikke Forum Sak som et særlig gammelt system. Dette åpnet en mulighet for for midling for IKAR. Vi kunne lage en DIP for Sola kommune som arkivtjenesten kunne bruke på en lokal pc eller sette opp på kommunens intranett for oppslag. IKAR foreslo for Sola kommune å sette dette opp på kommunens forslag til arbeidsplan for IKAR for 2010. Som sagt så gjort. I februar 2010 laget IKAR en DIP (Data Information Package) for Sola kommune hvor vi gjorde følgende:
• Reimporterte de 4 XML-filene inn i en MySQL database ved hjelp av Altova XMLSpy og kontrollerte feltformatene i henhold til filen METADATA.XML i avleveringen.
• Deretter brukte vi programmet PHP-Runner til å designe oppslagsdatabasen bestående av nevnte MySQL-database og PHP-filer som kan kjøre i alle nettlesere vi kjenner til.
• Denne oppslagsdatabasen ble presentert for arkivtjenesten og IKT-avdelingen i Sola kommune den 2. mars 2010. De likte det de så og vil sette denne DIP-en opp på en virtuell server på kommunen sitt intranett i løpet av våren 2010.
Slik endte historien om Forum Sak i Sola kommune.
Hva har vi lært?
Når elektronisk arkivmateriale som skal bevares ligger på en gammel proprietær teknologisk plattform som tiden er i ferd med å løpe fra, kan utfordringene for å få til en vellykket bevaring være krevende både arkivfaglig, teknologisk og økonomisk. Ofte må ekstern kompetanse hentes inn for å lykkes. Man må i tillegg være tålmodig og bruke nødvendig tid for å lykkes. Som dette eksemplet viser så lar selv vanskelige utfordringer seg løse. Eksempelet med Forum Sak i Sola kommune viser også hvor viktig det er å få til en tidlig avlevering/deponering av et eldre og avsluttet elektronisk arkiv. Venter vi for lenge vokser problemet fordi den proprietære teknologien vokser fra en forlatt server med et eldre og avsluttet eArkiv på. Derfor heter det følgende i «Forskrift om offentlege arkiv» § 3-17: «Ein elektronisk kopi av basen for ein avslutta periode skal klargjerast for deponering i arkivdepot. [...]. Deponering skal skje straks, jf. elles føresegnene for avlevering frå statlege organ til Arkivverket, kap. V. Kommunar og fylkeskommunar skal følgje den same prosedyren eller eit anna opplegg som på fullgod måte ivaretek omsynet til langtidslagring og framtidig dokumentasjon.»