Page History

Versions Compared

Key

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

Navitabs

root	Behandlingsrelationsservice (BRS) - Leverancebeskrivelse
includeroot	true

...

Gliffy Diagram

displayName	Overblik
name	Overblik
pagePin	45

Anchor

	docs-internal-guid-796e5297-b24e-4ee0-b5
	docs-internal-guid-796e5297-b24e-4ee0-b5

...

Kaldet vil returnere 200 OK hvis alt går godt, ellers 500 Internal Server Error.

...

Konfiguration af Oprydningsjob

Servicens job til oprydning bliver afviklet vha. en udstillet RestController, som kaldes vha. simpelt HTTP GET kald.
Dette gøres for at sikre afviklingen af jobbet i fler-node drift, hvor en loadbalancer sørger for fordeling af kald til bagvedliggende servere.

Driften vedligeholder en cron, som kalder jobbets url i et fast mønster vha. curl.

Kommando til kald af oprydningsjob:

curl <server>/brs-backend/notificationcleanupjob

Kaldet vil returnere 200 OK hvis alt går godt, ellers 500 Internal Server Error.

Anchor
_Toc477260963
_Toc477260963
Tilføjelse af CVR-numre og typer

Tilføjelse af CVR numre og typer på NSP'erne foregår i MySQL i tabellen whitelist_config i databasen register_notification. Når en ny af disse tilføjes replikeres opsætningen ud til de øvrige NSP'er automatisk. Der kræves ingen opdatering af brs-frontend/brs-backend.properties i den forbindelse.

Duplikering af data for CVR-nummer ifm. certifikatskift

I forbindelse med udskiftning af et anvendercertifikat kan det være nødvendigt at duplikere data for et CVR-nummer, som beskrevet i anvenderguiden, afsnit 2.5. Hvis der er behov for dette, køres nedenstående SQL-script.

Inden scriptet køres, justeres variablerne old_cvr og new_cvr.

Code Block

title	Duplikering af data for CVR-nummer
collapse	true

set @old_cvr = '46837428';
set @new_cvr = '12345678';

use followup;

begin;

