Teknisk dokumentation Anslutningsspecifikation e-arkiv Stockholm

Transkript

1 STADSARKIVET LANDSARKIV FÖR STOCKHOLMS LÄN Bilaga 4 Teknisk dokumentation Stadsarkivet Författare Version e-arkiv Stockholm Elin Kröger Nygren 1.1 Magnus Asplund Louise Högberg Senast ändrad (35)

2 Innehållsförteckning 1. Dokumentinformation Målgrupp Grundprinciper Anslutning 3 3. Synkron anslutning Övergripande beskrivning Beskrivning av användande Arkivera Söka -i form av fritextsökning Hämta ett unikt och komplett arkivobjekt Säkerhet Autentisering Behörighetsprincip Kryptering Publicerade webbtjänster ArchiveSipExtended SearchIndexObjects GetIndexObjectComplete GetFile GetFiles OrderDIP Felhantering Felkoder vid arkivering Asynkron anslutning Övergripande beskrivning Beskrivning av användande Struktur för massinlämning Inleveransflöde SIP-etiketten Åtkomst Kvittohantering och felhanteringsrutiner Säkerhet Åtkomst till miljöer Miljöer Testmiljö Preproduktionsmiljö Produktionsmiljö Brandväggsöppningar Extern åtkomst via VPN-anslutning Revisionshistorik 35 2 (35)

3 1. DOKUMENTINFORMATION Detta dokument beskriver, ur en teknisk synvinkel, hur synkron och asynkron anslutning till e-arkivet sker och har till syfte att underlätta anslutningsprocessen för verksamhetssystem. 1.1 Målgrupp Målgruppen för detta dokument är tekniskt orienterade personer som arbetar med anslutning till e-arkivet. 2. GRUNDPRINCIPER ANSLUTNING Leverans till och återsökning i e-arkivet kan ske antingen synkront eller asynkront. Eftersom synkron anslutning har begränsningar i storleken på paket som kan skickas, sker detta främst när man vill leverera mindre mängder data, vill ha omedelbar arkivering och omedelbar kvittens på leveransen. För att leverera och återsöka synkront utnyttjas Stockholms stads SOA-plattform. Asynkron anslutning kan med fördel användas när stora mängder data ska levereras vid ett eller fler tillfällen och det inte är viktigt med omedelbar kvittens på leveransen. T.ex. vid avställning av system eller vid årsskiften. Asynkron leverans sker genom att data levereras till en FTP-area varifrån informationen läses in till e-arkivet. Bilden nedan illustrerar grundprinciperna med anslutning till e-arkivet, oberoende av typ av anslutning, genom att beskriva de tre scenariorna Arkivera, Söka och Hämta. 3 (35)

4 Arkivera 1. En producent av information (avslutade ärenden) startar en arkivering (ett eller fler ärenden) 2. Ärendet packas ihop enligt överenskommelse om innehåll, format och struktur till en SIP (Submission Information Package) och skickas till e-arkivet. 3 E-arkivet validerar informationen (metadata och fil) enligt överenskomna regler. 4. Om leveransen är ok sparas arkivobjektet i leveransen till e-arkivets databas 5. En kvittens på mottagen leverans och genererad nyckel för arkivobjektet. Söka 6. En konsument ställer frågor om innehåll i e-arkivet 7. E-arkivet sammanställer svaren och returnerar resultatet i form av metadata. Hämta 8. En konsument kan, när den vet vilket objekt som den är ute efter utföra en hämtning genom en order av objektet. 9. Arkivobjektet levereras som ett paket innehållande metadata och filer. 3. SYNKRON ANSLUTNING För synkron anslutning tillhandahåller e-arkivet en webbtjänst som hanterar leverans, återsökning och hämtning. Tjänsten publiceras i Stockholm stads SOAplattform och anropas av anslutande verksamhetssystem. Vid leverans skickas en SIP (Submission Information Package) där de bifogade dokumenten inkluderas i meddelandet. Kvittoinformationen returneras omedelbart i svaret från webbtjänsten. Även vid återsökning och hämtning returneras resultatet omedelbart. 4 (35)

5 3.1 Övergripande beskrivning Bilden nedan illustrerar grundprinciperna för synkron anslutning genom scenario för Arkivera, Söka och Hämta. Arkivera 1. En producent vill arkivera information, t.ex. ur ett verksamhetssystem, vid avslut av ett ärende. 2. Information om ärendet och dess ingående handlingar packas i ett meddelande och skickas till e-arkivet genom anrop av en webbtjänst. 3 E-arkivet validerar informationen (metadata och fil) enligt överenskomna regler. 4. Om leveransen är ok sparas arkivobjektet i leveransen till e-arkivets databas 5. En kvittens på mottagen leverans och identifikation för arkivobjektet levereras omedelbart tillbaka till producenten i responsmeddelandet för webbtjänsten. Söka 6. En konsument ställer frågor om innehåll i e-arkivet genom anrop av en webbtjänst med ett meddelande innehållande sökfrågan. 7. E-arkivet sammanställer svaren och returnerar resultatet i form av metadata om handlingarna. Inga filer returneras i detta steg. Hämta 8. En konsument kan, när den vet vilket objekt den är ute efter, hämta objektet genom anrop av webbtjänst. 9. Arkivobjektet innehållande metadata och ev filer returneras i responsmeddelandet. 5 (35)

6 3.2 Beskrivning av användande Arkivera Anslutet system SOA-plattformen Navet e-arkiv avsluta ärende( ) Skapa metadata för arkivobjektet ::Användare av anslutet system Hämta fil från dokumentlager/skapa fil Skapa innehåll i SIP (metadata + fil) Anrop till WS - ArchiveSipExtended(SIP) ArchiveSipExtended(SIP) Kvitto(ArkivID/Felmeddelande) Kvitto(ArkivID/Felmeddelande) Uppdatera databas. Länka internt ID med ArkivID Söka -i form av fritextsökning Anslutet system SOA-plattformen Navet e-arkiv Identifiera sökbegrepp söka efter ärende( ) Skapa ett QueryRequest Anrop till WS - SearchIndexObject(QueryRequest) SearchIndexObject(QueryRequest) ::Användare av anslutet system Result/Felmedelande Result/Felmedelande Läs ur metadata och/eller ArkivID ur resultat Presentera resultatet 6 (35)

7 3.2.3 Hämta ett unikt och komplett arkivobjekt 3.3 Säkerhet Den webservice som finns i SOA-plattformen kräver att användaren/systemet autentiserar sig vid anrop och själva kommunikationen är säkrad via SSL (Secure Socket Layer). Autentiseringen är av typen basic http Autentisering Basic http-autentiseringen bygger på att ett systemkonto och lösenord sätts i anropet. Kontot och lösenordet beställs hos Service Centrum av behörig beställare på Stadsarkivet. 7 (35)

