Indholdsfortegnelse

Snitflader

Applikationen opstiller forskellige snitflader, som er beskrevet nedenfor.

DKS

Snitfladen for at udstille DKS konfigurationen kan findes under:

https://localhost/dks

DKS snitfladen har support for brugen af HTTP header If-Modified-Since.

Status

Applikationen udstiller to forskellige status output på samme snitflade; en human readable i XML format, og en simpel som kan bruges til hyppige check af applikationens health.

Snitfladen for hyppige health checks:

https://localhost/status

Denne snitflade er i stand til at håndtere, at blive kaldt ofte. Hvis applikationen tror at den er oppe, returnerer den blot HTTP kode 200. Hvis servicen er nede, prøver den at lave et kald til en lignende snitflade hos backend servicen, og afhængig af hvad den svarer, sker forskellige ting. Hvis backend servicen svarer tilbage med HTTP kode 200, bliver den interne score resat til 0, og kaldet til applikationen vil returnere HTTP kode 200 selv. Hvis backend servicen ikke svarer, eller svarer med HTTP kode 500, så vil kaldet til applikationen selv returnere HTTP kode 500. Ved HTTP kode 500 kan applikationen ikke betragtes som værende brugbar.

Snitfladen for at få XML output findes her:

https://localhost/status?verbose

Snitfladen returnerer et simpelt XML format, som indeholder følgende information:

...

For begge disse outputs, hvis et forceCheck URL parameter tilføjes, tvinges applikationen til at teste om backenden er tilgængelig.

Modus operandi

Applikationen prøver så vidt muligt altid at give et fornuftigt svar. Kun i de tilfælde, hvor at applikationen ikke kan skrive et pænt svar til klienten, vil den give op og bare kaste en exception. Ved et kald til en snitflade der ikke eksisterer, vil den svare med HTTP kode 404.

Applikationens hovedfunktionalitet ligger under følgende HTTP POST på adresser:

http://localhost/v3/SOROpdateringService

Denne er en SOAP snitflad, og kan håndtere en af følgende SOAP operationer:

• For http://localhost/v3/SOROpdateringService:
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#CreateSorEntity
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#EditSorEntity
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#MoveSorEntity
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#ReplaceSorEntities
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#CloseSorEntity
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#EditEanLocationCodeSystemType
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#EditEanLocationCodeCommunicationSupplier
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#EditEanLocationCodeEdiAdministrator
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#EditEanLocationCodeRegion
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#EditEanLocationCodeSystemSupplier
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#MoveEanLocationCode
  • http://sundhedsdatastyrelsen.dk/SOROpdateringServiceV3#UpdateEdiTypes

Operationen bliver valgt med HTTP header SOAPAction. Hvis en anden operation end de listede er valgt, vil servicen returnere HTTP kode 405.

Alle operationer vil returnere et Status objekt som en del af svaret. Dette object indeholder altid to felter, ErrorCode og Message. Hvis ErrorCode er 0, så var kaldet en succes, ellers skete der en fejl i løbet af kaldet. Positive værdier er validerings fejl fra SOR's interne systemer, hvoraf mere tekniske fejl vil blive lavet som en SOAP fault. De nedenstående er hvilke denne applikation definerer:

...

1. Introduktion

Formål

Dette dokument er rettet mod systemadministratorer og driftspersoner, som skal kunne håndtere de driftsmæssige aspekter af komponenterne.
Driftsvejledningen indeholder information om hensyn til eksterne afhængigheder, placering af logfiler og konfigurationsfiler.

Sammenhæng med øvrige dokumenter

Dette dokument er en del af den samlede dokumentation for NAP Platformen.

Dokumentet er udformet, så det i videst muligt omfang opfylder sit formål uafhængigt af de øvrige dokumenter.

Ønskes mere information omkring arkitektur og design findes dette på NAP Platform - Design og Arkitektur beskrivelse.

Ønskes mere information omkring installationsvejledning til anvender kan findes på NAP Platform - Installationsvejledning.

Ønskes mere information omkring anvendelse kan dette findes på NAP Platform - Guide til anvendere.

Nap-administration

Nap-administration overskriver kontekstroden i jboss-web.xml og forventer derfor, at være udstillet på /admin. se eventuelt https://svn.nspop.dk/src/components/nap/nap-compose/trunk/haproxy/nap-haproxy.cfg for at se hvordan en ha-proxy konfigureres.

Service Snitflade

Servicen kalder en database med projekter og udstiller dem på en REST snitfalde.

Overvågningssnitflade

Login / logout (OIOSAML)

Konfiguration

Konfiguration af NAP-reference sker i filerne "compose/configuration" mappen som er beskrevet i NAP Platform - Installationsvejledning. I det følgende gennemgåes konfigurationsfilernes detaljer.

Følgende konfigurationsfiler skal være tilgængelige i classpath under deployment (loades fra applikationsserverens modules/dk/sds/nsp/nap/admin/main).

