NAS2 - Kontrol af husregler

Paragraf

Beskrivelse

Kontrolmetode

Acceptkriterie

 2

Designkrav

2.1.1

Komponenter skal kunne afvikles i platformens applikationsserver

Opstart af applikation iht. vejledning

Ingen fejl i WF Log

2.1.2

Komponenter skal udvikles i programmeringssproget Java passende til den aktuelle platformsversion af JDK.

Visuel samt byg af løsning

OK

2.1.3

Komponenter skal baseres på Java Servlet 3.0 specifikationen. Brug af yderligere JEE features så som EJB mv er ikke tilladt.

Visuel

OK

2.1.4

Applikationer må ikke benytte XA transaktioner mod databaseplatformen, da det ikke understøttes.

Visuel

OK

2.1.5

Opslag i stamdata bør så vidt muligt ske via et database view der defineres i samarbejde med NSP.

Visuel

OK

2.1.6

Adgang til Kafka skal ske gennem NSP Kafka Clients biblioteket.

Visuel

OK

2.2

Anvendelse af kodebiblioteker

2.2.1

Komponenter skal bruge de kodebiblioteker, som platformen stiller til rådighed. Derudover skal udviklingsprojektet levere de anvendte kodebiblioteker eller referere til disse i offentlig tilgængelige repositories.

Automatisk/

Visuel

OK

2.2.2

Komponenter skal stræbe efter at benytte de kodebiblioteker platformen udbyder og, så vidt muligt anvende de standard kodebiblioteker der leveres med  Wildfly platformen.

Automatisk/

Visuel

OK

2.2.3

Af hensyn til reproducerbarheden, så er det ikke muligt at referere til kodebiblioteker i repositories som er leveret/opstillet af komponentleverandøren.

Visuel

N/A

2.2.4