8 3.3.2 Behörighetsprincip 1. E-arkivet definierar en uppsättning attribut som är nödvändiga för att avgöra om utlämning av informationsobjekt är möjligt enligt regelverket 2. Inför en anslutning till e-arkivet översätts verksamhetens behörighetsmodell till e-arkivets behörighetsattribut. Detta sker i ett tjänstekontrakt. 3. VS ansvarar för att påföra rätt attribut vid ett anrop enligt tjänstekontraktet. 4. SOA Security Gateway översätter varje SOAP-request till HTTP-header. 5. E-arkivet avgör med hjälp av attributen om information kan lämnas ut eller ej Anslutande verksamhetssystem har till ansvar att påföra behörighetsattributen i meddelandet till e-arkivet. Dessa attribut används av sedan e-arkivet för att avgöra om slutanvändaren har rätt att lämna in eller ta del av informationen. Attributen sätts i form av SOAP-headers i anropet. Följande tre headers måste sättas: UserID Role IP Kryptering Anropen till SOA-tjänsten säkras genom SSL. 3.4 Publicerade webbtjänster Nedan följer en beskrivning av de webbtjänster som är publicerade i SOA-plattformen som kan anropas av anslutande system. De anslutande klienterna måste använda sig av SOAP Message Transmission Optimization Mechanism, MTOM, när bilagor ska sändas eller tas emot. Entiteter i arkivet har identifierare som ser ut på nedanstående sätt oavsett om det identifierar en fil, en nod i informationsredovisningsstrukturen eller ett helt arkivobjekt. Alla identifierare ser ut på följande sätt: iipax://objectbase.document/docpartition#<integer> Många av operationerna som beskrivs tar ett From-element som indata, detta element används då för att logga statistik om vilket system som använder arkivet. Undantaget är ArchiveSipExtended där From-elementet används för att koppla det inkommande arkivobjektet till ett inlämningskontrakt. Varje operation nedan beskrivs enligt signaturen returnerat objekt := metodnamn(inskickat objekt) ArchiveSipExtended Signatur: Kvitto := ArchiveSipExtended(SIP) 8 (35)

9 Beskrivning: ArchiveSipExtended används för inlämning av arkivobjekt som ligger packat i en SIP. Innan ett system börjar leverera information till arkivet skall Objekttyper skapas samt Inlämningskontrakt upprättas, denna process styr hur indata kommer att se ut. Indata beskrivs av ett Submission Information Package (SIP) definierat i OAIS modellen. En SIP består av metadata om det som arkiveras samt binärdata för de arkiverade filerna. Metadata kan se ut på olika sätt beroende på hur verksamheten ser ut men det består av en trädstruktur som är antingen två eller tre nivåer djup. Roten i metadata är ett IndexObject som kan beteckna t.ex. ett ärende hos verksamheten, enligt Stadsarkivets terminologi kallas detta för ett huvudobjekt. Ett IndexObjekt kan sedan innehålla antingen ett eller flera IndexDocument (alternativ 1 nedan) eller IndexFile (alternativ 2 nedan). Ett IndexDocument kan beteckna t.ex. en handling i ett specifikt ärende, enligt Stadsarkivets terminologi kallas detta för ett underobjekt. Ett IndexDocument kan sedan innehålla ett eller flera IndexFile-element som är metadata för filen samt tillhörande binärdata (filen). Objekt: SIP (förenklat alternativ 1) <Huvudobjekt> <metadata> <... <Underobjekt> <metadata> <... <Filobjekt> <metadata> <... <Binär fil> <FilObjekt> <metadata> <... <Binär fil> <Underobjekt> Objekt: SIP (förenklat alternativ 2) <Huvudobjekt> <metadata> <... <Filobjekt> <metadata> <... <Binär fil> <FilObjekt> <metadata> <... <Binär fil> 9 (35)

10 På IndexObject och IndexDocument nivån skall en objekttyp definieras i den inkommande SIP:en. Objekttyper finns definierade för den verksamhet som ansluter till systemet, dessa objektyper kan innehålla specifika verksamhetsattribut. IndexObject, IndexDocument samt IndexFile har ett DisplayName element som är den text som kommer att visas när man söker i arkivet efter ett visst ärende, handling eller fil. DisplayName för ett IndexObject skall vara en unik identitet såsom ett diarienummer. DisplayName för ett IndexFile-element skall vara filens namn. Ett filnamn har vissa syntaxregler, använd ej blanktecken eller svenska åäö i filnamnet. En fil skall ha en tillhörande checksumma beräknad enligt en viss algoritm, t.ex. SHA1, vilket anges i elementet lta_file_digest. IndexObject, IndexDocument och IndexFile kan även definiera ett eller flera attribut som beskriver objektet. Vilka dessa attribut är kan skilja mellan olika verksamheter och deras objekttyper, vissa av dessa är obligatoriska och vissa är valfria. Attributtyperna har även olika basala typer såsom strängvärden, datum, flyttal o.s.v. IndexObject-elementet har även elementen Producer och From som skall fyllas i. Producer avser den verksamhet som arkiverar och From är namnet på det system som arkiverar. Producer, From och ObjectType elementet bildar tillsammans en nyckel som avgör bland annat vart i arkivet SIP:en skall lagras samt vilka filformatskontroller som skall göras, detta definieras via ett så kallat Inlämningskontrakt (Submission agreement). Om inget inlämningskontrakt kan associeras med SIP:en kommer ett fel att returneras från anropet. Resultatet av operationen ArchiveSipExtended är att ett kvitto som innehåller identiteter till de resulterande objekten i arkivet. Kvittot har en trädstruktur på samma sätt som den inskickade SIP:en. Tillsammans med identiteten för varje skapat objekt följer också DisplayName med, detta eftersom arkivet inte har någon definierad sorteringsordning för de IndexDocument eller IndexFile element som ingår i ett arkivobjekt. Objekt: kvitto (förenklat) <kvitto> <huvudobjekt orgid = iipaxid> <underobjekt orgid = iipaxid> <filobjekt orgid = iipaxiid> <binärfil orgid = iipaxid> </kvitto> Objekt: felkvitto (förenklat) <ingestfel> <kategori></kategori> <kod></kod> <meddelande></meddelande> </ingestfel> 10 (35)

