...

Definitioner og referencer

...

Alle properties der starter med "kafka.producer." vil blive givet videre til NSP Kafka Clients API'et og derved videre til Kafka Clients. Det er derved muligt at konfigurere alle aspekter af Kafka klienten som måtte være ønsket, blot ved at tilføje nye properties. Hvis f.eks. Kafka konfigurationen "abc" skulle sætte til "42" så tilføjes blot linien "kafka.producer.abc=42".

...

log4j-idlist.xml

Denne fil indeholder en Log4J opsætning der følger gængs standard på NSP.

...

log4j-subscriptionmanager.xml

...

pullpointfactory.properties

log4j-pullpointfactory.xml

Denne fil indeholder en Log4J opsætning der følger gængs standard på NSP.

Pullpoint service

Denne service konfigureres i filerne "pullpoint.properties" og "log4j-pullpoint.xml"

pullpoint.properties

...

log4j-pullpoint.xml

Denne fil indeholder en Log4J opsætning der følger gængs standard på NSP.

...

Cleanup service

Denne service konfigureres i filerne "pullpointcleanup.properties" og "log4j-pullpointcleanup.xml"

...

cleanup.properties

log4j-cleanup.xml

Denne fil indeholder en Log4J opsætning der følger gængs standard på NSP.

Administration service

Denne service konfigureres i filerne "administration.properties" og "log4j-administration.xml"

cleanup.properties

log4j-

...

cleanup.xml

Denne fil indeholder en Log4J opsætning der følger gængs standard på NSP.

...

NAS2 skal anvender NSP Kafka Clusteret på NSP Backend miljøet. Der kræves ikke nogen særlig opsætning af Kafka i forhold til det eksisterende NSP Kafka Cluster.

...

Administration af topics i NAS2

I det følgende gennemgåes de manuelle aktiviteter der skal ske i databasen og i Kafka ifm driften af NAS2. 
Til at administrere topics og adgang til topics anvendes forskellige shell scripts, som kalder administrationsservicen i NAS2. I den forbindelse opdateres topics både i databasen og i kafka.

 Hent Topic

 Hent liste med alle Topics

get_topics.sh basepath="localhost:8086/administration"

 Hent specifikt topic med detaljer

get_topics.sh basepath="localhost:8086/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard"

Nyt Topic

For at NAS2 skal kunne modtage adviseringer på et Topic skal dette oprettes i Kafka og i databasen.
For at give tilladelse til at der kan oprettes abonnementer og afhentes adviseringer på et Topic, skal der desuden  oprettes et Topic Access i databasen. 

Opret Topic

Først oprettes Kafka Topic via følgende kommando, hvor topic er navnet på topic i databasen og internal_topic er  navnet på topic i kafka:

bin/kafka-topics.sh --create --bootstrap-server kafka-host:port --replication-factor 2 --partitions 15 --topic dk.nsp.nas.fmk.MedicineCard

create_topic.sh basepath="NAS/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" internalTopic="dk.nsp.bo.nas.fmk.MedicineCard" numPartitions=6 replicationFactor=2

Udover de ovenstående parametre er det også muligt at sætte kafka topic config parametre, hvis ønsket (fx cleanup.policy=delete).

Mulige kafka topic config parametre findes fx her: https://kafka.apache.org/documentation/#topicconfigs

Opret Topic Access

Efter oprettelse af et Topic, tildeles adgang ved at oprette Topic access. 

Topic Access oprettes med en identifier, der angiver adgangen til et specifikt topic. Identifier kan indeholde "ALL", et cvr-nummer på formen "CVR:XXXXXXXX", eller et Subject Serial Number (CVR-RID, CVR-UID CVR-FID, UUID).
Eksempler:

• "CVR:46837428"
• "CVR:46837428-FID:92421325"
• "UI:DK-O:G:23550132-5e1f-4e43-a5f9-048acf49e0b8"

Topic Access oprettes på følgende måde: 

topic_access.sh basepath="NAS/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" operation="create" identifier="ALL" comment="SDS-4393: topic access oprettet"

Lukke for et Topic

For at lukke for nye adviseringer til et Topic anvendes følgende shell script og parametre:

activate_deactivate_topic.sh basepath="NAS/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" activation="disable"

Slette et Topic

