Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

PropertyBeskrivelse
kafka.consumer.bootstrap.serversKommasepareret liste af Kafka servere som NAS2 skal anvende. Denne liste bør indeholde alle noderne i Kafka clusteret
kafka.consumer.client.idNavnet som NAS2 vil fremgå med i listen af Consumers på et Kafka Cluster.
nsp.kafka.consumer.component.nameNavnet på NAS2 komponenten
nsp.kafka.consumer.component.abbreviationKort navn på NAS2 komponenten
nsp.kafka.consumer.component.versionVersionen af NAS2 komponenten
nsp.kafka.consumer.service.nameNavnet på den service i NAS2 der anvender Kafka
datasource.jndiJNDI navnet på den datasource der giver adgang til NAS2 databasen.
app.endpointService endpoint (anvendes i DKS servlet)
pullpoint.app.endpoint.regexRegex udtryk for service Service endpoint for pull point servicen. Anvendes til at validere korrekt format af pullpoint. F.eks.: https?://localhost:\\d{1,5}/pullpoint/service/
liquibase.changelog.fileAngiver hvilken changelog fil som liquibase skal anvendes. Property er ikke krævet. Hvis der skal afvikles integrationstest mod det miljø der installeres skal denne sættes til liquibase-changelog-test.xml. Denne kan også sættes via en environmentvariabel i formen liquibase_changelog_file.

...

Code Block
create_topic.sh basepath="localhost:8086NAS/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" internal_topicinternalTopic="dk.nsp.bo.nas.fmk.MedicineCard" num_partitionsnumPartitions=6 replication_factorreplicationFactor=2

Udover de ovenstående parametre er det desuden også muligt at sætte følgendekafka topic config parametre, hvis ønsket
segment_bytes
segment_ms
segment_jitter_ms 
segment_indexbytes
flush_messages_interval
flush_ms
retention_bytes
retention_ms
max_message_bytes
index_interval_bytes
file_delete_delay_ms
delete_retention_ms
min_compaction_lag_ms
min_cleanable_dirty_ratio
cleanup_policy
unclean_leader_election_enable
min_in_sync_replicas
compression_type
preallocate
message_format_version
message_timestamp_type
message_timestamp_difference_max_ms

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 CVR-RID, CVR-UID eller CVR-FID på formen: "CVR:XXXXXXXX-XID:XXXXXXXX".
Eksempler:

  • "CVR:46837428"
  • "CVR:46837428-FID:92421325"