11 Exempel Exempelanrop för en arkivering och returnerat kvitto följer nedan. <soapenv:envelope xmlns:soapenv=" xmlns:ssa=" <soapenv:header/> <soapenv:body> <ssa:archivesipextendedrequest> <ssa:indexobject> <ssa:displayname>aiptest</ssa:displayname> <ssa:objecttype>huvudobjekt</ssa:objecttype> <!--Zero or more repetitions:--> <ssa:attribute name="original_id_definition"> <ssa:value>orginal Id definition</ssa:value> <ssa:attribute name="title"> <ssa:value>titeln</ssa:value> <ssa:producer>testproducent</ssa:producer> <ssa:from>testsystem</ssa:from> <ssa:indexdocument> <ssa:displayname>dokument</ssa:displayname> <!--Optional:--> <ssa:objecttype>lta_document</ssa:objecttype> <!--Zero or more repetitions:--> <ssa:attribute name="original_id_definition"> <ssa:value>definition</ssa:value> <ssa:attribute name="sekretess"> <ssa:value>nej</ssa:value> <ssa:attribute name="producer_system"> <ssa:value>producentsystem</ssa:value> <ssa:attribute name="producer_system_version"> <ssa:value>2.5</ssa:value> <!--1 or more repetitions:--> <ssa:indexfile> <ssa:displayname>ida_infront.pdf</ssa:displayname> <!--Zero or more repetitions:--> <ssa:attribute name="original_id_definition"> <ssa:value>filedef</ssa:value> <ssa:attribute name="language"> <ssa:value>enligt standard</ssa:value> <ssa:attribute name="format_name"> <ssa:value>enligt krav</ssa:value> <ssa:attribute name="format_version"> <ssa:value>pdf/a 1a</ssa:Value> <ssa:attribute name="lta_file_digest"> 11 (35)

12 <ssa:value>sha1:c879ccc8e3ca232126d07d5dee </ssa:v alue> <ssa:content> <xop:include href="cid:ida_infront.pdf" xmlns:xop=" /> </ssa:content> </ssa:indexfile> <ssa:indexfile> <ssa:displayname>buildingpermit.xml</ssa:displayname> <!--Zero or more repetitions:--> <ssa:attribute name="original_id_definition"> <ssa:value>filedef</ssa:value> <ssa:attribute name="language"> <ssa:value>enligt standard</ssa:value> <ssa:attribute name="format_name"> <ssa:value>enligt krav</ssa:value> <ssa:attribute name="format_version"> <ssa:value>pdf/a 1a</ssa:Value> <ssa:attribute name="lta_file_digest"> <ssa:value>sha1:3e616f3ed1df5256dad6003db80132d714971dbe</ssa:v alue> <ssa:content> <xop:include href="cid:buildingpermit.xml" xmlns:xop=" /> </ssa:content> </ssa:indexfile> </ssa:indexdocument> <ssa:indexdocument> <ssa:displayname>dokument2</ssa:displayname> <ssa:objecttype>lta_document</ssa:objecttype> <!--Zero or more repetitions:--> <ssa:attribute name="original_id_definition"> <ssa:value>definition</ssa:value> <ssa:attribute name="sekretess"> <ssa:value>nej</ssa:value> <ssa:attribute name="producer_system"> <ssa:value>producentsystem</ssa:value> <ssa:attribute name="producer_system_version"> <ssa:value>2.5</ssa:value> <!--1 or more repetitions:--> <ssa:indexfile> <ssa:displayname>kvarteretdetektiven.tif</ssa:displayname> <!--Zero or more repetitions:--> <ssa:attribute name="original_id_definition"> 12 (35)

13 <ssa:value>filedef</ssa:value> <ssa:attribute name="language"> <ssa:value>enligt standard</ssa:value> <ssa:attribute name="format_name"> <ssa:value>enligt krav</ssa:value> <ssa:attribute name="format_version"> <ssa:value>pdf/a 1a</ssa:Value> <ssa:attribute name="lta_file_digest"> <ssa:value>sha1:ec039411b6e9c29bd1746b45fe524b1ac66d2a5e</ssa:v alue> <ssa:content> <xop:include href="cid:ida_infront.pdf" xmlns:xop=" /> </ssa:content> </ssa:indexfile> </ssa:indexdocument> </ssa:indexobject> </ssa:archivesipextendedrequest> </soapenv:body> </soapenv:envelope> Ger ett resultat som liknar följande: <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns1:archivesipextendedresponse xmlns:ns1=" <ns1:indexobjectreceipt> <ns1:id>iipax://objectbase.document/docpartition#13101</ns1:id> <ns1:displayname>test Objekt</ns1:DisplayName> <ns1:indexdocumentreceipt> <ns1:id>iipax://objectbase.document/docpartition#13102</ns1:id> <ns1:displayname>dokument</ns1:displayname> <ns1:indexfilereceipt> <ns1:id>iipax://objectbase.document/docpartition#13104</ns1:id> <ns1:displayname>buildingpermit.xml</ns1:displayname> </ns1:indexfilereceipt> <ns1:indexfilereceipt> <ns1:id>iipax://objectbase.document/docpartition#13103</ns1:id> <ns1:displayname>ida_infront.pdf</ns1:displayname> </ns1:indexfilereceipt> </ns1:indexdocumentreceipt> <ns1:indexdocumentreceipt> <ns1:id>iipax://objectbase.document/docpartition#13105</ns1:id> <ns1:displayname>dokument2</ns1:displayname> <ns1:indexfilereceipt> <ns1:id>iipax://objectbase.document/docpartition#13106</ns1:id> <ns1:displayname>kvarteretdetektiven.tif</ns1:displayname> 13 (35)

14 </ns1:indexfilereceipt> </ns1:indexdocumentreceipt> </ns1:indexobjectreceipt> </ns1:archivesipextendedresponse> </soapenv:body> </soapenv:envelope> SearchIndexObjects Signatur: IndexObject* := SearchIndexObjects(Query+, From?, SearchRootPath?) Beskrivning: Används för att söka fram information om objekt när identiteter i e-arkivet inte är kända. Sökningar kan utföras på alla metadataattribut. Objekt: Sökfråga (Query) En Sökfråga består av: ObjectType objekttypsfilter. Kan utelämnas SearchCondition valfri parameter som kan förekomma flera gånger och används för att definiera sökvillkor. En sökträff måste uppfylla samtliga sökvillkor. SearchCondition består av: o Attribute namnet på ett sökbart attribut. o Operator villkorets operator. o Value sökvärde. Returvärde: Resultatet består av en lista av de huvudobjekt som innehåller dokument som matchar sökfrågan. Objekten returneras inte med alla sina underordnade objekt. Endast de som direkt medverkade till att objektet returnerades ingår. Om någonting går fel returneras ett AccessFault innehållande ett felmeddelande. Det valfria SearchRootPath-elementet används om man vill begränsa träffmängden genom att bara söka i ett delträd i informationsredovisningsstrukturen. Elementet innehåller ett eller flera Container element, ett Container element per nod i informationsredovisningsstrukturen. Resultatet består av en lista av de arkivobjekt som innehåller de underobjekt och/eller filobjekt som matchar sökfrågan. Arkivobjekten returneras inte med alla sina underordnade objekt utan endast de som direkt medverkade till att arkivobjektet returnerades ingår. Detta möjliggör träffmarkering i en klient. För att hämta samtliga underordnade objekt till ett arkivobjekt används istället GetFiles-operationen. Anges flera villkor i sökfrågan måste alla dessa vara sanna för att generera en träff. Om frågan dessutom är begränsad med objekttyp måste attributen vid sökningen vara definierad på aktuell objekttyp för att träffar ska genereras. Vid flera sökfrågor kommer snittet av träffmängderna att returneras. Detta innebär att det är möjligt med ytterligare filtrering av en träffmängd genom att ställa ytterligare en fråga. 14 (35)