-- Duplicate from BRS2_TreatmentRelationFollowup
insert into BRS2_TreatmentRelationFollowup (
    nextCheck,
    queryableCvr,
    externalReferenceId,
    uid,

Duplikering af data for CVR-nummer ifm. certifikatskift

BEMÆRK!!! SQL-scriptet udvikles ifm. JIRA-sag SDS-4039, og er d.d. under Q/A. Når denne sag er afsluttet, indsættes scriptet nedenfor.

Inden scriptet køres, justeres variablerne old_cvr og new_cvr.

Code Block

title	Duplikering af data for CVR-nummer
collapse	true

set @old_cvr = '46837428';
set @new_cvr = '12345678';

use followup;

begin;

-- Duplicate from BRS2_TreatmentRelationFollowup
insert into BRS2_TreatmentRelationFollowup (
    nextCheck,
    queryableCvr,
    externalReferenceId,
    uid,
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    created,
    sor
)
select
    nextCheck,
    @new_cvr, -- the new cvr
    externalReferenceId,
    uuid(), -- new uid
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    created,
    sor
from
    BRS2_TreatmentRelationFollowup
where
    queryableCvr = @old_cvr;

-- Duplicate from BRS2_Followup
-- We need a relation between old and new serial numbers later on, when duplicating into the BRS2_Notification table, as that table refers into BRS2_Followup through the followupSerialNumber-column.
-- We achieve this by creating a temp table of the followups that need to be duplicated, and generate fresh uid's there. The contents of the temp table are then inserted into BRS2_Followup. This allows us to relate serial numbers through the chain <old serial> <-> <old uid> <-> <new uid> <-> <new serial>.

-- Create the temp table
create temporary table BRS2_Followup_tmp select * from BRS2_Followup where queryableCvr = @old_cvr;
alter table BRS2_Followup_tmp add column newUid varchar(36);
update BRS2_Followup_tmp set newUid = uuid();

-- Insert into into BRS2_Followup (from the temp table)
insert into BRS2_Followup (
    queryableCvr,
    externalReferenceId,
    uid, -- The uid we just generated. 
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    created,
    errorCount,
    nextSync,
    sor
)
select
    @new_cvr, -- the new cvr
    externalReferenceId,
    newUid, -- The new uid we just generated
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    created,
    errorCount,
    nextSync,
    sor
from
    BRS2_Followup_tmp;

commit;

use register_notifications;

begin;

-- Duplicate from BRS2_TreatmentRelationFollowup
insert into BRS2_Notification (
    externalReferenceId,
    queryableCvr,
    creationTimestamp,
    doctorOrganisation,
    hospitalOrganisation,
    ean,
    patientCpr,
    healthProfessionalCpr,
    relationLookupStart,
    relationLookupEnd,
    timeLimit,
    acceptableRelations,
    actualRelations,
    followupSerialNumber,
    followupRelations,
    authorisationIdentifier,
    serviceProviderName,
    serviceProviderVersion,
    serviceProviderVendor,
    uid,
    sor
)
select
    n.externalReferenceId,
    @new_cvr,
    n.creationTimestamp,
    n.doctorOrganisation,
    n.hospitalOrganisation,
    n.ean,
    n.patientCpr,
    n.healthProfessionalCpr,
    n.relationLookupStart,
    n.relationLookupEnd,
    n.timeLimit,
    n.acceptableRelations,
    n.actualRelations,
    coalesce(f.pk, n.followupSerialNumber),
    n.followupRelations,
    n.authorisationIdentifier,
    n.serviceProviderName,
    n.serviceProviderVersion,
    n.serviceProviderVendor,
    uuid(),
    n.sor
from
    BRS2_Notification n
    left join followup.BRS2_Followup_tmp ft on
        n.followupSerialNumber = ft.pk
    inner join followup.BRS2_Followup f on
        ft.newUid = f.uid
where
    n.queryableCvr = @old_cvr;

commit;

...

Code Block

language	js
collapse	true

{
	"time": "2019-08-19T03:05:02.071Z",
	"category": "dk.sds.nsp.audit.log.brs",
	"audit": {
		"timestamp": "2019-08-19T05:05:02.028+02:00",
		"components": [
			{
				"component": "BRS",
				"contexts": [
					{
						"context": "TreatmentRelationRequest",
						"information": [
							{
								"key": "cvrFromHeader",
								"type": "RPI",
								"value": "46837428"
							},
							{
								"key": "queryableCvr",
								"type": "NPI",
								"value": "46837428"
							},
							{
								"key": "healthProfessionalIdentifierCpr",
								"type": "RPI",
								"value": "1007707419"
							},
							{
								"key": "healthProfessionalIdentifierValidityStart",
								"type": "NPI",
								"value": "2019-01-01T05:05:01.000+01:00"
							},
							{
								"key": "healthProfessionalIdentifierValidityEnd",
								"type": "NPI",
								"value": "2020-01-01T05:05:01.000+01:00"
							},
							{
								"key": "acceptableRelations",
								"type": "NPI",
								"values": [
									"C"
								]
							},
							{
								"key": "authorisationIdentifier",
								"type": "RPI",
								"value": ""
							},
							{
								"key": "followupRelations",
								"type": "NPI",
								"value": "ALL"
							},
							{
								"key": "doctorOrganisationIdentifier",
								"type": "RPI",
								"value": ""
							},
							{
								"key": "ean",
								"type": "RPI",
								"value": "1234567890123"
							},
							{
								"key": "hospitalOrganisationIdentifier",
								"type": "RPI",
								"value": ""
							},
							{
								"key": "sor",
								"type": "RPI",
								"value": "null"
							},
							{
								"key": "patientCpr",
								"type": "RPI",
								"value": "3112910017"
							},
							{
								"key": "timeLimit",
								"type": "NPI",
								"value": "2016-01-01T05:05:01.000+01:00"
							},
							{
								"key": "serviceProviderVendor",
								"type": "NPI",
								"value": "arosii"
							},
							{
								"key": "serviceProviderName",
								"type": "NPI",
								"value": "service"
							},
							{
								"key": "serviceProviderVersion",
								"type": "NPI",
								"value": "snapshot"
							},
							{
								"key": "didCallerSpecifyExternalReferenceId",
								"type": "NPI",
								"value": "no"
							},
							{
								"key": "externalReferenceId",
								"type": "NPI",
								"value": "7412a3ec-953e-4792-a3bf-d512088571fb"
							},
							{
								"key": "uid",
								"type": "NPI",
								"value": "f25d011b-fba1-42fa-a0a7-5ee327b50e44"
							},
							{
								"key": "uniqueReferenceId",
								"type": "NPI",
								"value": "f25d011b-fba1-42fa-a0a7-5ee327b50e44"
							},
							{
								"key": "actualRelations",
								"type": "SPI",
								"values": [
									"D"
								]
							}
						]
					}
				]
			}
		]
	},
	"access": {
		"code": 200,
		"duration": 33,
		"httpHeaders": {
			"Content-Type": "text/xml; charset=utf-8",
			"SOAPAction": "\"\""
		},
		"httpHost": "localhost",
		"idCardAttributes": {
			"medcom:CareProviderID": "46837428",
			"medcom:CareProviderName": "Statens Serum Institut",
			"medcom:ITSystemName": "it system",
			"sosi:AuthenticationLevel": "3",
			"sosi:IDCardID": "JqjzhVMxTrwrm3jCVoj8nw==",
			"sosi:IDCardType": "system",
			"sosi:IDCardVersion": "1.0.1"
		},
		"method": "POST",
		"path": "/brs-nsp/service/brs",
		"query": "wsdl",
		"port": 9090,
		"protocol": "http",
		"reqSize": 8484,
		"resSize": 2469,
		"soapHeaders": {
			"Issuer": "TEST1-NSP-STS",
			"MessageID": "AAABbKfVyyx0S3W3tl49ilNPU0k=",
			"NameID": "SubjectDN={SERIALNUMBER=CVR:46837428-FID:92421325 + CN=Funktionssignatur til testmiljø (funktionscertifikat), O=Statens Serum Institut // CVR:46837428, C=DK},IssuerDN={CN=TRUST2408 Systemtest XXII CA, O=TRUST2408, C=DK},CertSerial={1495058032}"
		},
		"threadId": "default task-59",
		"time": "2019-08-19T05:05:02.027+02:00",
		"stats": {
			"handlerDuration": 6,
			"bufferAllocated": false,
			"usedBuffers": 2,
			"activeBuffersInPool": 2,
			"idleBuffersInPool": 0
		}
	}
}

...

Følgende settings påvirker overvågningssnitfladen
dk.nsi.followupjob.maxtime=120
dk.nsi.notificationcleanupjob.maxtime=120
dk.nsi.replicationjob.maxtime=120
Her angiver man i minutter hvor langt tid de enkelte jobs max må tage at udføre inden overvågningssnitfladen vil begynde at returnerer HTTP 500.

...

BRS-frontend med warning om manglende forbindelse til backend (HTTP 202):

Image Removed
BRS-backend OK:
Image Removed

BRS-backend med fejl pga. MySQL (HTTP 500):

Image Removed

BRS-backend med fejl pga. at behandlingstiden for en opfølgning er for lang. Fejlen opstår når et batch til opfølgning tager for lang tid. Og status viser både hvorhvornår en kørsel er kørt helt færdig (lastSuccessfullAllBatches), og hvornår et batch er blevet kørt færdig (lastSuccessfulRun). Er lastSuccessfullAllBatches blank, betyder det, at der er tale om den første batchkørsel siden start af servicen, og den endnu ikke er afsluttet.

Image Removed

Status-siderne er også i stand til at trække yderligere informationer om køstørrelser osv. fra MySQL. Disse oplysninger inkluderes dog ikke i de normalt responses, da de genererer et vist load på MySQL, men de kan trækkes ved at tilføje en "?detailed"-parameter på URLen til status-siden (fx http://host:port/brs-nsp/status?detailed).

Nedenfor ses eksempler på hvilke oplysninger der inkluderes på hhv. frontend og backend. På frontend ses det at der ligger 5 records der afventer overførsel til backend, samt 1 notification der kan hentes af klienter:

Image Removed

På backend rapporteres det, at followup-jobbet har 5 records der afventer behandling, 85 records der er udsat til senere check, samt en notifikation der kan hentes af klienter:

Image Removed

...

Hvis status-siden giver HTTP 500 bør man checke den tilsvarende brs-frontend/brs-backend.log, som typisk vil indeholde en mere detaljeret fejlmeddelelse end status-siden (stacktrace osv).
Ved problemer med indlæsning af brs-frontend/brs-backend.properties bør man verificere at filen er volume-mappet korrekt ind i configuration/ biblioteket. Vær opmærksom på at filen ikke læses hvis den ikke er til stede ved opstart af Wildfly.
Kontroller altid præcist hvilke jobs og services der er nede. Hvis BRS-backend er nede vil det også give sig udslag i warning på BRS-frontend, som i så fald ikke kan sende data videre. I den situation hjælper det ikke at genstarte BRS-frontend. Hvor ofte jobs køres kan konfigureres i property-filerne.
En service eller et job kan stoppes og starter gennem docker.

...

Data fra eksterne registre vil løbende blive slettet. Der bør derfor foretages backup af indkomne registerdata på en forsvarlig måde, i tilfælde af behovet for en genetablering af data på register_alarm i tilfælde af nedbrud. Disse skal opbevares på en forsvarlig måde da der er tale om personhenførbare data.

Migrering ved overgang til Kafka-løsning

I release 2.1.0 er BRS ændret, så Kafka anvendes til at vedligeholde køen af bestilte opfølgninger. Anvendelsen af Kafka erstatter den tidligere followup-database. I den forbindelse er der brug for at behandle de bestillinger der allerede ligger i followup-databasen, og sætte dem i kø i Kafka. Til dette formål er der udviklet en kommandolinjeapplikation, kafka-migration, som leveres som et docker-image (navn: registry.nspop.dk/components/brs/kafka-migration). Applikationen forbinder til followup-databasen og kafka-serveren, og fungerer som følger:

Hent et batch af bestillinger fra BRS2_TreatmentRelationFollowup-tabellen.
Hver bestilling sættes i kø som en kafka-besked.
Bestillingerne slettes fra BRS2_TreatmentRelationFollowup-tabellen.

Applikationen udfører ovenstående procedure, ind til BRS2_TreatmentRelationFollowup-tabellen er tom. I tilfælde af fejl standser applikationen.

Applikationen konfigureres i filerne kafka-migration.properties og log4j.properties. Disse filer volume-mountes på stien /config. Nedenfor dokumenteres indholdet af kafka-migration.properties. Indholdet af filen log4j.properties er standard og forventes ikke at skulle ændres, og en gennemgang af indholdet er derfor udeladt.

...

Property

...

Beskrivelse

...

Default

...

dk.nsi.db.treatment_relation_followup.url

...

Database URL - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
Eksempel kan ligeledes være følgende:
jdbc:mysql://cnsp-db01/

,
			"MessageID": "AAABbKfVyyx0S3W3tl49ilNPU0k=",
			"NameID": "SubjectDN={SERIALNUMBER=CVR:46837428-FID:92421325 + CN=Funktionssignatur til testmiljø (funktionscertifikat), O=Statens Serum Institut // CVR:46837428, C=DK},IssuerDN={CN=TRUST2408 Systemtest XXII CA, O=TRUST2408, C=DK},CertSerial={1495058032}"
		},
		"threadId": "default task-59",
		"time": "2019-08-19T05:05:02.027+02:00",
		"stats": {
			"handlerDuration": 6,
			"bufferAllocated": false,
			"usedBuffers": 2,
			"activeBuffersInPool": 2,
			"idleBuffersInPool": 0
		}
	}
}