For at slette et topic bør det først være inaktivt i en periode således at der ikke kan afleveres nye data og modtagere kan nå at afhente alle deres adviseringer. Derefter skal nedenstående udføres. 

Nedenstående sletter topic fra NAS databasen og i kafka: Herefter mappes dette Kafka Topic til et WS-Notification Topic i databasen på følgende måde:

delete_topic.sh basepath="NAS/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" 

Hvis et topic har tilhørende subscriptions vil sletning fejle med ovenstående kommando. Hvis man ønsker at gennemtvinge sletning og dermed også slette tilhørende subscriptions anvendes parameteren 'force' som nedenstående viser:

delete_topic.sh basepath="NAS/administration" topic=INSERT INTO TopicMapping
	(topic, internal_topic)
VALUES
	("http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" force="true"

Ændre Topic Access

Hvis der skal ændres på hvem, der har lov til at tilgå et topic, skal det opdates i Topic Access. 

Tilføj en adgang til et Topic

Der kan tildeles adgange til et topic på cvr eller cvr-Xid. Der kan være flere adgange for et topic. For at give en ny tilladelse oprettes et nyt Topic Access på følgende måde: 

topic_access.sh basepath="NAS/administration" "dk.nsp.nas.fmk.MedicineCard");

Lukke for et Topic

topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" operation="create" identifier="CVR:46837428" comment="SDS-4393: ny tilladelse oprettet"

Slette en adgang til et Topic

Hvis en adgang til et Topic skal slettes, gøres det For at lukke for nye adviseringer til et Topic opdateres rækken i "TopicMapping" på følgende måde:

topic_access.sh basepath="NAS/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" operation="delete" identifier="CVR:46837428"

Ændre tilladelse fra 'ALL' til cvr eller cvr-Xid

Hvis et Topic skal ændres fra at være tilgængeligt for alle, er det vigtigt at Topic Access med identifier 'ALL' ikke længere findes i databasen. 

Dette sikres ved først at slette adgang for det specifikke Topic hvor identifier = 'ALL'.

Herefter tilføjes adgang for de ønskede CVR eller eller CVR-Xid. 

 Hent liste over adgange for et Topic

For at se hvilke identifiers der er tildelt adgang til et topic anvendes følgende script:

topic_access.sh basepath="NAS/administration" topicUPDATE TopicMapping SET active = false where topic ="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard";

Udvide antallet af partitioner

Hvis der opstår et behov i Kafka for at udvide antallet af partitioner for et Topic, skal der ikke foretages noget i NAS2 idet den selv opdager dette og tilpasser sig det nye antal.

Overvågning

Alle services i NAS udstiller en status side. På denne side fremgår servicens versionsnummer samt status for adgang til database og/eller Kafka. Status siden kan tilgås via http://NAS/SERVICE_NAME/health. SERVICE_NAME er pullpoint, pullpointfactory, idlist, notificationbroker, subscriptionmanager eller cleanup. Det svarer til de 6 services der er implementeret i NAS2.

Eksempel på svar på fra status-siden. 

HTTP/1.1 200 OK
Connection: keep-alive
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/json
Content-Length: 82
Date: Fri, 10 May 2019 08:06:26 GMT

{
	"version": "1.0.0-SNAPSHOT"
	,"database": "OK"
	,"kafka streamer": "OK"
}

HTTP statuskode

Status-siden returnerer følgende status koder afhængig af servicens status. 

200: Applikationen er sund

500: Der er opstået en fejl i applikationen eller en af de services der integreres med.

Fejlfinding

Såfremt der er problemer med adgang til servicens database, vises nedenstående fejl. Bemærk at den giver en HTTP statuskode 500, og at man i body kan se, at det er NAS servicen der ikke er OK.

Følgende årsager kan resultere i en statuskode 500. 

• Hvis database eller Kafka ikke er tilgængelig. 
• Andre ukendte årsager

Hvis status-siden returnerer HTTP status 500 bør man tjekke applikationsloggen, da fejl logges her til. 

Servicen kan genstartes ved at genstarte den docker container, som servicen den kører i. 

Cleanup Service Status

Statussiden for Cleanup servicen indeholder tidspunkt for seneste cleanup, status for seneste clean up og beskrivelse af eventuel fejl. 