15 Objekt: felkvitto (förenklat) <accessfel> <meddelande></meddelande> </accessfel> Fritextsökning Det finns möjligheter att göra fritextsökningar i arkivet genom att använda det reserverade attributnamnet text_search. Om man vill söka på filinnehåll där termen Melanders återfinns skriver man: content:melanders. Skriver man inte content: framför kommer arkivet att söka i de objektattribut i metadata som är konfigurerade för fritextsökning. Söktermer med blanksteg kan man söka efter ifall man omsluter dem med citat tecken. Till exempel Melanders Fisk söker efter denna exakta fras. Söktermer med wildcards kan användas t.ex. kan man skriva Melanders* om man vill söka efter alla termer som börjar med Melanders. Asterisken betyder noll, ett eller flera valfria tecken. Även? finns definierad som ett wildcard och betyder ett valfritt tecken. Man kan inte börja en term med ett wildcard så följande termer är ogiltiga *Melanders och?fisk. Logiska operatorerna AND, OR och NOT finns definierade och har standardbetydelse. Även operatorerna + och finns. Skriver man till exempel +Melanders Fisk betyder detta att Melanders måste finnas men att Fisk är valfri. Vill man söka på dokument som innehåller Melanders men inte Fisk skriver man Melanders Fisk. Om det är så att söktermen i sig innehåller ett minus eller plus måste dessa föregås av prefixet \\ Exempel Nedan syns ett exempelanrop: <soapenv:envelope xmlns:soapenv=" xmlns:ssa=" <soapenv:header/> <soapenv:body> <ssa:searchindexobjectsrequest> <!--1 or more repetitions:--> <ssa:query> <!--Zero or more repetitions:--> <!--<ssa:objecttype>huvudobjekt</ssa:objecttype>--> <!--1 or more repetitions:--> <ssa:searchcondition> <ssa:attribute>display_name <!--Optional:--> 15 (35)

16 <ssa:operator>equal</ssa:operator> <!--Optional:--> <ssa:value>aipobjekt</ssa:value> </ssa:searchcondition> </ssa:query> <!--Optional:--> <ssa:from>testsystem</ssa:from> <!--Optional:--> <ssa:searchrootpath> <!--1 or more repetitions:--> <ssa:container>ssa-test</ssa:container> </ssa:searchrootpath> </ssa:searchindexobjectsrequest> </soapenv:body> </soapenv:envelope> Kan ge resultatet: <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns1:searchindexobjectsresponse xmlns:ns1=" <ns1:indexobjectref> <ns1:id>iipax://objectbase.document/docpartition#3</ns1:id> <ns1:displayname>aipobjekt</ns1:displayname> <ns1:objecttype>huvudobjekt</ns1:objecttype> <ns1:attribute name="created_by"> <ns1:value>iipaxsystem</ns1:value> </ns1:attribute>... <ns1:attribute name="original_id_definition"> <ns1:value>orginal Id definition</ns1:value> </ns1:attribute> </ns1:indexobjectref> </ns1:searchindexobjectsresponse> </soapenv:body> </soapenv:envelope> GetIndexObjectComplete Signatur: DIP := GetIndexObjectComplete(Id, From?) Beskrivning: GetIndexObjectComplete används för att hämta ut ett Dissemination Information Package (DIP) ur arkivet. En DIP liknar en SIP, med skillnaden att de ingående objekten har identiteter satta. Binärdata kommer att skickas tillbaka i separata MIME-datadelar. Id-elementet skall peka antingen på ett huvudobjekt (IndexObject), ett underobjekt (IndexDocument) eller en fil (IndexFile). Om id pekar på ett IndexDocument eller en IndexFile hämtas delmängder av det lagrade arkivobjektet. Svaret ser ut på lite olika sätt beroende på vilket id som skickades in. 16 (35)

17 1. Om det inskickade ID:t pekar på ett huvudobjekt skall huvudobjektet och alla underliggande objekt returneras. 2. Om det inskickade ID:t pekar på ett underobjekt skall underobjektet och alla underliggande objekt returneras men även det omslutande huvudobjektet. 3. Om det inskickade ID:t pekar på ett filobjekt skall filobjektet returneras men även det omslutande underobjektet och det omslutande huvudobjektet. Det är alltså alltid ett IndexObject element som är roten i svaret. Objekt: ID Identiteten i arkivet på ett huvudobjekt, ett underobjekt eller filobjekt Objekt: DIP (förenklat) <Huvudobjekt> <metadata> <... <Underobjekt> <metadata> <... <Filobjekt> <metadata> <... <Binär fil> <FilObjekt> <metadata> <... <Binär fil> <Underobjekt> Objekt: felkvitto (förenklat) <AccessFault> <felmeddelande></felmeddelande> </AccessFault> Exempel <soapenv:envelope xmlns:soapenv=" xmlns:ssa=" <soapenv:header/> <soapenv:body> <ssa:getindexobjectcompleterequest> <ssa:id>iipax://objectbase.document/docpartition#13260</ssa:id> <!--Optional:--> <ssa:from>testsystem</ssa:from> </ssa:getindexobjectcompleterequest> </soapenv:body> </soapenv:envelope> Ger svaret (vissa metadata-attribut är bortplockade): 17 (35)

18 <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns1:getindexobjectcompleteresponse xmlns:ns1=" <ns1:indexobject> <ns1:id>iipax://objectbase.document/docpartition#13260</ns1:id> <ns1:displayname>aiptest~29</ns1:displayname> <ns1:objecttype>huvudobjekt</ns1:objecttype> <ns1:attribute name="created_date"> <ns1:value> :08:00</ns1:Value> </ns1:attribute>... <ns1:indexdocument> <ns1:id>iipax://objectbase.document/docpartition#13261</ns1:id> <ns1:displayname>dokument</ns1:displayname> <ns1:attribute name="created_date"> <ns1:value> :08:00</ns1:Value> </ns1:attribute>... <ns1:indexfileref> <ns1:id>iipax://objectbase.document/docpartition#13262</ns1:id> <ns1:displayname>ida_infront.pdf</ns1:displayname> <ns1:attribute name="created_by"> <ns1:value>iipaxsystem</ns1:value> </ns1:attribute>... <ns1:content> <xop:include xmlns:xop=" </ns1:content> </ns1:indexfileref> </ns1:indexdocument> </ns1:indexobject> </ns1:getindexobjectcompleteresponse> </soapenv:body> </soapenv:envelope> GetFile Signatur: Filnamn+Fildata := GetFile(Id, From?) Beskrivning: Denna operation används för att hämta upp binärdata för ett visst arkiverat filobjekt. Denna operation tar en identitet som indata samt ett valfritt From element som används för att logga statistik. Objekt: ID Ett id som pekar på filobjektet Returvärde: Resultatet innehåller filens data som en Base64-kodad sträng 18 (35)