Anchor
_Toc477260968
_Toc477260968
Konfiguration af overvågning

Anchor
RefHeading_Toc1113_4855908941
RefHeading_Toc1113_4855908941
Anchor
_Toc477260969
_Toc477260969
Eksempler på status-sider

BRS-frontend OK:
Image Added

BRS-frontend med warning om manglende forbindelse til backend (HTTP 202):

Image Added
BRS-backend OK:
Image Added

BRS-backend med fejl pga. MySQL (HTTP 500):

Image Added

På backend rapporteres det, at followup-jobbet har 5 records der afventer behandling, 85 records der er udsat til senere check, samt en notifikation der kan hentes af klienter:

Image Added

Anchor
_Toc326916726
_Toc326916726
Anchor
_Toc477260970
_Toc477260970
Standard fejlsøgning

Hvis status-siden giver HTTP 500 bør man checke den tilsvarende brs-frontend/brs-backend.log, som typisk vil indeholde en mere detaljeret fejlmeddelelse end status-siden (stacktrace osv).
Ved problemer med indlæsning af brs-frontend/brs-backend.properties bør man verificere at filen er volume-mappet korrekt ind i configuration/ biblioteket. Vær opmærksom på at filen ikke læses hvis den ikke er til stede ved opstart af Wildfly.
Kontroller altid præcist hvilke jobs og services der er nede. Hvis BRS-backend er nede vil det også give sig udslag i warning på BRS-frontend, som i så fald ikke kan sende data videre. I den situation hjælper det ikke at genstarte BRS-frontend. Hvor ofte jobs køres kan konfigureres i property-filerne.
En service eller et job kan stoppes og starter gennem docker.