(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: 

Code Block
languagesql
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:

Code Block
languagesql
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: 

Code Block
languagesql
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:

Code Block
delete_topic.sh basepath="NAS/administration" topic="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: 

Code Block
languagesql
topic_access.sh basepath="NAS/administration" 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 på følgende måde:Topic Access oprettes i på følgende måde: 

Code Block
languagesql
topic_access.sh basepath="localhost:8086NAS/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" operation="createdelete" identifier="CVR:46837428"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:

Code Block
languagesql
activate_deactivate_topic.sh basepath="localhost:8086/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. 

Æ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:Nedenstående sletter topic fra NAS databasen og i kafka: 

Code Block
languagesql
deletetopic_topicaccess.sh basepath="localhost:8086NAS/administration" topic="http://www.dkma.dk/medicinecard/xml.schema/2012/06/01:MedicineCard" 

Udvide antallet af partitioner

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:

Code Block
delete_topic.sh basepath="localhost:8086/administration" topic="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: 

Code Block
languagesql
topic_access.sh basepath=localhost:8086/administration 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 på følgende måde:

Code Block
languagesql
topic_access.sh  basepath=localhost:8086/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. 

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. 

Code Block
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.

...

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. 

Code Block
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.

HTTP/1.1 500 Internal Server Error
Connection: keep-alive
X-Powered-By: Undertow/1
Server: WildFly/8
Content-Type: application/json
Content-Length: 103
Date: Wed, 20 Feb 2019 13:30:11 GMT
 
 
{ "version": "1.0.0-SNAPSHOT", "database": "FAILED", "kafka streamer": "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:

LogningspunktKomponent

Eksempel på message fra applikationsloggen

(formatteret så det er lettere at læse i denne vejledning)

Der logges når der oprettes et PullPoint. Hertil medtages yderligere information, så som ejeren, evt. abonnement og URL, der er tilknyttet.

PullPointFactory

Service

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

Logning af alle forespørgsler til Pull Point service herunder antal af adviseringer, der medtages i svaret.

Der logges også om der var tale om replay (DGWS).

PullPoint

Service

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

Alle kald til Notification Broker skal ligeledes logges sådan at antal af adviseringer modtaget kan uddrages. Her vil topic også medtages.

NotificationBroker

Service

STATISTIK: {
"action":"notify",
"info":{
"quota":1,
"topic":"TESTNAS-TOPIC1"}}
Offsets statistik log logger information omkring subscription og offsets på subscription og offsets i Kafka.PullPoint service

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:

createPullPointinfo{pullPointId"98a3f337-4a65-45db-9001-2c9f0b69ff05" "ownerItSystem":"NAS2UnitTests" ownerCvr46837428"}}STATISTIK: {
"action":"getmessages"info{ pullPointId2acedce5c00a40bc8ddffe6de2a596a3",
"subscriptionIds":["a34c720f-9c26-4832-83d1-8671d4b6f7f3"],
"quota":2,
"replay":false}}STATISTIK: {
     "action":"notify",
     "info":{"No security headers found. Notification request is without DGWS protection"}
}
LogningspunktKomponent

Eksempel på message fra applikationsloggen

(formatteret så det er lettere at læse i denne vejledning)

Der logges når der oprettes et PullPoint. Hertil medtages yderligere information, så som ejeren, evt. abonnement og URL, der er tilknyttet.

PullPointFactory

Service

STATISTIK: {
"action":"
offsets",
"
owner":
["46837428NAS2UnitTests"],
"e
ndOffsets":["146","72","72"],
"
maxOffsetDelta":
["17"],
"pullPointId":["d43c793f-b29a-4d61-b9db-5970e2fc65f0"],
"
deltaOffsets":["

Logning af alle forespørgsler til Pull Point service herunder antal af adviseringer, der medtages i svaret.

Der logges også om der var tale om replay (DGWS).

PullPoint

Service

17","16","17"],
"
topic":
["topic"],
"
subscriptionId":["
d8274761-
4c27-
40d4-
bef3-

Alle kald til Notification Broker skal ligeledes logges sådan at antal af adviseringer modtaget kan uddrages. Her vil topic også medtages.

NotificationBroker

Service

STATISTIK: {
"action":"notify",
"info":{
"quota":1,
"topic":"TESTNAS-TOPIC1"}}
Offsets statistik log logger information omkring subscription og offsets på subscription og offsets i Kafka.PullPoint service
STATISTIK: {
"action":"offsets",
"owner":["46837428NAS2UnitTests"],
"e
ndOffsets":["146","72","72"],
"maxOffsetDelta":["17"],
"pullPointId":["d43c793f-b29a-4d61-b9db-5970e2fc65f0"],
"deltaOffsets":["17","16","17"],
"topic":["topic"],
"subscriptionId":["d8274761-4c27-40d4-bef3-31cec848f5a6"]
}

For alle kald til Notifikation Broker logges det om et request indeholder DGWS headers.
Dermed er muligt at overvåge dette i forbindelse med udfasningen af muligheden for at kalde uden.

NotificationBroker

Service

31cec848f5a6"]
}

For alle kald til Notifikation Broker logges det om et request indeholder DGWS headers.
Dermed er muligt at overvåge dette i forbindelse med udfasningen af muligheden for at kalde uden.

NotificationBroker

Service

STATISTIK: {
     "action":"notify",
     "info":{"No security headers found. Notification request is without DGWS protection"}
}

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:

Code Block
languagebash
curl -i http://localhost:8080/pullpointfactory/service/dks

Eksempel på output:

Code Block
languagexml
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. 

...