11. april 2018 Compliance-test, STS Sags- og Dokument indekset Version 1.0 75 Side 1/13
1. Ændringshistorik Dato Version Foretaget af Ændringsbeskrivelse 28-01-2019 0.1 CWM Dokument oprettet. 06-03-2019 0.2 CWM Ændringer efter intern review. 07-03-2019 1.0 CWM Version 1 klar til udstilling og anvendelse 75 Side 2/13
1. Ændringshistorik... 2 2. Indledning... 4 2.1 Baggrund... 4 3. Compliancetest... 5 3.1 Forudsætninger:... 5 3.1.1 Dokumentation... 5 3.1.2 Mapning af fagsystems data... 6 3.1.3 Indgåelse af Serviceaftale... 6 3.1.4 Etablering af teknisk integration... 7 3.1.5 Tilslutning til STS Organisation og STS Klassifikation... 7 3.2 Gennemførelse... 7 3.2.1 Testforløb... 8 3.2.2 Forberedelse... 8 3.2.3 Gennemførelse af tests og godkendelse... 8 4. Teknisk hjælp til testen... 9 4.1 Kodeeksempler... 9 4.2 SAPA prototype... 9 SAPA-P er et prototypemiljø, som giver kommunerne og deres leverandører mulighed for at se ned i samspillet mellem leverandørens løsning og den fælleskommunale infrastruktur i KOMBITs eksterne testmiljø, inden løsningen sættes i produktion.... 9 5. Testscenarier... 10 Initialisering og genload: Testcase der sikrer håndtering af masseimport til Sags- og dokumentindeks. Efterfølgende sletning sikrer at data fjernes igen på et fornuftigt måde.... 10 5.1 Forretningsbaserede testcases... 10 5.2 Fejlhåndtering... 12 5.3 Datavarians validering... 12 5.4 Initialisering og Gen-load... 12 5.5 Store sager... 12 5.6 End-to-end tests med SAPA-P og pilotkunde... 13 75 Side 3/13
2. Indledning Dette dokument beskriver compliance-testforløb for anvendere af STS Sags- og Dokument indeks, som skal gennemføres forud for ibrugtagning i et produktionsmiljø. Formålet er, at give kommuner og leverandører den fornødne forståelse og tryghed i behandlingen af data der importeres og eksporteres til indeksene. Et Kombit compliance testforløb sigter primært på at serviceanvendere har den rigtige forretningsmæssige forståelse af udstillede services, og dermed sikre korrekt behandling af data. Leverandører af løsninger som anvender services udstillet af Kombit kan bruge compliance testforløbet til at demonstrere overfor deres kunder, at de overholder forretningsregler og andre funktionelle og nonfunktionelle krav, ved at gennemføre et compliance testforløb. Leverandører kan efter succesfuld gennemførelse af compliance forløbet angive i oplysnings- og salgsmateriale i hvilket omfang de understøtter STS Sags- og Dokument indekset. Kommuner og andre offentlige myndigheder kan derved nemmere træffe beslutning om en eventuel anskaffelse, hvor der er behov for integration til STS Sags- og DokumentIndeket. Testen udføres af anvenderen (typisk en leverandør) i samarbejde med kunden (typisk en kommune, UDK eller KOMBIT). Gennemførsel af en compliancetest, der dækker testscopet i nærværende dokument, er et vilkår for adgang til STS Sags- og Dokumentindekset i produktion. I det følgende gennemgås krav til opsætning, testdata og gennemførelse af compliancetest for STS Sags- og Dokumentindeks. 2.1 Baggrund Baggrunden for compliancetesten er KOMBITs ønske om at sikre en ensartet forståelse og anvendelse af STS Sags- og Dokumentindekset på tværs af kommuner og leverandører. STS Sags- og Dokumentindekset fungerer som en port til dataudveksling imellem et eller flere fagsystemer, ESDH leverandører og borgernære informations systemer. Compliancetesten er lavet for at sikre et fælles datagrundlag ( sprog ) for leverandører og anvendere som skal læse eller skrive til indeksene. 75 Side 4/13
3. Compliancetest 3.1 Forudsætninger: Der er en række forberedelsesøvelser som skal gennemføres før der kan opnås adgang til STS Sag- og Dokumentindeks. Det drejer sig i listet form om følgende: Læsning af relevant dokumentation. Mapning af fagsystemets data til STS Sags- og Dokumentindeksets datamodel. Indgåelse af serviceaftale. Implementering af de tekniske beskrivelser af snitfladen for STS Sags- og Dokumentindekset. Tilslutning til STS Organisation og STS Klassifikation. Samtlige punkter er beskrevet i de kommende underpunkter for at give en samlet gennemgang af de stand-alone delprocesser som skal gennemføres for at kunne gennemføre compliance forløbet. 3.1.1 Dokumentation Før tilslutning skal følgende dokumentation som minimum læses: STS Integrationsbeskrivelser som findes i bilags mappen under snitflade SF1470 her. Integrationsbeskrivelserne indeholder foruden vilkår for integration til støttesystemerne STS Sags- og Dokumentindekset og begrebs og informationsmodeller også beskrivelser af de enkelte operationer i webservicen. Anvisninger Anvisningerne til støttesystemerne findes her og er en præcisering til ovenstående integrationsbeskrivelser. Anvisningerne indeholder definitioner af data elementerne for Sags- og Dokument objektet i STS Sags- og Dokumentindekset og anvisninger til, hvorledes de skal udfyldes af anvendersystemerne. Klassifikationer Klassifikationer anvendes i STS Sags- og Dokumentindekset både som angivelse af egentlige klassifikationer såsom KLE, men de anvendes også i form af værdilister på attributter og som henvisning til objekttyper og relationsroller. Klassifikationerne findes her 75 Side 5/13
3.1.2 Mapning af fagsystems data Som en del af forberedelsen til anvendelse af Sags- og Dokumetindekset kræves det at leverandøren, i sammenarbejde med kommunen, har taget stilling til hvordan fagsystems data modelleres ind i indeksene. For at hjælpe leverandørerne på vej udstiller KOMBIT en mapningsdokument skabelon for Sag- og Dokumentindekset. Skabelonen tager udgangspunkt i skabelonen for anvisnings dokumenterne og beskriver samtlige felter i Sags- og Dokument indekset og det angives, hvilke elementer der er obligatoriske, samt definitionen og datatypen af disse. Yderligere to felter er beregnet til at anvender kan udfylde med det korresponderende felt fra fagsystemet, samt angive evt. bemærkninger eller opmærksomhedspunkter. Formålet er at give anvendere mulighed for, at identificere datafelter i de respektive fagsystemer til felter i STS Sags- og Dokument indekset. Dokumentet er tænkt udarbejdet i samarbejde med anvenders kunder, og på den måde, dokumentere hvordan kundens data i fagsystemet repræsenteres i de fælleskommunale indekser. Dokumentet vil dermed også finde anvendelse som dokumentation og opslagsværk, når kundens andre kunder skal læse og fortolke anvenders data i indekserne. Der findes et mapningsdokument for hvert af følgende objekter Dokumentobjektet Økonomisk Effektueringsobjektet Sagsobjektet Ydelsesobjektet Der er kun krav om udfyldelse af de objekter hvis indeks man skal tilgå. Mapningdokumenterne til Sags-og DokumentIndekset findes samlet her. 3.1.3 Indgåelse af Serviceaftale Rettighedsstyring for systemer: For at lave kunne tilgå STS Sags- og Dokumentindeks med et IT-system, skal der først indgås serviceaftaler som giver adgang. Det kan der anmodes om via STS Administrationsmodulet. Processen for at få adgang til Administrationsmodulet og til at anmode om aftaler er beskrevet i: Brugervejledning til Administrationsmodulet for leverandører 75 Side 6/13
Når der er anmodet om en serviceaftale, skal kommunen godkende anmodningen før der opnås adgang til servicen. Beskrivelse af kommunens processer for at få adgang til, og at benytte STS administrationsmodulet er beskrevet her: Brugervejledning til Administrationsmodulet for myndigheder Når serviceaftalen er godkendt af den kommunale aftalegodkender, så har IT systemet adgang til den pågældende kommunes data i STS Sag- og Dokument Indeks. 3.1.4 Etablering af teknisk integration Integrationsbeskrivelserne med relevante informationer er at finde under SF1470 (STS Sags- og Dokumentindeks) på KDI ShareKomm site her: Integrationsbeskrivelser. Den tekniske dokumentation for integrations via Serviceplatformen er at finde i mappen Tekniske bilag under SF1470 (STS Sags- og Dokumentindeks) på KDI ShareKomm site her: Integrationsbeskrivelser. Følg integrationsbeskrivelsen og de tekniske bilag nøje for at finde frem til alle de relevante informationer om WSDL, XSD filer, endpoints, logik og konfiguration/opsætninger. 3.1.5 Tilslutning til STS Organisation og STS Klassifikation Oprettelse af sager og dokumenter i STS Sags- og Dokumentindeks kræver oplysninger om blandt andet ejerforhold og tilhørssted i Organisationen. Disse oplysninger til at berige sag og dokument data findes tilgængelig i STS Organisation, hvorfor en tilslutning til STS Organisation er nødvendig. Opmærkning af sagers attributter og angivelse af klassifikationer er på samme måde angivet i STS Klassifikation, hvorfor en tilslutning til STS Klassifikation stærkt anbefales for at anvende STS Sags- og Dokumentindeks. 3.2 Gennemførelse Overordnet set består compliancetesten af tre faser: 1. Forberedelse 2. Gennemførelse af tests 3. Godkendelse 75 Side 7/13
I forberedelsesfasen gennemføres de trin som er forudsætninger for at testen må eksekveres. Nedenfor gennemgås testforløbet, sådan som det tager sig ud i de enkelte steps. 3.2.1 Testforløb Forberedelse Test 1-X Godkendelse 3.2.2 Forberedelse Figur 1: Testforløb for compliancetest Inden selve testen kan påbegyndes, er det som tidligere nævnt nødvendigt at læse alt relevant dokumentation for tilslutning til STS Sags- og Dokumentindekset som beskrevet i afsnit 3.1.1. Dernæst foretages mapningen af fagsystemets data til indeksene som beskrevet i afsnit 3.1.2 Ligeledes skal det sikres at man har den nødvendige adgang til at hente data fra STS Organisation. Dels for at 3.2.3 Gennemførelse af tests og godkendelse Efterfølgende eksekveres testscenarierne i afsnit 4 via SF1470. Når testscenarierne er gennemført tilfredsstillende angives dette pr. mail til KOMBIT, ved udfyldelse af rapporteringsskabelonen. Dette sker via kdi@kombit.dk med emnet Compliancetest STS Sags- og Dokument Indeks [Anvendersystemnavn], hvor Anvendersystemnavnet skal svare til det navn som systemet har indgået aftale om anvendelse af SF1470 på. 75 Side 8/13
4. Teknisk hjælp til testen 4.1 Kodeeksempler Som hjælp til udviklere har vi fremstillet eksempel XML på hovedelementerne af de operationer som skal benyttes i testen. Hjælpe koden består af et udfyldt XML eksempel på et kald, samt en beskrivelse/hjælpetekst til udfyldelse. Kodeeksempler og beskrivelser kan findes i en samlet mappe her 4.2 SAPA prototype SAPA-P er et prototypemiljø, som giver kommunerne og deres leverandører mulighed for at se ned i samspillet mellem leverandørens løsning og den fælleskommunale infrastruktur i KOMBITs eksterne testmiljø, inden løsningen sættes i produktion. For information om tilslutning og brug af SAPA-P henvises til følgende produktblad. 75 Side 9/13
5. Testscenarier I det følgende gennemgås samtlige test scenarier som tilsammen udgør compliancetesten til STS Sags- og Dokumentindeks. Bemærk at det er op til leverandøren selv at oprette de nødvendige testdata til gennemførelse af testen. KOMBIT lever ikke testdata, da forretningsbehovet varierer fra fagsystem til fagsystem. Opgaven med at generere testdata ligger derfor bedre hos anvender/leverandøren selv, i forhold til at tilpasse testdata til det enkelte fagsystems specifikke behov. Casene er bygget op omkring 6 forskellige områder. Forretningsbaserede testcases: Dækker over de mest gængse operationer i webservicen importer, opdater, fremsøg og fjern. Indeholder totalt: 13 cases, som ved udførelse gør leverandøren i stand til at fortage standard kald til STS Sags- og Dokument indekset. Fejl håndtering: Testcase(s) der skal sikre at leverandøren taget aktiv stilling til fejlhåndtering ved fejlkald til STS Sags- og Dokumentindekset. Datavarians: Testcase der importerer samtlige mulige felter i indeksene. En efterfølgende udlæsning sikrer at data er importeret korrekt. Initialisering og genload: Testcase der sikrer håndtering af masseimport til Sags- og dokumentindeks. Efterfølgende sletning sikrer at data fjernes igen på et fornuftigt måde. Store sager: Casen giver leverandøren kan håndtere store sags objekter på en fornuftig måde i forhold til en indlæsning. Kontrol af data via SAPA Prototype: Casen giver leverandøren og deres samarbejdes kommune, mulighed for I fællesskab at verificere at data er korrekt udfyldt og ligger som forventet i STS Sags- og Dokumentindekset. 5.1 Forretningsbaserede testcases ID Testcase Beskrivelse Verifikation Forretningsbaserede testcases TC1 Importer sag Hvis sag allerede eksisterer, så husk at fjerne den først. Gem oprindelige Importer XML Importer sag udelukkende med de obligatoriske felter 75 Side 10/13
TC2 Fremsøg sag Fremsøg sagen oprettet under TC1 Sammenlign fremsøg XML en med den omprindelige Importer XML TC3 Opdater sag tilføj en part, en sagsaktør, og beskrivelse Forsæt på sagen oprettet under i TC1 Opdater sagen med en ny sagspart, sagsaktør af typen primær behandler, en beskrivelse Gem opdater XML Fremsøg sagen og verificer at part er tilføjet TC4 Opdater sag tilføj journalnotat Forsæt på sagen oprettet under i TC1 Opdater sagen med journalpost af typen journalnotat Fremsøg sagen og verificer at journalnotatet er tilføjet og at indholdet er korrekt efter Base64 dekoding. TC5 Opdater sag Skift primær behandler Forsæt på sagen oprettet under i TC1 Fjern eksisterende sagsaktør af typen primær behandler ved at sætte tiltidspunkt på virkning til nu. Fremsøg sagen, evt. ud fra hvad der har virkning nu, og verificer at sagsaktøen af primær behandler er skiftet. Tilføj ny primær behandler TC6 Opdater sag tilføj sagshenvisning Forsæt på sagen oprettet under i TC1 Fremsøg sagen, verificer at sagshenvisng er tilføjet Opdater sag med sagshenvisning til anden sag af typen oversag (opfind UUID på anden sag) TC7 TC8 TC9 Opdater sag skift fremdriftstatus til afsluttet Importer dokument til dokumentindekset Opdater sag tilføj dokumentrelation TC10 Opdater dokument tilføj dokumentaktør Forsæt på sagen oprettet under i TC1 Opdater fremdriftstatus til Afsluttet Opdater sagsstatus med lokal sagsstuatus Hvis dokumentet allerede findes, så husk af fjerne det først. Importer dokument udelukkende med obligatoriske felter Forsæt på sagen oprettet under i TC1 Opdater sag med journalpost af type Tilakteret med typen Dokument med UUID på dokumentet fra TC7 Forsæt på dokumentet oprettet under TC7 Opdater dokumentet med ny sagsaktør af typen primær behandler genanvend evt. primær behandler fra TC4 Fremsøg sagen, verificer at fremdriftstatus er afsluttet, at sagsstatus er identiske med anvenders lokale sagsstatus. Fremsøg dokument, og verificer at XML svarer til det forventede Fremsøg sagen, se at dokumentet er tilføjet Fremsøg dokumentet og se at primær behandler er tilføjet TC11 Fjern dokument Opdater sag fra TC1 og fjerne journalpost relation ved at sætte tiltidspunkt til nu. Fremsøg sager verificer at dokument ikke er tilknyttet andre sager Fremsøg sag, tjek af jorunalpost er fjernet Fremsøg dokument, verificer at dokument ikke findes. Fjern dokument TC12 Fjern sag Fjern sagen Fremsøg sagen, og verificer at STS giver korrekt returkode Sag findes ikke 75 Side 11/13
TC13 Importer sag og flere dokumenter Fjern alt via kaskadeslet Importer sag Importer 3-4 dokumenter Opdater sag med journalpost relation til dokumenter Fjern sag via kaskadeslet Fremsøg og verificer at alle dokumenter er fjernet via kaskadeslet 5.2 Fejlhåndtering Testcases til fejlhåndtering TC30 Importer sag uden itsystem master Importer sag uden relation til it-system af typen Master Verificer at der modtages fejlkode 48 5.3 Datavarians validering Testcases til datavarians validering TC40 Importer sag med alle elementer fra mapningsdokument Importer sag, hvor alle informationselementer fra anvendes mapningsdokument er inkluderet Verificer af importer går godt Fremsøg sag Verificer af alle elementer er til stede som forventet 5.4 Initialisering og Gen-load Testcases vedr. initialisering og gen-load TC50 Start initialisering Opret 100 forskellige sager og 100 forskellige dokumenter. Initaliser kunden ved at oploade alle sager og dokumenter til indeksene TC51 Fjern alle kundens sager og dokumenter Igangsæt nedlukning af kunden, ved at fjerne alle sager og dokumenter fra indeksene Fremsøg og verificer at antal passer. Fremsøg og verficer at alle sager og dokumenter er væk. 5.5 Store sager Testcases store sager TC60 Verificer opdeling af kald i maks 10 MB Generer en stor sag, f.eks. med mange journalnotater, så XML før afsendelse af større en 10 MB Fremsøg sagen, verificer at alle data på sagen er registreret Verificer af programmel opdeler operationen i en importer, + X antal opdater 75 Side 12/13
5.6 End-to-end tests med SAPA-P og pilotkunde Forberedelse: - Leverandøren og pilotkunden skal aftale hvilke organisationsenheder, KLE numre og følsomhedsniveauer der anvendes til testen - Pilotkunden skal oprette forskellige jobfunktionsroller og tilknytte disse forskellige testbrugere. Jobfunktionsrollerne (JFR) skal opbygges med forskellige dataafgrænsninger, således det kan verificeres at sager og dokumenter, afgrænses korrekt som forventet ift. Leverandørens løsning. o o o F.eks. en JFR den kun kan se sager tilknyttet Enhed-A, og ikke Enhed- B En JFR der kun kan se sager for KLE-området 32.00.00 og tilknyttet Enhed-A Osv. Således at de forskellige udfaldsrum er dækket ind. End-to-End tests TC70 Importer en række sager og dokumenter verificer fra SAPA-P Importer sager og dokumenter til SD-Indekset opmærket med de aftalte KLE numre, følsomhedsniveauer samt tilknyttet de forskellige aftalte organisationsenheder Leverandøren og kunden fremsøger via SAPA-P, de forskellige sager, logget ind som de forskellige brugere. Verificer at de forskellige afgræsninger håndhæves som forventet, og brugerne kun kan se det forventede. TC71 Verificer tilstedeværelsen af sagsdata Arbejde evt. videre på sagerne importeret ved TC70 Verificer at de sags- og dokumentdata ser korrekt ud, ift. Hvordan sagen ser ud i kildesystemet Bemærk dog at SAPA ikke viser alle data. 75 Side 13/13