Anchor
_Toc326916727
_Toc326916727
Anchor
_Toc477260971
_Toc477260971
Krav til backup m.m.

Migrering ved overgang til Kafka-løsning

Hent et batch af bestillinger fra BRS2_TreatmentRelationFollowup-tabellen.
Hver bestilling sættes i kø som en kafka-besked.
Bestillingerne slettes fra BRS2_TreatmentRelationFollowup-tabellen.

Applikationen udfører ovenstående procedure, ind til BRS2_TreatmentRelationFollowup-tabellen er tom. I tilfælde af fejl standser applikationen.

Property	Beskrivelse	Default
dk.nsi.db.treatment_relation_followup.url	Database URL - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} Eksempel kan ligeledes være følgende: jdbc:mysql://cnsp-db01/
dk.nsi.db.treatment_relation_followup.driverclass	Database driver - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn} Eksempel kan ligeledes være følgende: com.mysql.jdbc.Driver
dk.nsi.db.treatment_relation_followup.user	Database brugernavn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
dk.nsi.db.treatment_relation_followup.pwd	Database adgangskode - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
dk.nsi.db.treatment_relation_followup.database	Database navn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
dk.nsi.brs.kafka.topic	Kafka-topic som bestillinger skal publiceres til
kafka.producer.client.id	Client-id på den kafka-producer, der ikøsætter bestillinger.
kafka.producer.bootstrap.servers	Url til Kafka bootstrap-server.