Bemærk at statusoplysninger fra Cleanup servicen gemmes i memory og præsenterer derfor udelukkende status for den kaldte instans af servicen. Hvis det seneste oprydningsjob er udført på en anden instans af servicen, vil dette derfor ikke reflekteres i den returnerede statusside. 

Statistiklogning

Som en del af den almindelige applikationslog foretages en række logninger særligt beregnet til udtræk til statistik og ledelsesinformation.

Følgende logningspunkter til statistik er defineret:

STATISTIK: {
  "action":"createPullPoint",
  "info":{
    "pullPointId":"98a3f337-4a65-45db-9001-2c9f0b69ff05",
    "ownerItSystem":"NAS2UnitTests",
    "ownerCvr":"46837428"}}

STATISTIK: {
  "action":"getmessages",
  "info":{
    "pullPointId":"2acedce5-c00a-40bc-8ddf-fe6de2a596a3",
    "subscriptionIds":["a34c720f-9c26-4832-83d1-8671d4b6f7f3"],
    "quota":2,
    "replay":false}}

STATISTIK: {
  "action":"notify",
  "info":{
    "quota":1,
    "topic":"TESTNAS-TOPIC1"}}

STATISTIK: {
  "action":"offsets",
  "owner":["46837428NAS2UnitTests"],
  "endOffsets":["146","72","72"],
  "maxOffsetDelta":["17"],
  "pullPointId":["d43c793f-b29a-4d61-b9db-5970e2fc65f0"],
  "deltaOffsets":["17","16","17"],
  "topic":["topic"],
  "subscriptionId":["d8274761-4c27-40d4-bef3-31cec848f5a6"]
}

DKS-snitflader

Relevante services udstiller deres DKS-snitflade på endpointet "/dks".  I skrivende stund findes følgende:

• <serverurl>/idlist/service/dks

• <serverurl>/subscriptionmanager/service/dks

• <serverurl>/pullpointfactory/service/dks

• <serverurl>/pullpoint/service/dks

Test af DKS

Efter konfiguration og deployment af NAS2, kan en given DKS-snitfladen testes i stil med følgende:

curl -i http://localhost:8080/pullpointfactory/service/dks

Eksempel på output:

HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: text/xml;charset=UTF-8
Date: Thu, 18 Jan 2024 09:28:28 GMT

<?xml version="1.0"?><root xmlns="http://nspop.dk/2014/04" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://nspop.dk/2014/04 dks.xsd">    <dksVersion>1</dksVersion>    <timestamp>2024-01-18T09:25:06+01:00</timestamp>    <name>pullpointfactory</name>    <endpoint>http://localhost:8080/pullpointfactory/service</endpoint>    <operations>    <action name="http://docs.oasis-open.org/wsn/bw-2/CreatePullPoint/CreatePullPointRequest"><model>synchronous_timeout</model><timeoutMillis>120000</timeoutMillis><idCardLevel>VOCES</idCardLevel></action>    </operations></root>

Oprydning

Der kan foretages oprydning af abonnementer og nasconsumers i databasen.
Der konfigureres hvor gamle abonnementer må være – se tidligere – og så sker oprydningen når oprydningsservicen kaldes.
Nasconsumers fjernes i batches af 20. 

Kald laves på følgende URL: http://NAS/cleanup/start (et simpelt GET request er tilstrækkeligt). Svaret for kaldet vil være 200 medmindre der er gået noget galt. Derudover svares der med hvor mange henholdsvis abonnementer og nasconsumers, der er blevet fjernet.

Statussiden for cleanup servicen: http://NAS/cleanup/status viser status for seneste oprydningsjob på instansten, og her bemærkes at status gemmes i memory og ikke representere status på tværs af instanser. 

Persistere offsets for tilbagespoling af subscription

Subscriptionmanager servicen udstiller en service til at persistere offsets for alle topics. Disse data kan bruges til at spole en subscription tilbage til et givent tidspunkt. Servicen skal kaldes med regulære mellemrum. og kan tilgås på føglende URL: http://nas/subscriptionmanager/saveOffsets. Hvis kaldet går godt returneres der HTTP 200 med nedenstående body.

{"rowsDeleted":0,"rowsInserted":6}

Databasen

Database modellen er beskrevet i i NAS2 - Design og Arkitektur dokumentet (LINK MANGLER)arktitekturbeskrivelse.