INDHOLD
Beskrivelse
DCC (DeCoupling Component): DCC er også kendt som SOSI afkoblingskomponenten. Også kaldet SOSI-DDC.
SOSI-DCC fungerer som webservice gateway, og dens hovedfunktioner er routning af requests, håndhævelse af timeout-grænser på webservice kald samt asynkron afkobling af webservice kald med tilhørende retry-mekanisme (som dog aldrig er blevet implementeret). Formålet med komponenten er primært at understøtte flere typer af kald-semantik. Et godt eksempel er behovet for en fleksibel garanti for svartider, hvor en klient til afkoblingskomponenten i et web service kald kan specificere, at kaldet skal forsøges gennemført inden for et antal millisekunder. Hvis svaret ikke er kommet inden for det angivne antal millisekunder, afbryder komponenten kommunikationen med den pågældende web service, og returnerer en fejl til klientsystemet. Afkoblingskomponenten understøtter også andre typer af kald.
Support ansvarlig: Arosii
NSP: Viderestillingsservice (DCC) - Leverancebeskrivelse
Forretningsanvendelse
Relaterede registre og services
- A00
Applikationsbeskrivelse
DCC (DeCoupling Component): SOSI-DCC fungerer som webservice gateway, og dens hovedfunktioner er routning af requests, håndhævelse af timeout-grænser på webservice kald samt asynkron afkobling af webservice kald med tilhørende retrymekanisme.
WSDL: DCC'en viderestiller kald til GW og andre services, så der er ikke en WSDL for DCC'en
DCC kræver ingen whitelisting.
DCC (DeCoupling Component): DCC er også kendt som SOSI afkoblingskomponenten.
SOSI-DCC fungerer som webservice gateway, og dens hovedfunktioner er routning af requests, håndhævelse af timeout-grænser på webservice kald samt asynkron afkobling af webservice kald med tilhørende retry-mekanisme (som dog aldrig er blevet implementeret). Formålet med komponenten er primært at understøtte flere typer af kald-semantik. Et godt eksempel er behovet for en fleksibel garanti for svartider, hvor en klient til afkoblingskomponenten i et web service kald kan specificere, at kaldet skal forsøges gennemført inden for et antal millisekunder. Hvis svaret ikke er kommet inden for det angivne antal millisekunder, afbryder komponenten kommunikationen med den pågældende web service, og returnerer en fejl til klientsystemet. Afkoblingskomponenten understøtter også andre typer af kald.
Der bemærkes, at komponenten ikke er bundet til [DGWS] og ikke foretager nogen form for validering af at [DGWS] overholdes og dermed heller ikke validerer et eventuel indlejret SOSI Idkort.
Afhængig af hvordan den enkelte operation (SOAPAction) er konfigureret, erstatter, fjerner eller bevarer SOSI-DCC [WS-addressing] headere i kaldet der viderestilles.
Arkitekturoverblik
-------------------
Som webservice gateway er komponenten placeret mellem en klient – som typisk kaldes for webservice consumer (WSC) – og en service udbyder, kaldet webservice provider (WSP, kan være både indenfor og udenfor NSP miljøet).
WSCen webservice sender requests til WSPen igennem komponenten og modtager responsen enten direkte eller ved synkron kommunikation.
Logisk arkitektur
-------------------
Komponenten er implementeret som simpel Servlet, som danner indgangspunktet for indkommende webservice kald. Ved opstart af komponenten indlæses konfigurationen, som indeholder routningsinformation og en default afkoblings-model for de operationer, der skal kunne kaldes igennem komponenten.
Når en besked modtages fra en WSC til videreforsendelse til en WSP, gennemløbes følgende flow:
1) der er IKKE (længere) whitelisting til DCC
2) Routning slås op i komponentens konfiguration: På baggrund af SOAPAction i HTTP headeren afgøres hvorhen beskeden skal routes. Hvis routningsinformation ikke findes i komponentens konfiguration afbrydes kaldet og der returneres et fejlsvar
3) Beskeden parses: Der foretages en SAX parsning af beskeden hvor relevante parametre opsamles
4) Afkoblingsmodel identificeres: Der afgøres hvorvidt kaldet til WSPen skal foregå synkront med timeout, asynkront eller asynkront ved timeout. Hvis ikke WSCen har specificeret afkoblingsmodellen i beskeden, benyttes default afkoblingsmodellen for den pågældende operation som er angivet i komponentens konfiguration
5) Beskeden sendes til WSPen
Routningskonfigurationen vedligeholdes af Central Router Konfiguration (CRK) komponenten.
SOSI-GW som Proxy
----------------------
Det er muligt at specificere i DCC-routing-konfigurationen, at kald skal routes over SOSI-GW inden en service kaldes. SOSI-GW vil efterfølgende kalde den endelige service. Dette giver mening, hvor der anvendes MOCES-certifikater mod en service. Ved denne type routing hjælpes klienter ved at overlade opgaven med, at opbevare SOSI ID-kort til SOSI-GW. Rent praktisk fungerer dette ved, at angive i DCC-routing-konfigurationen om service-kald skal routes gennem SOSI-GW. Angives dette kan samtidig også angives en værdi for den maksimale alder i minutter på SOSI ID-kort fundet i SOSI-GW cache. DCC sørger så for, at indsætte denne værdi i kaldet inden routningen til SOSI-GW, som vil afvise kaldet, hvis alderen er overskredet. Denne type routning-konfiguration benyttes typisk af services, som ønsker en specifik styring af SOSI ID-kortets alder eller ønsker at håndtere SOSI ID-kort opbevaringen udenfor eget system.
Snitflade
----------
SOSI-DCC har én proxy webservice snitflade, som router kald på baggrund af den operation der kaldes – angivet som 'SOAPAction' HTTP header En angivelse af 'SOAPAction' HTTP headeren er påkrævet for HTTP bundne SOAP kald. .
For hver operation, der skal kunne kaldes i gennem DCC, er komponenten konfigureret med et WSP endpoint, en timeout-grænse og en eventuel proxy endpoint som kaldet skal routes i gennem (fx en SOSI-Gateway).
Datastruktur, Intern register: Central Rute Konfiguration (CRK)
Register properties:
Central Rute Konfiguration
CRK'en har til formål at stille konfiguration til rådighed for DCC'en på en form der let kan modificeres og gøres tilgængelig for DCC i alle NSP-miljøer -- centrale såvel som decentrale.
CRK anvender databasen til dels at læse eksisterende endpoint definitioner, dels til oprettelse af nye definitioner og deaktivering af ældre versioner.
Databasen består af 2 tabeller, som tilsammen udgør en versioneret repræsentation af de eksterne endpointdefinitioner.
Entitetsbeskrivelser
LogEntry
Logentry for hændelsen med angivelse af borger, bruger og evt. ansvarlig, organisation og system samt anvender session og tidspunkt.
Objektet indeholder følgende information:
---------------------------------------------
id
regKode -- Unique enforced af constraint
cprNrBorger -- CPR-nummer for den borger, hvis data der er forsøgt tilgået.
bruger -- CPR for person som har tilgået eller forsøgt at tilgå borgerens data. CPR 0000000000 kan benyttes efter aftale med NSI, hvor registrator så har ansvaret for at kunne fremfinde personens identitet.
ansvarlig -- CPR på sundhedsperson eller borger, der er handlet på vegne af ifbm. tilgang til eller forsøg på tilgang til borgerens data. CPR 0000000000 kan benyttes efter aftale med NSI, hvor registrator så har ansvaret for at kunne fremfinde personens identitet. Kan være tom.
orgUsingID -- Identifikation af tilknyttet organisation ved hjælp af SOR-kode, SHAK-kode, ydernummer, p-nummer, cvr-nummer eller kommunekode samt angivelse af hvilken af disse typer, der anvendes som identifikation. Anvendes kun, når bruger er sundhedsperson. Når registreringen omhandler sundhedspersons adgang til borgers data er elementet krævet, medmindre andet er aftalt i den serviceaftale, som anvender af servicen har indgået med den dataansvarlige myndighed (NSI).
orgUsingName_id -- relation til OrganisationName
systemName -- Identifikation eller navn på kildesystem hvorfra forsøg på tilgang til borgers data er sket.
handling -- Tekstuel beskrivelse af den handling, bruger har udført i forbindelse med forsøg på tilgang til borgers data.
sessionId -- Et teknisk sessions id, der i kontekst af anvendersystemet unikt identificerer den session, som bruger var i, da handlingen blev gennemført.
tidspunkt -- Tidspunktet for tilgang eller forsøg på tilgang til borgers data. Dato og tid skal anføres i Zulu-tid og med millisekunder.
OrganisationName
Indeholder organisations navnet som brugeren tilhører
Objektet indeholder følgende information:
---------------------------------------------
name -- Navn på sundhedspersonens organisation. Når registreringen (LogDataEntry) omhandler sundhedspersons adgang til borgers data er elementet krævet. Bemærk, at navnet skal være meningsfyldt for en borger.
digest -- relation fra LogEntry
Status
Benyttes til at optimere oprydningen af Minlog data.
Objektet indeholder følgende information:
---------------------------------------------
`id` --
`lastUpdated` --
Whitelist config (BRS)
Objektet indeholder de CVR som er whitelisted til brug på test/prod for BRS servicen
Objektet indeholder informationen:
---------------------------------------
service_key
-- BRS behandlingsrelationsservice:
+ dk.nsi.auth.query.type.cvr.list - BRS
+ dk.nsi.auth.create.type.cvr.list - BRS
+ dk.nsi.auth.brs.cvr.list - NO_TYPE
-- Min Log:
+ dk.nsi.minlog.registration (registration service)
+ minlogws (opslags service)
service_type
-- NO_TYPE
-- BRS
-- CPRSUBSCRIPTION
cvr -- CVR nummer
comment -- Her anføres NSP Jira nummer som relaterer den enkelte whitelisting
Tabelbeskrivelser
Tabel: LogEntry
CREATE TABLE LogEntry (
id bigint NOT NULL AUTO_INCREMENT,
regKode varchar(36) NOT NULL,
cprNrBorger varchar(10) NOT NULL,
bruger varchar(20),
ansvarlig varchar(20),
orgUsingID varchar(25),
orgUsingName_id int,
systemName varchar(25),
handling varchar(75),
sessionId varchar(46),
tidspunkt datetime NOT NULL,
PRIMARY KEY (id),
CONSTRAINT unique_constraint_regKode UNIQUE (regKode),
INDEX log_cpr_and_timestamp_index (cprNrBorger, tidspunkt))
ENGINE=InnoDB DEFAULT CHARSET=latin1 DEFAULT COLLATE=latin1_swedish_ci;
Tabel: OrganisationName
CREATE TABLE OrganisationName (
id int(11) NOT NULL AUTO_INCREMENT,
name varchar(256) NOT NULL,
digest bigint NOT NULL,
PRIMARY KEY (id),
INDEX organisation_name_digest_idx (digest))
ENGINE=InnoDB DEFAULT CHARSET=latin1 DEFAULT COLLATE=latin1_swedish_ci;
Tabel: status
CREATE TABLE `status` (
`id` int NOT NULL,
`lastUpdated` datetime not null,
PRIMARY KEY (`id`)
);
Fil: Minlog.log
Entries sendt til MinLogRegistrationService formatteres og gemmes i en logfil.
Fil: MinlogTransfer.log
Entries sendt til MinLogRegistrationService formatteres og gemmes i en logfil.
Sendes fra dNSP/cNSP til Backend via Minlog Transfer
Tabel: whitelist_config (BRS)
CREATE TABLE whitelist_config (
service_key VARCHAR(50) NOT NULL,
service_type VARCHAR(20) NOT NULL,
cvr CHAR(8) NOT NULL,
comment VARCHAR(100) NULL,
PRIMARY KEY (service_key, service_type, cvr)
); -- ENGINE=InnoDB COLLATE=utf8_bin;
Teknologibeskrivelse
Refereres fra
- 2.2 NSP Forretningsarkitektur områder
- A00 Central Rute Konfiguration (CRK)
- A01 DCC viderestillingsservice
- E06 SOSI-GW