I development-setuppet (compose/development/docker-compose.yml) findes et eksempel på, hvordan applikationen sættes op.

...

dk.nsi.db.treatment_relation_followup.driverclass

...

Database driver - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}
Eksempel kan ligeledes være følgende:
com.mysql.jdbc.Driver

...

dk.nsi.db.treatment_relation_followup.user

...

Database brugernavn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}

...

dk.nsi.db.treatment_relation_followup.pwd

...

Database adgangskode - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}

...

dk.nsi.db.treatment_relation_followup.database

...

Database navn - se tabel med miljøspecifikke oplysninger for databaser for detaljer om {navn}

...

dk.nsi.brs.kafka.topic

...

Kafka-topic som bestillinger skal publiceres til

...

kafka.producer.client.id

...

Client-id på den kafka-producer, der ikøsætter bestillinger.

...

kafka.producer.bootstrap.servers

...

Url til Kafka bootstrap-server.

I development-setuppet (compose/development/docker-compose.yml) findes et eksempel på, hvordan applikationen sættes op.

...

Version

...

Dato

...

Ændring

...

Ansvarlig

...

0.1

...

2011-06-15

...

Initielt Dokument

...

Trifork

...

0.2

...

2011-07-27

...

Opdatering af dokumentation jf. implementation af generelle notifikationer