19 Objekt: felkvitto (förenklat) <AccessFault> <felmeddelande></felmeddelande> </AccessFault> Exempel Exempel på anrop ser ut som följer: <soapenv:envelope xmlns:soapenv=" xmlns:ssa=" <soapenv:header/> <soapenv:body> <ssa:getfilerequest> <ssa:id>iipax://objectbase.document/docpartition#13230</ssa:id> <!--Optional:--> <ssa:from>testsystem</ssa:from> </ssa:getfilerequest> </soapenv:body> </soapenv:envelope> Som ger följande svar i SOAP datadelen, plus binärdata i en separat MIME-del utpekad av xop:include elementet: <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns1:getfileresponse xmlns:ns1=" <ns1:indexfile> <ns1:displayname>ida_infront.pdf</ns1:displayname> <ns1:content> <xop:include href="cid:1.urn:uuid:5859f5d5d52b5198e @apache.org" xmlns:xop=" </ns1:content> </ns1:indexfile> </ns1:getfileresponse> </soapenv:body> </soapenv:envelope> GetFiles Signatur: Metadata := GetFiles(Id,From?) Beskrivning: Används för att hämta upp metadata om underobjekt samt filobjekt genom en identitet till ett arkivobjekt. Denna operation skiljer sig från GetIndexObjectComplete som även hämtar metadata för huvudobjektet vars identitet man skickar in. Precis som GetFile operationen kan man skicka in ett From element som används för statistikgenerering. 19 (35)

20 Objekt: ID Ett id som pekar antingen på ett huvudobjekt eller ett underobjekt Returvärde: 1. Om ID:t pekar på ett huvudobjekt kommer antingen en lista med underobjekt att hämtas, eller kommer en lista på filobjekt att returneras. Ingen blandning av Underobjekt eller Filobjekt tillåts. Detta har att göra med strukturen som beskrivits under ArchiveSIP metoden. 2. Om ID:t pekar på ett underobjekt kommer en lista med filobjekt att returneras. Objekt: felkvitto (förenklat) <AccessFault> <felmeddelande></felmeddelande> </AccessFault> Ett exempel på anrop ser ut som följer: <soapenv:envelope xmlns:soapenv=" xmlns:ssa=" <soapenv:header/> <soapenv:body> <ssa:getfilesrequest> <ssa:id>iipax://objectbase.document/docpartition#13260</ssa:id> <!--Optional:--> <ssa:from>testsystem</ssa:from> </ssa:getfilesrequest> </soapenv:body> </soapenv:envelope> Detta anrop kan ge följande svar (ett svar som har ett underobjekt med en fil under sig). Vissa metadata attribut har utelämnats för att korta ner svaret. <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns1:getfilesresponse xmlns:ns1=" <ns1:indexdocumentref> <ns1:id>iipax://objectbase.document/docpartition#13261</ns1:id> <ns1:displayname>dokument</ns1:displayname> <ns1:attribute name="created_date"> <ns1:value> :08:00</ns1:Value> </ns1:attribute>... <ns1:indexfileref> <ns1:id>iipax://objectbase.document/docpartition#13262</ns1:id> <ns1:displayname>ida_infront.pdf</ns1:displayname> <ns1:attribute name="created_by"> <ns1:value>iipaxsystem</ns1:value> </ns1:attribute> 20 (35)

21 ... </ns1:indexfileref> </ns1:indexdocumentref> </ns1:getfilesresponse> </soapenv:body> OrderDIP Beskrivning: Används för att göra en beställning av arkivobjekt som DIP. Signatur: Kvitto := OrderDip(OrderItem+, DeliveryChannel, Customer, IncludeFileContent) Objekt: Lista<ID, leveranskanal) En lista med id och önskad leveranskanal. ID:t pekar antingen på ett strukturobjekt, huvudobjekt eller ett underobjekt Returvärde: Ett OrderID Ett exempel på anrop ser ut som följer: <soapenv:envelope xmlns:soapenv=" xmlns:ssa=" <soapenv:header> <! - Your SOAP header attributes here: --> </soapenv:header> <soapenv:body> <ssa:orderdiprequest> <ssa:orderlist> <!--1 or more repetitions:--> <ssa:orderitem>iipax://objectbase.document/docpartition#514801</ss a:orderitem> </ssa:orderlist> <ssa:deliverychannel> </ssa:deliverychannel> <ssa:customer> <ssa:name> <ssa:firstname>ma SYNKRON soa</ssa:firstname> <ssa:lastname>ma</ssa:lastname> </ssa:name> <ssa:streetaddress>kungsklippan 6 OR Box 22063</ssa:StreetAddress> <ssa:zipcode>10422</ssa:zipcode> <ssa:postalarea>stockholm</ssa:postalarea> <ssa: >magnus.asplund@stockholm.se</ssa: > <ssa:phone> </ssa:phone> </ssa:customer> <ssa:comment>end user s comment here</ssa:comment> <ssa:includefilecontent>true</ssa:includefilecontent> </ssa:orderdiprequest> </soapenv:body> </soapenv:envelope> Objekt: felkvitto (förenklat) <AccessFault> 21 (35)

22 <felmeddelande></felmeddelande> </AccessFault> 3.5 Felhantering Felkoder vid arkivering Fel vid arkviering ger ett SOAP fault där details-elementet innehåller felkategori, felkod och ett beskrivande meddelande. Det finns tre olika felkategorier definierade i e-arkivet, dessa är: META_DATA_ERROR som betyder att klienten har skickat in felaktigt metadata. Metadatafel som returneras från iipax Archive har en felkod mellan samt 0. FILE_DATA_ERROR som betyder att klienten har skickat in felaktigt filinnehåll. Fildatafel som returneras från iipax Archive har en felkod mellan samt 1. INTERNAL_ERROR som betyder att något oförutsett har hänt på servern. Denna har i regel felkod ASYNKRON ANSLUTNING För asynkron anslutning tillhandahåller e-arkivet en FTP-tjänst för leverera SIP:ar till arkivet. Kvittoinformationen returneras till samma FTP-area så fort inleveransen är klar. Återsökning av arkiverat material som levererats via FTP-tjänsten kan ske via: via den synkrona webbtjänsten (integration via SOA) vilket passar system som är synkront anslutna till e-arkivet. via speciellt klientprogram för e-arkivet som vissa arkivarieroller och handläggare har tillgång till. som självservice via e-arkivets publika söktjänst på Internet avsett för allmänheten men även för personal som har åtkomst till klientprogrammet. Stadsarkivet har för internt bruk även en lösning i FTP-plattformen för att mellanlagra större DIP-paket ut från arkivet innan slutkund får sin leverans med begärt arkivmaterial, att avhämtas på plats eller skickas på CD-ROM. Enkelt uttryckt en omvänd leveransarea. 4.1 Övergripande beskrivning Bilden nedan illustrerar grundprinciperna för asynkron anslutning genom scenario för Arkivera, Söka och Hämta. 22 (35)