Komponenter skal, når der anvendes 3. parts kodebiblioteker, såvidt det er muligt, anvende nyeste version som stadig er under aktiv udvikling samt, (gennem udviklingsprojektet for 3. parts biblioteket, at have mulighed for at yde support til anvendere af dette 3. parts bibliotek.

Visuel / Automatisk

OK

2.2.5

Såfremt projekterne har behov for at anvende andre kodebiblioteker til løsningerne end dem der er godkendt, skal det ske efter aftale med NSP projektet.

Visuel / Automatisk

OK

2.3.2

Komponenter kan ikke regne med at, på hinanden følgende forespørgsler rammer samme NSP søjle (applikationsserver).

?

?

2.4.1

Statisk konfiguration skal være filbaseret.

Visuel

OK

2.4.2

Database opsætning bør ske vha. en Wildfly datasource descriptor og benyttes ud fra JNDI eller lignende tilgang.

Visuel

OK

2.4.3

Konfigurationer, hvor det skal være muligt at ændre efter opstart af komponenten, såsom f.eks. adgangskontrol, må ikke være filbaseret. Komponentdesignet må ikke basere sig på ændringer til platformen efter produktions-deployment. Konfiguration, der ønskes ændret herefter, skal ske gennem en anden mekanisme; f.eks. en database på NSP databasesystemet.

Automatisk/

Visuel

OK

2.4.4

Komponentkonfiguration skal placeres i højst en fil per service/delkomponent. Anden konfiguration såsom log eller database opsætning kan specificeres andetsteds.

Automatisk/

Visuel

OK

2.4.5

Det skal være muligt direkte at associere en kommentar til adgangskontrol-indgange.

Visuel

OK

2.4.6

Konfiguration af NSP Kafka Clients skal ske som beskrivet i Den Gode Brug af Kafka

Visuel

OK

2.5.1

Komponenter skal stille en simpel HTTP service til rådighed for load balanceren på platformen. Denne bruges til at afgøre om servicen på søjlen er aktiv. Servicen skal levere sin status som et simpelt ja/nej; hhv. HTTP status kode 200 eller 5xx. (Se http://www.ietf.org/rfc/rfc2616.txtafsnit 10).

Visuel

OK

2.5.2

Servicen skal kunne håndtere hyppige forespørgsler (cirka et hvert 10 sekund). Den må deslige ikke blokere på andre services uden for NSP platformen.

Performance test

OK

2.5.2

Et svar på 200 vil i loadbalanceren afgøre om forespørgelser kan routes til pågældende service. Det er derfor vigtig at alle afhængigheder, en service måtte have, indgår i dette svar. Dette skal ses i sammenhæng med paragraf 2.5.2.

?

?

2.5.3

Et svar på 200 vil i load-balanceren afgøre om forespørgsler kan routes til pågældende service. Det er derfor vigtig at alle afhængigheder, en service måtte have, indgår i dette svar. Dette skal ses i sammenhæng med paragraf 2.5.2.

Visuel / Funktionstest

OK

2.5.4

Det skal være muligt at udtrække en service version fra en HTTP snitflade.

Visuel / Funktionstest

OK

2.5.5

Udstillede HTTP monitorerings snitflader skal opfylde formatet defineret i sektion 3.1 i RFC822, ECMA-404 (JSON) eller XML 1.0

Visuel / Funktionstest

OK

2.5.6

Dokumentationen skal indeholde en beskrivelse af hvor monitorerings snitfladen kan findes samt hvilke andre snitflader, der måtte bruges i samme kontekst.

Visuel / Funktionstest

OK

2.6

Logning

2.6.1

Al logning på platformen skal være filbaseret. Logfiler centraliseres til en central log server af NSP infrastruktur services.

Visuel / Funktionstest

OK

2.6.2

Konfiguration af logningen skal ske gennem en log4j-kompatibel xml eller property-fil. Filen skal kunne ændres separat fra den binære komponent.

Visuel

OK

2.6.3

Logkonfiguration skal kunne specificeres individuelt per komponent. Dette forventes at fremgå af den leverede dokumentation.

Visuel

OK

2.6.4

Generelt skal logning overholde følgende:

- Logformat skal være tekstuelt og linje-baseret indeholdende en dato-tid for hver log-enhed.

- Anvendte dato-tid-format skal overholde ISO-8601.

- Logfilerne skal placeres i folderen log/ under Wildfly profilen.

- Rotation skal kunne konfigureres baseret på størrelse.

- Logfilerne skal ikke komprimeres.

Visuel / Funktionstest

OK

2.6.5

 Det foretrækkes at der logges i et format, som senere kan maskin-parses for at tilgodese log-inspektion på tværs af komponenterne samt, at dette så vidt muligt er dokumenteret.

Visuel

OK

2.6.6

Til logning, hvor kalderens IP logges, skal HTTP headeren X-Forwarded-For bruges såfremt den er sat.

Visuel / Funktionstest

OK

2.6.7

Komponenter, der kalder andre komponenter på platformen, skal sætte headeren, X-Forwarded-For, i det omfang det skønnes relevant for forespørgelsen.

Visuel / Funktionstest

OK

2.6.8

Enkelte komponenters services skal opsætte logpunkter, der reflekterer komponentens funktionalitet. Disse logpunkter dækker SLA-logning for en komponent.

Visuel / Funktionstest

OK

2.6.9

SLA-logning skal overholde et bestemt format, som pt. dikteres af biblioteket NSP-Util.

Visuel /

Funktionstest

OK

2.6.10

Til hvert logpunkt høres der en entydig identifikation. Denne skal afstemmes med NSP-projektet.

Visuel

OK

2.6.11

MessageId skal udfyldes ud fra modtagne DGWS forespørgelse såfremt det er muligt. Alternativt kan komponenten selv generere et, som skal være unikt.

Visuel /

Funktionstest

OK

2.6.12

Auditlog skal foretages gennem NSP Audit API-'et

Visuel / Test

OK

2.6.13

Komponenter skal anvende loglevels fornuftigt; der ses her på 4 inddelinger: DEBUG, som ikke bør være aktiveret i produktion, INFO, som anvendes til sparsom logning om relevant information, WARN, som bør anvendes til at gøre opmærksom på en uheldig situation og sidst, ERROR, som udelukkende skal bruges når der indtræffer en fejl, som menes skal behandles med aktiv indvirken af driften.

Visuel / Test

OK

2.6.14

Applikationslog må ikke indeholde personhenførbare oplysninger.

Visuel / Test

OK

2.6.15

Applikationsspecifikke logs skal dokumenteres i forhold til formål, placering og indhold. Logformater for nye komponenter skal være dokumenteret i forhold til deres forretningsmæssige indhold, herunder om et felt er obligatorisk eller valgfrit, og de mulige feltværdier.

Dokumentation/

Visuel

OK

2.7

Persistens

2.7.1

Komponenter kan ikke forvente at kunne anvende databasen på NSP noderne i scenarier med samtidig dataintegritet på tværs af søjler.

Test/

Visuel

OK

2.7.2

Komponenter skal levere opdateringsfunktionalitet til databaseskema såfremt data skal bevares ved opdatering.

Visuel

OK

2.7.3

Der tages ikke backup af databaserne på NSP noderne, kun på NSP Backoffice.

N/A

N/A

2.7.4

UTF8 skal anvendes som codepage med mindre andet er aftalt.

Visuel

OK

2.7.5

Brug af streaming platformen må kun ske gennem NSP Kafka Clients

Visuel

OK

2.7.6

Brug af streaming platformen kræver specifik aftale med NSP.

Test/

Visuel

OK

2.8

Komponentinteraktion

2.8.1

En komponents ressourcekrav skal være kendt og videre gives til NSP platformen.

Dokumentation/

Visuel

OK

2.8.2

Hvis en komponent kalder en anden service i systemet, skal det overvejes hvilke attributer der skal medsendes. Der skal etableres sporbarhed af både forespørgsel og klient, dvs. omtalte MessageId skal sættes og enten X-Forwarded-For eller X-NSI-Original-Client-IP skal sættes. (gl. 5.2.2). Oplysningerne skal logges i SLA-loggen for komponenten.

Visuel / Test

OK

2.9

Webservices

2.9.1

En udstillet webservice snitflade skal kunne håndtere forespørgelser med og uden BOM.

Visuel / Test

OK

2.9.2

 WSDL kontrakter samt tilhørende artefakter for udbudte services skal kunne hentes via HTTP. Dokumentationen skal tilmed angive placeringen heraf.

Dokumentation/

Visuel / Test

OK

2.9.3

Eksterne kald til webservices som udstilles på NSP platformen, skal altid kaldes gennem DCC (Decoupeling Component).

Dokumentation/

Visuel / Test

OK

2.10

2.10.1

En service, der udstilles gennem DCC, skal have en DKS snitflade. Dennes placering skal være dokumenteret.

Visuel / Test

OK

2.12

Fejlsvar

2.12.1

Fejlbeskeder skal være på dansk

Visuel / Test

OK

3

Krav til Udviklingsværktøjer og metode

3.1

Værktøjer

3.1.1

Apache Maven skal anvendes til byg af komponenter til NSP platformen.

Dokumentation/

Visuel / Test

OK

3.1.2

Generelle retningslinjer angående brug af Maven skal være overholdt.

Visuel

OK

3.1.3

Build scripts må ikke skulle ændres for at kunne bygge til NSP, dog kan parameterisering benyttes.

Test/

Visuel

OK

3.1.4

Leveret dokumentation skal beskrive anvendelse af de brugte værktøjer samt angive specifikke versioner deraf.

Dok./Visuel

OK

3.2

Nexus

3.2.1

Leverancer skal begrænse sig til at bruge projektets maven repository.

Test/

Visuel

OK

3.3

Byg

3.3.1

Komponenter skal kunne bygges, testes og afvikles på den af driftleverandøren leverede NSP. Byggeværktøjer må dog installeres, da disse ikke følger med og ikke vil være til stede i produktion.

Dokumentation/

Visuel

OK

3.4

Continuous Integration

3.4.1

Komponenter skal kunne bygges vha. en automatiseret proces. Afhængigheder skal enten kunne angives som en konfiguration til byggeprocessen eller komponentleverancen skal understøtte opløsning af disse uden intervention.

Dokumentation/

Visuel

OK

3.4.2

Bygge scripts skal være udformet således at byg af komponentleverancer er idempotent

Test / Visuel

OK

3.4.3

Unittest eller andre komponentspecifikke test skal være inkluderet i denne proces.

Test / Visuel

OK

4.

Krav til Testmetoder og værktøjer

4.1

Unit test - JUnit

4.1.1

Test af komponenter skal kunne udføres med , seneste version af JUnit (anbefalet).

Dokumentation/

Test

OK

4.2

Code Coverage

4.2.1

Code coverage målet er 80%. NSP Projektet kontrollere graden af code coverage ved modtagelse.

Test/ Visuel

OK

4.3

Performance Test - JMeter

4.3.1

Performance test af komponenter bør foretages med JMeter.

Test / Visuel

OK

5

Krav til leverancer og installation

5.1

Leverancer generelt

5.1.1

NSP projektet har til hensigt at offentliggøre kildekoden. Derfor skal hensyn desangående beskrives. Dette vil imødekommes på offentliggørelsestidspunktet.

N/A

N/A

5.2

Licens

5.2.1

Kildekoden skal være udstyret med MIT licens. Den eksakte ordlyd af denne kan erhverves hos SDS.

Visuel

OK

5.3

Subversion

5.3.1

Kildekode samt dokumentation skal leveres til et subversion repository på svn.nspop.dk

Visuel

OK

5.4

Tests

5.4.1

Den leverede dokumentation skal beskrive, hvordan de forskellige typer af tests skal udføres.

Visuel

OK

5.4.2

Leverancen skal indeholde unit tests, der bruges som ovenfor nævnt.

Visuel / Test

OK

5.4.3

Leverancen skal indeholde integrationstest, der bruges som ovenfor nævnt.

Visuel / Test

OK

5.4.4

En integrationstest skal kunne køres flere gange uden manuelle ændringer i konfiguration eller datagrundlag

Visuel / Test

OK

5.5

Installation

5.5.1

Komponenter har kun adgang til services udstillet på sundhedsdatanettet. Det skal specielt bemærkes, at der kun er begrænset adgang til certifikatinfrastrukturen: HTTP adgang til CRL og krydscertifikat er muligt på normal vis. Desuden udstilles RID/CPR tjenesten.

N/A

N/A

5.5.2

Der skal kunne opsættes timeouts på kald til eksterne services. Komponenter skal endvidere behandle timeout forventelig overfor klienten/klientsystemet.

Visuel

OK

5.6

Sagshåndtering

5.6.1

Henvendelser vedrørende forhold omkring releases, der ikke kan spores tilbage til en sag i JIRA, vil blive afvist

N/A

N/A

5.6.2

En sag i JIRA bør begrænses til at omhandlet én opgave. Dette gælder både når en sag startes og senere i forløbet.

N/A

N/A

6.

Krav til driftsmæssige forhold

6.1

Afhængigheder

6.1.1

Komponenter skal kunne starte op (deploye), selvom deres afhængigheder ikke er tilgængelige.

Test / Visuel

OK

6.1.2

Komponenter skal logge en ERROR eller WARN fejltype såfremt de driftsmæssige forudsætninger ikke er opfyldt

Test / Visuel

OK

6.1.3

Komponenter skal desuden være i stand til at genoprette deres tilstand, når afhængighederne igen er tilgængelige.

Test / Visuel

OK

7

Krav til dokumentation

7.1

Dokumentation af værktøjer

7.1.1

Leverede dokumentation skal beskrive anvendelse af de brugte værktøjer samt angive specifikke versioner deraf.

Test / Visual

Version OK

7.2

Test dokumentation

7.2.1

Den leverede dokumentation skal beskrive, hvordan de forskellige typer af tests skal udføres.

Visuel

OK

7.3

SLA logpunkter

7.3.1

Identifikationen samt beskrivelse af SLA-logpunkter skal indskrives i dokumentationen.

Visuel

OK

7.4

Ressourceforbrug

7.4.1

En komponents ressource krav skal fremgå af dokumentationen.

8

Krav til ændringer

N/A

N/A