...

Trifork

...

0.3

...

2011-08-10

...

Opsplitning af dokumentation jf. opsplitning af BRS og GOS

...

Trifork

...

0.4

...

2011-10-05

...

Mindre tilretninger jf. Stamdatas replikering af Sikrede data

...

Trifork

...

1.0

...

2012-06-08

...

Tilføjet SQL til oprydning på BRS tabeller

...

Trifork

...

1.1

...

2013-10-21

...

Opdateret SVN link

...

Trifork

...

2.0

...

2017-03-10

...

Diverse opdateringer ifm. BRS2

...

Trifork

...

KvalitetsIT

...

Content

Space Tools

Versions Compared

Old Version 57

New Version Current

Key

Konfiguration af Oprydningsjob

Anchor
_Toc477260963
_Toc477260963
Tilføjelse af CVR-numre og typer

Duplikering af data for CVR-nummer ifm. certifikatskift

Duplikering af data for CVR-nummer ifm. certifikatskift

Migrering ved overgang til Kafka-løsning

Anchor
_Toc477260968
_Toc477260968
Konfiguration af overvågning

Anchor
RefHeading_Toc1113_4855908941
RefHeading_Toc1113_4855908941
Anchor
_Toc477260969
_Toc477260969
Eksempler på status-sider

Anchor
_Toc326916726
_Toc326916726
Anchor
_Toc477260970
_Toc477260970
Standard fejlsøgning

Anchor
_Toc326916727
_Toc326916727
Anchor
_Toc477260971
_Toc477260971
Krav til backup m.m.

Migrering ved overgang til Kafka-løsning

Content

Space Tools

Page History

Versions Compared

Old Version 57

New Version Current

Key

Konfiguration af Oprydningsjob

Anchor_Toc477260963_Toc477260963Tilføjelse af CVR-numre og typer

Duplikering af data for CVR-nummer ifm. certifikatskift

Duplikering af data for CVR-nummer ifm. certifikatskift

Migrering ved overgang til Kafka-løsning

Anchor_Toc477260968_Toc477260968Konfiguration af overvågning

Anchor__RefHeading___Toc1113_4855908941__RefHeading___Toc1113_4855908941 Anchor_Toc477260969_Toc477260969Eksempler på status-sider

Anchor_Toc326916726_Toc326916726 Anchor_Toc477260970_Toc477260970Standard fejlsøgning

Anchor_Toc326916727_Toc326916727 Anchor_Toc477260971_Toc477260971Krav til backup m.m.

Migrering ved overgang til Kafka-løsning

Anchor
_Toc477260963
_Toc477260963
Tilføjelse af CVR-numre og typer

Anchor
_Toc477260968
_Toc477260968
Konfiguration af overvågning

Anchor
RefHeading_Toc1113_4855908941
RefHeading_Toc1113_4855908941
Anchor
_Toc477260969
_Toc477260969
Eksempler på status-sider

Anchor
_Toc326916726
_Toc326916726
Anchor
_Toc477260970
_Toc477260970
Standard fejlsøgning

Anchor
_Toc326916727
_Toc326916727
Anchor
_Toc477260971
_Toc477260971
Krav til backup m.m.