23 Arkivera 1. En producent vill arkivera en stor informationsmängd. 2. En SIP innehållande flera arkivobjekt i en katalogstruktur skickas till en inleveransarea. 3 Leveransen valideras mot reglerna i e-arkivet. 4. Om leveransen är ok läggs denna till en intern kö för att vidare bearbetning. 5. e-arkivet bearbetar objekten sekventiellt från kön. 6. Databasen uppdateras med arkivobjekten. 7. Efter samtliga objekt är bearbetade skapas ett kvitto som läggs på inleveransarean. 8. Kvittot hämtas av producenten. Söka och hämta 9. En konsument gör en sökning via söktjänsten/e-tjänsten för e-arkivet. Om konsument har rätt att ta del av materialet, i detta fall via Internet, visas innehållet direkt via söktjänsten. Om materialet är skyddat genom sekretess eller åtkomst via Internet är begränsat av PuL sker istället följande: En konsument med intresse att hämta ett eller flera arkivobjekt gör en förfrågan till stadsarkivet via söktjänsten/e-tjänsten för e-arkivet. 10. Genom arkivklientens ärendehantering skapas en handläggningsprocess inkluderande menprövning avseende det efterfrågade arkivmaterialet. 11. Det färdiga paketet av arkivobjekt (DIP) skickas till area för utlämning. 12. DIP skickas ut enligt överenskommen kanal (mail, leveransarea, manuellt). 23 (35)

24 4.2 Beskrivning av användande För att utföra en asynkron ingest överförs data till en FTP-area i form av filer i en mappstruktur. Denna mappstruktur levereras sedan in asynkront till e-arkivet. När leveransen är färdig skrivs en kvittens som kan hämtas för kontroll av resultatet. Inleveranserna måste organiserade på ett strukturerat sätt för att de ska läsas in korrekt i e-arkivet. Detta beskrivs i avsnittet nedan Struktur för massinlämning Varje anslutande system har en inloggning, ett användarkonto, till FTP-arean. I själva verket finns ett konto per systemmiljö för e-arkivet, dvs tre konton totalt per anslutning, men i det följande betraktar vi en miljö separat. Principen för de andra miljöerna är lika. Vid inloggning hamnar den inloggande parten i en egen avgränsad rotkatalog/hemkatalog med fullständiga läs- och skrivrättigheter i sin egen mappstruktur. Rotkatalogen innehåller i normalfallet två stycken filareor. Den ena filarean är avsedd att hantera SIP-paket som endast valideras mot arkivet utan att arkivera något. Denna filarea (filkatalog) heter validate. Den andra filarean är avsedd att hantera SIP-paket där e- arkivet först utför en validering för att sedan arkivera SIP-paketen. Denna filarea (filkatalog) heter ingest. Varje filarea kan innehålla så kallade jobb. Jobb har en viss livscykel som beskrivs nedan. Ett arkiveringsjobb är tänkt att vara atomiskt, antingen lyckas arkiveringen av samtliga SIP-paket i jobbet eller arkiveras ingenting. För att åstadkomma detta gör man först en fullständig validering av jobbet och sedan kommer en arkivering att ske endast om allting gått bra. De svar man fått från valideringarna och/eller arkiveringarna kommer att rapporteras på jobbnivå. Ett jobb som är redo att behandlas känns igen på att mappen som representerar jobbet har ändelsen.request. En massinlämning kan bestå av flera SIP-paket. Varje SIP-paket organiseras då i mappar och känns igen på att de har en SIP-etikett i sig. Namnet på filen som representerar SIPetiketten är konfigurerbart men det förkonfigurerade filnamnet är SIPLabel.xml. SIPetiketten refererar till de filer som skall arkiveras och dessa filer måste ligga i samma mapp som SIP-etiketten. Observera följande: Antalet filer som följer med i SIP-paketet måste stämma exakt med antalet IndexFile-element i SIP-etiketten och att mappen som representerar ett SIPpaket får inte innehålla några undermappar. Filer som är inkluderade i SIP-paketet och därmed skall refereras till i SIPetikettfilen skall inte innehålla blanktecken. Filnamn måste bestå av en sammanhängande sträng alfanumeriska tecken inklusive punkt som avskiljningstecken för t.ex. filändelse. Flera punkter är tillåtna t.ex. filnamn.doc.pdf Filer som ej tillhör SIP-paketet skall ej heller ligga och skräpa i SIP-paketets mapp. Sådana ovidkommande filer medför normalt sett att valideringsfel erhålls. 24 (35)

25 När en scanning av filarean startas kommer mapparna under filarean att traverseras. De mappar som slutar på.request anses vara inleveranser. Dessa kan dock ligga på vilket djup som helst i en mappstruktur. När en sådan mapp har påträffats scannas jobbmappen igenom efter SIP-paket. Även SIP-paketen kan ligga på olika djup Inleveransflöde När ett system håller på att överföra filer för ett jobb till filarean är då viktigt att mappnamnet inte slutar på.request eftersom jobbet då riskerar att påbörjas innan alla SIP-paket är färdigskrivna till filarean. Ett lämpligt namn under FTP-överföringen kan vara t.ex..request.init. När filöverföringen är klar kan inleveransen initieras genom att döpa om mappens ändelse till.request. När jobbet som skannar av filarean körts igång, kommer mappen att få ändelsen.request.validate.processing. Om inte alla SIP-paket validerats korrekt mot arkivet kommer mappen att döpas om till request.validate.error och ingen mer bearbetning kommer ske. Vare sig valideringen går bra eller inte skrivs valideringskvitto i kvittensmappen (.reply) i filen validate. Om valideringen går bra kommer den faktiska inleveransen starta och mappen får ändelsen.request.ingest.processing. Om någonting går fel får mappen ändelsen.request.ingest.error och ingen mer bearbetning kommer ske. I slutet av inleveransen skrivs kvitto i kvittensmappen (.reply) i filen ingest. 25 (35)