nap-lobby-ds.xml

Konfiguration af oiosaml sker i filerne "compose/configuration/oiosaml". 

Der findes en konfiguration til development / localhost-test1 / og test1 (test1 miljøet). 

De forskellige konfigurationer adskiller sig primært for singleLogoutService i SPMetadata og iDpMetadata samt og service provider url i oiosaml-sp.properties.

Oiosaml konfigurationerne skal ligeledes være tilgængelig i oiosaml.home under deployment (oiosaml.home sættes med JAVA_OPTS i compose filerne og er sat til /pack/oiosaml).

Hele oiosaml-konfigurations-mappen skal udskiftes til de forskellige miljøer. Så fx for localhost og test1 ser mapning således ud :

- ../configuration/oiosaml/localhost-development:/pack/oiosaml # localhost

- ../configuration/oiosaml/test1:/pack/oiosaml # test1

Database 

Adgang til nap-admin databasen styres gennem filen "nap-lobby-ds.xml" - Denne skal matche det NSP miljø hvor komponenten afvikles.

Da en nap- og projektadministratorer, skal kunne tilføje projekter, og database-brugeren skal kunne tilføje nye nap- og projektadminstratorer skal brugeren fx kunne skrive

insert into User (id, cpr, cvr, admin) values (UuidToBin(UUID()), '0501792275', '20921897', false);

For at tilføje nye projektadministrator.

Desuden forgår der også skrive operationer til samtlige tabeller for at oprette / opdatere / slette projekter og web-aps.

Derfor skal brugeren have read / write rettigheder.

Aktiviteter

For at NAP-admin kan deployes skal der være initieret en tabel i den database, der er defineret i nap-lobby-ds.xml, da hibernate vil tjekke at database schemaet matcher entiteterne i applikationen.

Følgende scripts skal derfor køres:

Logning

Alle logfiler er at finde i log/ under WildFly. Herunder findes en liste over alle logfiler med en beskrivelse af hvilke komponenter der skriver til dem. 

Fejlhåndtering

Applikationsfejl bliver logget ved hjælp af log4j, med type ERROR, INFO, DEBUG alt efter hvor alvorlig fejlen er. 

Nap-test-web

Hvordan fungerer servicen

Nap-test-web fungerer som test-suite til værtsystemer.

Den tester, at kommunikationen over broen fungerer som den skal, og der er således ingen konfiguration, opsætning eller logning.

Håndtering af fejlsituationer og logning

nap-test-web er en stateless webapplikation, og der er derfor ingen logning i denne komponent. Fejl vil dog blive skrevet ud i konsollen. I tilfælde af http fejl bliver klienten præsenteret med en fejl.

Logging

Log4j konfigurationen skal findes i log4j-napadmin.xml på classpath.

Ved default konfiguration skrives alle modul-relaterede fejl til nap-admin.log

Fejlhåndtering

Applikationsfejl bliver logget ved hjælp af log4j, med type ERROR, INFO, DEBUG, alt efter hvor alvorlig fejlen er. 

Nap-java-host

Er et dummy læge praksis system, som ikke kræver nogen drift

Andre fejlkoder kan forekomme, men disse kommer fra backenden, eller dens underliggende services.

Det skal pointeres, at MedCom's fault code kan findes under detail sektionen af den resulterende SOAP fault. Den påkrævede faultstring vil altid være "Server".

Logning

Applikationen bruger tre forskellige logs.

Audit log

Audit logning benytter audit API biblioteket, og skriver til audit.log i logs/ mappen. Følgende oplysninger bliver trukket ud af forespørgelsen og skrevet i audit loggen:

• Message ID
• SOAP operation
• Klient certifikatets common name
• Klient certifikatets organization
• Klient certifikatets CVR
• Klient certifikatets ID
• Klient certifikatets type
• Listen af roller listet i forespørgelsens User objekt
• Listen af entities listet i forespørgelsens User objekt

SLA log

SLA logning benytter nsp-util biblioteket, og skriver til nsputil-sla.log i logs/ mappen. Der bliver startet et nyt SLA log objekt på to forskellige tidspunkter; når en forespørgelse kommer ind til applikationen, og når applikationen skal lave en forespørgelse mod backend.

Ved forespørgelser til applikationen er der følgende ID'er:

...

Ved forespørge til backenden er der følgende ID'er:

...

Ved forespørge til whitelist databasen er der følgende ID'er:

...

Applikation log

Applikation loggen styres af log4j-sorus.properties, og denne afhænger af hvad der er blevet sat op. Det er muligt slet ikke at få en applikation log på disken, hvis dette ønskes (ikke anbefalet).

Typisk kun ved fejl, vil der blive skrevet i applikation loggen. Der kommer en kort fejl beskrivelse, og så stacktrace fra hvor fejlen skete.