26 Mappstrukturen för ett visst system skulle då kunna se ut som följande: Systemspecifik mapp <job1>.request.processed SIPEtikett.xml Fil1.xml Fil2.pdf <job2>.request.ingest.processing SIPEtikett.xml Fil3.xml <job1>.reply validate ingest <job2>.reply validate Nedan ett konkret exempel på hur en leverans till FTP-arean kan se ut via ett grafiskt FTP-klientprogram på PC. Bild nedan: Del av FTP-areans grundstruktur som visar tre anslutande system/förvaltningar med vardera ingest- respektive validate-mappar i sina respektive rotkataloger där FTP-inloggningen ansluter. Rotkatalogerna i bild är tillstand, ssa respektive mus vilket ett anslutande system av naturliga skäl inte ser namnet på vid inloggning. Stadsarkivet och e-arkivets serverprogram har dock full åtkomst till hela mappstrukturen nedan i bild från stora roten / och nedåt i strukturen. 26 (35)

27 I nedanstående exempel är rotkatalogen lika med nivån tillstand vilket visas i de två följande bilderna. Bild nedan: Detaljerad vy med SIP-paket benämnt bestående av en SIP-etikettfil, två PDF-dokument och en metadatafil. SIP-paketet ingår i jobbet request. Bild nedan: Jobbet är redan exekverat och har därför namnet request.processed under ingest-katalogen vilken också innehåller de två filer receipt.validate och receipt.ingest som vardera innehåller en lista över de filer som jobbet hanterat i respektive steg, validate resp ingest. 27 (35)

28 Bild nedan: Kvittensfilen ingest infälld underst i bilden ihop med kvittensmappen reply efter en ingest som har arkiverats i e-arkivet SIP-etiketten SIP-etiketten måste följa viss struktur och innehåll. Vilka metadata som, förutom de obligatoriska, måste anges konfigureras upp per anslutande system och objekttyp under anslutningsprocessen. 28 (35)

29 Följande krav finns på SIP-etiketten: Grundstruktur: <?xml version="1.0" encoding="iso "?> <IndexObject> <DisplayName value="{unikt ID för informationsobjektet på huvudobjektnivå}"/> <ObjectType name="{unikt tekniskt namn som anvisas av stadsarkivet}"/> <Attribute name="original_id_definition"> <Value>{Definition/förklaring av DisplayName ovan}</value> <Attribute name="title"> <Value>{Vedertaget namn för informationen ifråga}</value> <Attribute name="sekretess"> <Value>{Numeriskt värde enligt utförd sekretessklassificering}</value> <Attribute name="pul"> <Value> Numeriskt värde enligt utförd pul-klassificering}</</value> <Attribute name="lta_system"> <Value>{Namn på Procucent namn på System}</Value> <Attribute name="producer_system_version"> <Value>{Eventuellt versionsnummer för System}</Value> <Attribute name="startdatum"> <Value>{Datum på formen ÅÅÅÅ-MM-DD}</Value> <Attribute name="slutdatum"> <Value>{Datum på formen ÅÅÅÅ-MM-DD}</Value> {Eventuella verksamhetsspecifika attribut läggs in här!} <Producer name="{tekniskt namn som definierar producenten anvisas av stadsarkivet}"/> <From name="{tekniskt namn som definierar systemet informationen ursprungligen kommer ifrån anvisas av stadsarkivet}"/>"/> <IndexDocument> <DisplayName value="{id för informationsobjektet på underobjektnivå}"/> <ObjectType name="{unikt tekniskt namn som anvisas av stadsarkivet}"/> <Attribute name="original_id_definition"> <Value>{Definition/förklaring av DisplayName ovan}</value> <IndexFile> <DisplayName value="{här anges filens namn inklusive filändelse}"/> <Attribute name="original_id_definition"> <Value>{Definition/förklaring av DisplayName ovan}</value> <Attribute name="lta_file_digest"> <Value>SHA1:{Här anges checksumma för filen enligt SHA1-algoritm (40 tkn)}</value> <Attribute name="language"> <Value>sv</Value> <Attribute name="format_name"> <Value>{Här anges MIME-typ för filen, tex för en vanlig textfil är värdet text/plain}</value> <Attribute name="format_version"> <Value/> </IndexFile> </IndexDocument> </IndexObject> <ObjektType> för <IndexObject>-nivån och <Producer> samt <From> måste anges för att inlämningskontraktet ska kunna identifieras. 29 (35)

30 Metadata anges i <Attribute>-element med dess interna namn samt värde. I etiketten nästlar man ett eller flera <IndexFile>-element i <IndexDocument>element och ett eller flera <IndexDocument>-element under <IndexObject>elementet på toppnivå. Metadata med det interna namnet display_name anges med ett eget element, <DisplayName>, och ska inte anges via något <Attribute>-element. <DisplayName>-elementet är obligatoriskt på alla tre nivåer. För att ett SIP-paket ska bli accepterat så krävs det att alla obligatoriska metadata för de i etiketten utpekade objekttyperna finns med och är ifyllda, med korrekt format där syntaxvalidering sker. Attributen pul och sekretess skall ex.vis alltid finnas med. <DisplayName>-elementet under <IndexFile>-nivån måste matcha namnet på en fil i SIP-paketet. Det måste följaktligen finnas lika många <IndexFile>-element i etiketten som det finns filer i SIP-paketet om man inte räknar med SIPLabel.xml-filen. För filer som ingår i SIP-paketet skall en checksumma per fil anges inom <IndexFile>elementet för attributet <lta_file_digest>. Man kan även ange <ObjectType> för <IndexDocument> nivån. Detta gör att man kan använda olika objekttyper för olika dokumentobjekt i samma SIP-paket. Ett exempel på SIP-etikett med reella attributvärden: Fetstilmarkerade element har särskilt beskrivits ovan med de olika arkivobjektnivåerna i blå text. <?xml version="1.0" encoding="iso "?> <IndexObject> <DisplayName value="tav1-20" /> <ObjectType name="ritningsärende_birka" /> <Attribute name="original_id_definition"> <Value>Ritningsnummer</Value> <Attribute name="sekretess"> <Value>0</Value> <Attribute name="pul"> <Value>0</Value> <Attribute name="lta_system"> <Value>Birka</Value> <Attribute name="birka_ritningsnummer"> <Value>Tav1-20</Value> <Attribute name="birka_datum"> <Value> </Value> <Attribute name="birka_typ"> <Value>Ritning</Value> <Attribute name="birka_nät"> <Value>Täby</Value> <Attribute name="birka_stadsdel"> <Value> </Value> 30 (35)

31 <Attribute name="birka_område"> <Value> </Value> <Attribute name="birka_delområde"> <Value> </Value> <Attribute name="birka_ritningstyp"> <Value>Fjärrvärmeritning</Value> <Attribute name="birka_status"> <Value>Ritad, ej byggd</value> <Attribute name="birka_digitalt_original"> <Value>Ja</Value> <Attribute name="birka_plan"> <Value>Ja</Value> <Attribute name="birka_profil"> <Value>Ja</Value> <Attribute name="birka_schema"> <Value>Nej</Value> <Attribute name="birka_diagram"> <Value>Nej</Value> <Attribute name="birka_smide"> <Value>Nej</Value> <Attribute name="birka_kammare_schakt"> <Value>Nej</Value> <Attribute name="birka_adress"> <Value> </Value> <Attribute name="birka_plats"> <Value> </Value> <Producer name="birka" /> <From name="ritning" /> <IndexDocument> <DisplayName value="täv1-20" /> <ObjectType name="ritningshandling_birka" /> <Attribute name="original_id_definition"> <Value>Ritningsnummer</Value> <Attribute name="sekretess"> <Value>0</Value> <Attribute name="pul"> <Value>0</Value> <Attribute name="lta_system"> <Value>Fjärrvärmeritningar</Value> <IndexFile> <DisplayName value="tav1-20.tif" /> <Attribute name="original_id_definition"> <Value>Ledningsportföljens ritningsregister</value> <Attribute name="lta_file_digest"> <Value>SHA1:38a8f20a36fb2a1d e06fc27464cea3124</Value> <Attribute name="language"> <Value>sv</Value> 31 (35)

32 <Attribute name="format_name"> <Value>image/tiff</Value> <Attribute name="format_version"> <Value>OCE TIFF V1.0</Value> </IndexFile> </IndexDocument> </IndexObject> Åtkomst Adressen till FTP-arean är: ftp.stockholm.se För att komma åt FTP-arean måste anslutning ske inom Stockholm Stads nät och för inloggning behövs ett FTP-konto som är specifikt för anslutande verksamhetssystem Rutiner för uppsättning av FTP-konto Beställning av FTP-konto begärs via ServiceCentrum hos driftleverantören Tieto. Endast behörig beställare hos Stadsarkivet kan beställa FTP-åtkomst för en anslutning Kvittohantering och felhanteringsrutiner Kvittenser hamnar i en nyskapad mapp, en för varje jobb. En kvittensmapp som är färdig att hämtas slutar på.reply. Om jobbmappen lämnades in som job1.request kommer motsvarande kvittensmapp att heta job1.reply och ligga i samma katalog som jobbmappen. En kvittensmapp kan innehålla antingen en valideringsresultatfil och en arkiveringsresultatfil eller bara en valideringsresultatfil beroende på om man använder en valideringsfilarea eller en arkiveringsfilarea och beroende på om valideringssteget i en arkivering lyckats eller inte. Valideringsresultatfilen heter validate och arkiveringsresultatfilen heter ingest. Båda dessa är XML-filer. Kortfattat så innehåller resultatfilen noll, ett eller många resultatposter. Varje resultatpost innehåller sökvägen till SIP-paketet relativt jobbmappen samt ett resultat. Resultatfilen innehåller enbart en resultatrad per arkivobjekt, dvs för hela arkivobjektet angivet på huvudobjektnivå, det objekt som benämns IndexObject internt i arkivet. Resultatet kan vara på två olika format. Det första formatet signalerar att något fel har hänt i massinlämningen innan man har skickat iväg SIP-paketet till arkivet. Då får man ett felmeddelande som beskriver vad som gått fel. Denna typen av svar ligger i XML-elementet ClientError. 32 (35)

33 Den andra typen av svar man kan få är svar ifrån arkivet angående hur valideringen eller arkiveringen har gått. Denna typ av svar ligger i XML-elementet ServerResponse där innehållet i elementet är samma som SipStatus-svarets innehåll (SipStatus är en operation som går att utföra på webbtjänsten i iipax Archive). Observera att, till skillnad från synkron ingest, ger den asynkrona ingesten ett kvitto som ger direktåtkomst endast till huvudobjektnivå (IndexObject). Ingående underobjekt (IndexDocument eller IndexFile) ges ingen egen kvittens. Exempel: Kvittensfilen ingest har en struktur enligt exempel nedan, med en <Result> element (en rad) per SIP-paket (per ärende / huvudobjekt): <?xml version='1.0' encoding='utf-8'?> <Batchresult> <Result><Path>241922</Path><ServerResponse><Status>ARCHIVED</Status><Id>i ipax://objectbase.document/docpartition#250901</id></serverresponse></res ult> </Batchresult> Hur tolkas ovanstående kvittens? SIP-paketet består av ett ärende, uttryckt i mer verksamhetsnära termer. Ärendets status efter arkivering är ARCHIVED, dvs arkivering har skett. Motsatsen är ERROR om fel inträffat, dvs arkivering har ej skett. Idnumret efter docpartition# i <Id> elementet är det unika löpnummer som ärendet/sip-paketet har fått i e-arkivet. Detta Id kan användas för återsökning av ärendet i e-arkivet. Med OAIS-terminologi kallas det arkiverade SIP-paketet för AIP (arkivobjekt). 4.3 Säkerhet Anslutande system kommer endast ha tillgång till den mappstruktur som tilldelats dem under anslutningsprocessen och således inte komma åt data från något annat anslutande system. 5. ÅTKOMST TILL MILJÖER E-arkivet tillhandahåller tre olika miljöer för olika faser i en anslutning. Test, Preproduktion och Produktion. Var och en av dessa består av en instans av FTP-area, SOA-miljö och e-arkiv server (iipax Archive). 33 (35)

34 5.1 Miljöer Utveckling Integrationstest Pre-produktion Produktion - Kontinuerliga tester för e-arkivsförvaltningen -Test av - integration mellan e-arkiv och anslutningar -En produktionslikmiljö - där produktuppgraderingar, konfigurationer och anpassningar kan. testas (en så produktionslik miljö som möjligt) -En produktionsmiljö - med redundans och möjlighet att skala. upp med behoven av utökad prestanda och last Singleserver -iipax archive -Applicationserver -Database server Iipax archive Application Server Application Server(s) Iipax archive Iipax archive Application Server(s) Database server Database Server(s) Kluster Database Server(s) Kluster Integrationsplattformen (testmiljö) Integrationsplattformen (pre-prod) Integrationsplattformen (prod) - Anslutande system (testmiljö) Anslutande system (pre-prod) Anslutande system (prod) Testmiljö I integrationstestmiljön sker detaljerade tester med verifiering av levererade informationspaket, kvittenser och felsituationer Preproduktionsmiljö I preproduktionsmiljön testas produktuppgraderingar, konfigurationer och anpassningar i en så produktionslik miljö som möjligt. Här kan även stora asynkrona leveranser verifieras innan de skickas till produktionsmiljö Produktionsmiljö Hit skickas skarpa leveranser från anslutande verksamhetssystem eller interna leveranser som Stadsarkivet tidigare har mottagit från producerande system. Dessa leveranser skall ha verifierats antingen genom kontrollerade testleveranser i integrationstest och preproduktionsmiljö. 34 (35)