Page History
...
| Table of Contents |
|---|
Beskrivelse
DCC National Adviseringsservice (DeCoupling ComponentNAS) : 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.
er en generel adviseringsservice, som giver mulighed for at modtage adviseringer i forbindelse med patientens eller borgerens forløb. NAS tilvejebringer mulighed for afkoblet system-til-system advisering ved brug af NSP.
Den nationale adviseringsservice giver mulighed for at oprette abonnementer og adviseringsfiltre, samt såkaldte PullPoints, der på anvenderens vegne opsamler adviseringer til senere afhentning på NSP’en. Adviseringsservicen fungerer som en ”distributionscentral”, der modtager adviseringer fra et antal kilder, og på basis af oprettede abonnementer med indbyggede filtre videredistribuerer adviseringerne til de rette modtagere (dvs abonnenter, hvor adviseringerne matcher kravene i filtrene).
Adviseringsservicen er ikke direkte databærende (dvs. indeholder ikke personfølsomme data), men adviserer klientsystemerne om at der findes nye eller opdatererede data der kan slås op på. Der adviseres på baggrund af nøgler som borgerens CPR-nummer og organisations-ID’er. Adviseringsservicen er ikke bundet til anvendelse af specifikke typer af nøgler.
Løsningen giver alle med adgang til NSP mulighed for at aflevere adviseringer til øvrige parter i sundhedssektoren gennem NSP. Løsningen er en realisering af et ”publish-subscribe” kommunikationsmønster, hvor adviseringskilder ”skubber” adviseringsinformationer til modtagere, dog med mulighed for at etablere et ”push-pull” scenarie gennem etablering af såkaldte ”PullPoints”.
Kilder og modtagere er indbyrdes afkoblede, idet kilderne leverer adviseringer til adviseringsservicen, og modtagerne vedligeholder et abonnement hos adviseringsservicen på de typer af adviseringer (”Topics”), de ønsker at modtage fra de respektive kilder.
Den primære datakilde er FMK.
Support ansvarlig: Arosii
NSP, NAS leverancebeskrivelse: National Adviseringsservice (NASSupport ansvarlig: Arosii
NSP: Viderestillingsservice (DCC) - Leverancebeskrivelse
Forretningsanvendelse
Relaterede registre og services
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
actions
Action angiver hvordan det enkelte endpoint kaldes
Objektet indeholder informationen:
--------------------------------------
- `name`: uri på den angivne action - Hentet fra ekstern definition og benyttes af DCC
- `model`: Indeholder pt altid værdien 'synchronous_timeout'
- `timeout`: angiver den maksimalt tilladelige svartid for den eksterne service der kaldes gennem DCC.
- `useProxy`: Angiver hvorvidt DCC'en må sende forespørgslen gennem en proxy (SOSI-GW). Indlæst fra ekstern kilde.
- `proxyOverride`: (valgfri) Vedligeholdes af driften og giver mulighed for at overskrive useProxy.
- `idcardmaxage`: (valgfri) Medsendes til gateway, såfremt en sådan benyttes, og anvendes til check for udløbne id-kort.
- `endpointId`: Den version af endpoint, som en given action er knyttet til. Relation til endpoints tabellen
- `inheritedEndpoint`: Såfremt en action "forsvinder" fra den eksterne kilde, bevares den som udgangspunkt i konfigurationen, med angivelse af hvor den er kopieret fra. Relation til endpoints tabellen
- `active`. Angiver hvorvidt pågældende action er aktiv eller ej. Kan f.eks. benyttes af driften til helt at fjerne actions, der forsvinder fra den eksterne kilde.
endpoints
Endpoints Konfiguration til brug for Viderstillingservicen, DCC
Objektet indeholder informationen:
--------------------------------------
- `configId`: Navnet på det konfigurerede job i spring konfigurationen.
- `name`: Det eksterne navn, defineret i den eksternt indlæste fil.
- `url`: Adressen på det eksterne endpoint.
- `externaltime`: Tidsstempel defineret i den eksterne kilde. Benyttes ved genindlæsning til at kontrollere om der er sket ændringer.
- `active`: Angiver hvorvidt denne (version af) endpoint definition er aktiv eller ej.
- `version`: Ved genindlæsning oprettes altid en ny version (række i tabellen), og de foregående deaktiveres.
override
"override" tabellen anvendes til at overstyre de url'er de DCC'er der kører på dnsp'erne anvender til at kalde videre med således vi kan ramme de services der kører på dnsp'erne også.
(undtagelses håndtering af regionernes DNS, hvor det hedder noget forskelligt i de forskellige regioner (kører på regionernes net), hvorved der kan overrides forskellige dele af url'en, f.eks. hostname)
Objektet indeholder informationen:
--------------------------------------
name
node
serviceUrl
useProxy
timeout
idcardmaxage
doNotVerifySSLHostName
wsaHeadersProcessing
Fil: xml-konfiguration (CRK)
Filen indeholder definitioner af endpoints med tilhørende actions
Tabelbeskrivelser
Tabel: actions
CREATE TABLE actions (
id bigint(20) NOT NULL auto_increment,
endpointId bigint(20) NOT NULL,
inheritedEndpoint bigint(20),
name varchar(4096) NOT NULL,
timeout bigint(20) NOT NULL,
model varchar(255) NOT NULL,
active boolean default false,
idcardmaxage int(11),
useProxy boolean NOT NULL,
proxyOverride boolean,
primary key(id)
);
CREATE INDEX IX_ACT_1 ON actions (endpointId, active); -- bruges af view
ALTER TABLE actions ADD CONSTRAINT act_ep1 FOREIGN KEY (endpointId) REFERENCES endpoints (id); -- bruges af DCC
ALTER TABLE actions ADD CONSTRAINT act_ep2 FOREIGN KEY (inheritedEndpoint) REFERENCES endpoints (id);
Tabel: endpoints
CREATE TABLE endpoints (
id bigint(20) NOT NULL auto_increment,
configId varchar(255) NOT NULL,
name varchar(255) NOT NULL,
url varchar(4096) NOT NULL,
lastModified Datetime NOT NULL,
externaltime Datetime NOT NULL,
createdtime Datetime NOT NULL,
version bigint(20) NOT NULL,
active boolean NOT NULL,
primary key(id)
);
CREATE UNIQUE INDEX IX_EP_1 ON endpoints (configId, version);
CREATE INDEX IX_EP_2 ON endpoints (active); -- bruges af view
CREATE INDEX IX_EP_3 ON endpoints (createdtime); -- bruges af view
Tabel: override
Desc crk.override;
Den Nationale Adviseringsservice udstilles på NSP (både cNSP og dNSP), og det er derfor teknisk muligt at få adgang til servicen fra både regionale it-systemer (dNSP) og fra it-systemer, der gør brug af den centrale NSP-instans (cNSP).
Der findes 5 endpoints med kald formelt specificeret i tilhørende WDSL:
++ http://[host]:[port]/decoupling/notificationbroker/service https://wsdl.nspop.dk/notificationbroker/service?wsdl
++ http://[host]:[port]/decoupling/pullpointfactory/service https://wsdl.nspop.dk/pullpointfactory/service?wsdl
++ http://[host]:[port]/decoupling/pullpoint/service https://wsdl.nspop.dk/pullpoint/service?wsdl
++ http://[host]:[port]/decoupling/subscriptionmanager/service https://wsdl.nspop.dk/subscriptionmanager/service?wsdl
++ http://[host]:[port]/decoupling/idlist/service https://wsdl.nspop.dk/idlist/service?wsdl
Whitelist databasen bruges ved autorisation af anvendersystemer (ikke for "Notify" operationen).
Adviseringsservice er realiseret som 5 Java baserede webservices med tilhørende operationer:
1) NotificationBroker-service: Modtager og persisterer adviseringer fra adviseringskildesystemer. Videresender adviseringer til de abonnerende PullPoints.
Overholder WS-BASE-NOTIFICATION-standardens NotificationConsumer-interface, dog med følgende afvigelse fra standarden:
- der returneres ikke-standard svar på Notify
- der kan returneres ikke-standard SOAP faults på Notify
Virkemåde:
- NotificationBroker webservice, der implementerer NotificationConsumer-interfacet og skriver modtagne adviseringer til en JMS-kø (JMS queue "NotifyQueue", ikke JMS topic)
- NotifyConsumerMessageBean, en message driven bean (MDB), der læser adviseringer fra JMS-køen og sender til interesserede abonnenters endpoints, der afgøres udfra Subscription-databasen
Persistering: JMS queue med hornetq køen "NotifyQueue"
Operation:
++ Notify: Publicerer en eller flere adviseringer på adviseringsservicen. (Bemærk at notify kaldet på notificationbroker ikke udstilles som Den Gode Webservice, hvorfor der (i modsætning til de efterfølgende services) ikke skal konfigureres krav til sikkerhedsniveau for id-kort for denne.)
2) PullPointFactory-service: Webservice der tilbyder operation til oprettelse af et pullpoint. Desuden kører PullPointFactory oprydningsjobbet, der tjekker og fjerner ubrugte pullpoints og abonnenter
Persistering: MySQL med skemaerne "pullpoints" og "eprmapping"
Oprydningen af pullpoints: PullPointFactory har en timer kørende, der løbende tjekker om der er ubrugte pullpoints. Se "Oprydning job" for nærmere beskrivelse.
Operation:
++ CreatePullPoint: Et anvendersystem opretter et Pullpoint ved denne operation. Når der oprettes et pullpoint skabes et unikt pullpoint-id, der i WS-BASE-NOTIFICATION returneres i CreatePullPointResponse som en WS Addressing endpoint reference (EPR). Pullpointets unikke EPR indeholder en adresse indeholdende en URI bestående af schema-navn, authority-del, path-del og en nøgle-del.
3) PullPoint-service: Webservice der tilbyder operationer til indhentning af adviseringer fra et PullPoint samt nedlæggelse af PullPointet.
Persistering: MySQL med skemaerne "pullpoints"
Operationer:
++ GetMessages - Et anvendersystem henter adviseringer, uanset emner, fra et PullPoint. Indhentede adviseringer fjernes fra PullPointet.
Anvendersystem skal være autentificeret og autoriseret
I autorisationen indgår desuden, at anvendersystemet skal være ejer af PullPointet, dvs. fra samme organisation som den, der oprettede PullPointet.
Statistik på et pullpoint vedligeholdes ved GetMessages-kald da det forventes at disse sker knap så hyppigt som Notify-kald.
Oprydning af idlister: I IdList kører en timer, der eksekverer oprydningen af ubrugte IdLister. En IdList kan fjernes, hvis ingen abonnenter refererer IdListen i en længere periode (45 dage som standard). Se også "Oprydning job".
++ DestroyPullPoint - Et anvendersystem nedlægger et PullPoint.
Anvendersystem skal være autentificeret og autoriseret
I autorisationen indgår desuden, at anvendersystemet skal være ejer af PullPointet, dvs. fra samme organisation som den, der oprettede PullPointet.
Kontrol af, om PullPointet er anvendt i abonnement(er) gennemføres ikke, men PullPointet bør ikke være anvendt.
4) IDlist servicen har ansvaret for at oprette, opdatere og nedlægge id-lister til filtrering af adviseringer på anmodning herom. Den skal kunne håndtere tusinder af ID-lister med forventet varierende længder, herunder ID-lister med tusinder af ID.
Persistering: MySQL med skema "subscriptions"
Operationer:
++ CreateIDList - Opretter eller opdaterer en ID Liste til brug for et abonnement på adviseringer
Anvendersystem skal være autentificeret og autoriseret
I autorisationen indgår desuden, at opdatering af ID-liste kun kan gennemføres af den organisation, der oprettede den
++ DestroyIDList - Nedlægger en eksisterende ID Liste
Anvendersystem skal være autentificeret og autoriseret.
I autorisationen indgår desuden, at nedlæggelse af ID-liste kun kan gennemføres af den organisation, der oprettede den.
Det er en forudsætning, at ID-listen ikke anvendes i abonnement(er). Der returneres SOAP Fault, hvis ID-listen anvendes.
5) SubscriptionManager-servicen udstiller Subscribe-operationen i NotificationProducer-interfacet og Unsubscribe-operationen i SubscriptionManager-interfacet i WS-BASE-NOTIFICATION. SubscriptionManager-servicen har ansvaret for at gennemføre anmodninger om oprettelse og nedlæggelse af abonnementer (med henblik på modtagelse af adviseringer).
Persistering: MySQL med skemaerne "subscriptions" og "eprmapping"
Operationer:
++ Subscribe - Opretter abonnement på et emne med givet filter.
Som led i abonnement-oprettelse specificeres hvilket emne, der ønskes abonneret på. Bemærk, at oprettelse og erhvervelse af emner og deres identifikation sker out-of-band forud for oprettelse af abonnement. Emner og indhold i adviseringer defineres af organisationen bag kildesystemet. Abonnering på adviseringer for enkelt ID henholdsvis flere ID'ere understøttes ved anvendelse af et filter, der specificeres på abonneringstidspunktet sammen med emne. Abonnering på adviseringer for flere ID'er understøttes gennem navngivne lister, de såkaldte ID-lister.
Anvendersystem skal være autentificeret og autoriseret.
I autorisationen indgår desuden, at såfremt der er anvendt ID-liste i abonnementet, da skal anvendersystemet være ejer af ID-listen
++ Unsubscribe - nedlægger et abonnement
Anvendersystem skal være autentificeret og autoriseret.
I autorisationen indgår desuden, at anvendersystemet skal være ejer af abonnementet, dvs. fra samme organisation som den, der oprettede abonnementet
Oprydning job
----------------
(BEMÆRK: ingen af nedenstående oprydning er blevet taget i brug,- i stedet har driften lavet et simpelt oprydningsjob med SQL-delete.)
Der er implementeret automatisk oprydning af pull points og data, da det har vist sig, at anvenderne af NAS ikke altid holder styr på, hvilke pullpoints, idlister og abonnementer de får oprettet. Følgende oprydningsjob er derfor implementeret i version 2.0.0, og de følger denne algoritme:
Oprydningen af pullpoints: PullPointFactory har en timer kørende, der løbende tjekker om der er ubrugte pullpoints. Når disse findes bliver de nedlagt.
Hvis et pullpoint har beskeder der ikke er blevet hentet i over 10 dage slettes beskederne og en systemadvisering oprettes på pullpointet, så en eventuel anvender kan se hvad der er sket. Så længe denne system besked ikke er afhentet, modtager pullpointet ikke nye adviseringer. Hvis et pullpoint har beskeder, der ikke er blevet afhentet i over 45 dage (inkl systembeskeden), slettes de abonnementer, som anvender pullpointet og pullpointet nedlægges.
Tre tilstande:
- OK: Angiver at pullpointets beskeder bliver afhentet regelmæssigt.
- WARNING: Angiver at beskederne i pullpointet har været uafhentet i en kort periode. I denne tilstand er beskederne i pullpointet fjernet og en systemadvisering er sendt til pullpointet. Nye beskeder sendes ikke videre til pullpointet før systemadviseringen er afhentet fra pullpointet, hvor tilstanden skifter til OK.
- DESTROYED: Hvis systemadviseringen i pullpointet har været uafhentet over lang tid, da nedlægges pullpointet og abonnementet fjernes.
Oprydning af idlister: Oprydningsjobbet for idlister tjekker hvornår en abonnent sidst har fjernet referencen til idlisten og om der er abonnenter, der benytter idlisten. Hvis en periode overskrides og ingen abonnenter referer til idlisten, da fjernes listen. Hvis en idliste ikke har været tilknyttet et abonnement i over 45 dage slettes idlisten.
Datastruktur, Sundhedsdataregister: National Adviseringsservice (NAS)
Register properties:
National Adviserings Service (NAS) registeret indeholder masterdata til understøttelse af afkoblet system-til-system advisering ved brug af NSP.
Løsningen giver alle med adgang til NSP mulighed for at aflevere adviseringer til øvrige parter i sundhedssektoren gennem NSP. Løsningen er en realisering af et ”publish-subscribe” kommunikationsmønster, hvor adviseringskilder ”skubber” adviseringsinformationer til modtagere, dog med mulighed for at etablere et ”push-pull” scenarie gennem etablering af såkaldte ”PullPoints”.
Kilder og modtagere er indbyrdes afkoblede, idet kilderne leverer adviseringer til adviseringsservicen, og modtagerne vedligeholder et abonnement hos adviseringsservicen på de typer af adviseringer (”Topics”), de ønsker at modtage fra de respektive kilder.
Generelt gemmes ingen persondata i servicens register, dog undtaget eventuelle CPR-numre angivet i IdListcontent.
Registeret består af 4 databaser, udover whitlisting verifikation:
- Eprmapping: Indeholder informationer om mapning mellem lokale og offentlige host navne
- Subscriptions: informationer om abonnementer og ID-lister
- Pullpoints: information om pullpoints, uafhentede adviseringer, gemte response til getMessages med henblik på gensendelse samt statistik
- NotifyQueue: indeholder køen (JMS Hornetq) af ubehandlede adviseringer modtaget fra adviserings kilder
Entitetsbeskrivelser
Getmessagesresponse
Getmessagesresponse indeholder de sendte svar på operationen
Objektet indeholder informationen:
--------------------------------------
`id`
`message` -- Indeholder Notify-elementet fra svaret fra getMessages i rå xml. Gemmes som en varchar. Dette begrænser størrelsen til 16MB. Dette betyder at hvis adviseringerne der hentes alle er de maksimale 65KB, så kan denne række kun indeholde ca. 256 adviseringer.
`getmessages_request_digest` -- Base 64-encoded værdi af et SHA1-digest på hele SOAP-beskeden for GetMessages-requestet.
`linking_message_id` -- MessageID i DGWS-headerens Linking-element fra det oprindelige response. Dette MessageID skal genanvendes i response sendt som gensendelse.
`creation_time` -- Tidspunktet for svarets første anvendelse svarende til dets oprettelse.
Hosts
Mapning mellem lokale hostnavne (på ’indersiden’ af adviseringsservice) og offentlige hostnavne (på ’ydersiden’ – set fra adviseringsmodtagere).
Indeholder information, der gør det muligt at mappe et service End Point Reference (EPR) fra det faktiske EPR til et logisk. Det vil komme til anvendelse ved registrering af PullPoints, opslag på PullPoint og ved registrering af abonnementer:
- Ved oprettelse af PullPoint skal der ske en mapning, således at tilgang til disse PullPoints kan ske gennem proxy. Servere der anvendes til PullPoint skal registreres i EPRMapping, således der ved oprettelse af et PullPoint kan returneres meningsfyldt EPR.
- Ved videresendelse af adviseringer med tilknyttet abonnement fra NotificationBroker til PullPoints, skal det være muligt at udpege logisk server navn for PullPoint servicen ud fra det EPR for et PullPoint, der er angivet i et abonnement. Servere der anvendes til PullPoints skal være registreres i EPRMapping, således der altid kan ske opslag af logisk servernavn, der udpeger PullPoint servicen (ikke den enkelte server, der tilbyder servicen).
- Ved oprettelse af abonnement skal der ske en mapning af det EPR, der returneres, således at tilgang til nedlæggelse af abonnement kan ske via proxy. Servere der anvendes til SubscriptionManager servicen skal registreres i EPRMapping, således, der kan returneres meningsfuldt EPR.
Objektet indeholder informationen:
--------------------------------------
logic_host_id -- Det logiske id for NSP, anvendt i pullpoint logisk EPR
public_logic_host -- Den offentlige del af pullpoint EPR adresse
internal_logic_host -- En del af pullpoint EPR adresse, der erstatter den offentlige del for at skabe en pullpoint EPR adresse, der kan tilgås fra indersiden af adviseringsservicen.
local_host -- Hostname for en host, hvorpå PullPointFactory-service kører.
IDlist
IDlist indeholder information om de oprettede idlister.
Inden et modtagersystem opretter et abonnement skal der oprettes en id-liste, der angiver hvilke entiteter der ønskes adviseringer omkring. Bemærk at begrebet id-liste er fastlagt og defineret af NAS i modsætning til f.eks. pullpoint og abonnement, som er generelle WS-Notification begreber.
En id-liste har et navn, en enkelt type og et antal id'er. Navnet på id-listen skal bruges når denne skal anvendes i et abonnoment, vedligeholdes eller evt. senere nedlægges igen. Navnet bør være unikt nok til at undgå konflikter med andre modtagersystemer og bør være opbygget således at det er læseligt i.f.m. support og fejlsøgning. De enkelte id'er er strenge, hvis format beskrives af idTypen. Mulige idTyper bestemmes af det kildesystem der ønskes adviseringer fra.
En id-liste oprettes via den tilhørende Idlist service
Objektet indeholder informationen:
--------------------------------------
`id`
`name` -- Idlistens navn. Hvis den bliver oprettet indirekte via operationen subscribe vil denne være en UUID
`id_type` -- Typen af id'er, listen indeholder. Typen er defineret på idlist fremfor idlistcontent da dette gør opslag hurtigere, men dette begrænser lister til kun at kunne indeholde én type id'er.
`owner_id` -- Id for ejeren af pullpointet. Dette id er taget fra "Den Gode WebService" header, en sammensætning af InvokerId og ITSystemName.
`description` -- Ikke obligatorisk streng som beskriver idlisten
`delete_on_unsubscribe` -- Denne værdi er true hvis idlisten er oprettet indirekte via operationen subscribe. Dette indikerer at idlisten skal slettes når unsubscribe bliver kaldt
`opt_lock` -- Række brugt af JPA til optimistisk låsning.
last_unsubscribe -- Dato for seneste kald til unsubscribe fra en refereret abonnent. Benyttes af oprydningsjobbet i Idlist servicen til at finde ubrugte idlists.
Idlistcontent
idlistcontent tabellen indeholder de konkrete id-værdier relateret en Idlist
Objektet indeholder informationen:
--------------------------------------
`id`
`id_value` -- Den konkrete id
`idlist_id` -- Foreign key til idlist tabellen. Dette er et many-to-one forhold, hvor en idlist indeholder mange idlistcontents
Message
Message indeholder de uafhentet adviseringer
Adviseringer slettes fra PullPoints databasen, når de er hentet af PullPoint ejer.
Objektet indeholder informationen:
--------------------------------------
`id`
`message` -- Indeholder den rå xml-advisering som en varchar. Rækken er begrænset til 65KB
`creation_time` -- Tidspunktet adviseringen er modtaget fra Notification Brokeren. Denne information bruges til at sende den ældste besked først.
`pullpoint_id` -- Dette er en foreign key til pullpoint tabellen. Dette er et many-to-one forhold, hvor et pullpoint har mange messages.
NotifyQueue
JMS queue (Hornetq), indeholder køen af ubehandlede adviseringer modtaget fra adviserings kilde.
Pullpoint
pullpoint indeholder data om de eksisterende pullpoints
Objektet indeholder informationen:
--------------------------------------
`id`
`pullpoint_id` -- Det unikke id genereret til pullpointet. Består af værdien fra rækken logic_host_id i eprmapping database og en genereret streng. Eksempel: JEJUNWORKSTATION-ID-13b75adf17c-24-0
`owner_id` -- Id for ejeren af pullpointet. Dette id er taget fra "Den Gode WebService" header, en sammensætning af InvokerId og ITSystemName.
`url` -- Url'en til pullpointet
Statistics
Statistics indeholder information om pullpoints, der skal bruges til at lave statistik om brugen af disse
Objektet indeholder informationen:
--------------------------------------
`id`
`used_last_time` -- Tidspunktet getMessages sidst blev kaldt på det pågældende pullpoint. Dette kan bruges til at finde ubrugte pullpoints.
`creation_time` -- Tidspunktet for oprettelsen af pullpointet.
`messages_retrieved_count` -- Antallet af adviseringer hentet i pullpointets levetid.
`pullpoint_id` -- Dette er ikke en foreign key til pullpoint, som i pullpoints.message. Dette er den faktiske pullpoint_id fra pullpoints.pullpoint. Dette bliver brugt til at forbinde de to tabeller uden at have dem i samme skema. (som de nu faktisk er ...)
`owner_id` -- Id for ejeren af pullpointet. Dette id er taget fra "Den Gode WebService" header, en sammensætning af InvokerId og ITSystemName. Dette er den samme værdi som i owner_id fra pullpoints.pullpoint. Denne information skal gemmes efter pullpointet bliver nedlagt.
`url` -- Url'en til pullpointet. Dette er den samme værdi som i url fra pullpoints.pullpoint. Denne information skal gemmes efter pullpointet bliver nedlagt.
`destroyed_time` -- Tidspunktet for nedlæggelsen af pullpointet.
`opt_lock` -- Række brugt af JPA til optimistisk låsning.
state -- Nuværende tilstand for pullpointet { OK, WARNING, DESTROYED }. State benyttes af oprydningsjobbet kørende fra PullpointFactory.
Subscription
Tabellen subscription indeholder information om subscriptions
Objektet indeholder informationen:
--------------------------------------
`id`
`subscription_id` -- Det unikke id genereret til subscription.
`subscription_reference` -- Endpoint reference til brug ved unsubscribe
`consumer_reference` -- Endpoint reference til pullpointet, så notification brokeren ved hvor den skal sende adviseringen hen
`topic` -- Topic som der skal filtreres på til denne subscription.
`owner_id` -- Id for ejeren af denne subscription. Dette id er taget fra "Den Gode WebService" header, en sammensætning af InvokerId og ITSystemName.
`state` -- Subscriptionens tilstand. Kan enter være OK eller FAILED. Subscriptions med tilstanden FAILED vil ikke modtage adviseringer mere. Alle subscriptions starter i tilstanden OK og skifter til FAILED hvis notification brokeren ikke kan foretage rollback for at håndtere manglende kontakt med det tilhørende pullpoint
`idlist_id` -- Foreign key til idlist tabellen. Dette er et many-to-one forhold, hvor en idlist indeholder mange Subscriptions
Whitelist config (NAS)
Whitelist indeholder de CVR som er whitelisted til brug for National Adviserings Service (NAS)
- service_key
+ NAS & NAS2:
++ 'dk.nsi.nas.idlist'
++ 'dk.nsi.nas.pullpoint'
++ 'dk.nsi.nas.pullpointfactory'
++ 'dk.nsi.nas.subscriptionmanager'
- service_type -- eventuel uddybende forklaring (f.eks. Test, Udv, prod)
- cvr -- CVR nummer
- comment -- Her anføres NSP Jira nummer som relaterer den enkelte whitelisting
Tabelbeskrivelser
Tabel: getmessagesresponse
CREATE TABLE IF NOT EXISTS `pullpoints`.`getmessagesresponse` (
`id` INT NOT NULL AUTO_INCREMENT ,
`message` MEDIUMTEXT NOT NULL ,
`getmessages_request_digest` VARCHAR(128) NOT NULL ,
`linking_message_id` VARCHAR(128) NOT NULL ,
`creation_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ,
PRIMARY KEY (`id`) ,
UNIQUE INDEX `getmessages_request_digest_UNIQUE` (`getmessages_request_digest` ASC) )
ENGINE = InnoDB;
CREATE INDEX creation_time_idx ON pullpoints.getmessagesresponse (creation_time ASC);
Tabel: hosts
CREATE TABLE IF NOT EXISTS `eprmapping`.`hosts` (
logic_host_id VARCHAR(30) NOT NULL,
public_logic_host VARCHAR(128) NOT NULL,
internal_logic_host VARCHAR(128) NOT NULL,
local_host VARCHAR(128) NOT NULL,
PRIMARY KEY (logic_host_id, public_logic_host, internal_logic_host, local_host),
UNIQUE INDEX `idx_local_host` ( `local_host` ) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;
Tabel: idlist
CREATE TABLE IF NOT EXISTS `subscriptions`.`idlist` (
`id` INT NOT NULL AUTO_INCREMENT ,
`name` VARCHAR(128) NOT NULL ,
`id_type` VARCHAR(128) NOT NULL ,
`owner_id` VARCHAR(128) NOT NULL ,
`description` VARCHAR(512) NULL ,
`delete_on_unsubscribe` TINYINT(1) NOT NULL DEFAULT false ,
`opt_lock` BIGINT NOT NULL ,
last_unsubscribe DATE NULL,
PRIMARY KEY (`id`) ,
UNIQUE INDEX `id_UNIQUE` (`id` ASC) ,
UNIQUE INDEX `name_UNIQUE` (`name` ASC) )
ENGINE = InnoDB;
CREATE INDEX nsp_perf_idlist1 ON subscriptions.idlist (id ASC, id_type ASC);
CREATE INDEX last_unsubscribe_idx ON subscriptions.idlist (last_unsubscribe ASC);
Tabel: idlistcontent
CREATE TABLE IF NOT EXISTS `subscriptions`.`idlistcontent` (
`id` INT NOT NULL AUTO_INCREMENT ,
`id_value` VARCHAR(255) NOT NULL ,
`idlist_id` INT NOT NULL ,
PRIMARY KEY (`id`, `idlist_id`) ,
INDEX `fk_idlistcontent_idlist_idx` (`idlist_id` ASC) ,
UNIQUE INDEX `id_UNIQUE` (`id` ASC) ,
CONSTRAINT `fk_idlistcontent_idlist`
FOREIGN KEY (`idlist_id` )
REFERENCES `subscriptions`.`idlist` (`id` )
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB;
CREATE INDEX nsp_perf_idlistcontent1 ON subscriptions.idlistcontent (id_value ASC, idlist_id ASC);
Tabel: message
CREATE TABLE IF NOT EXISTS `pullpoints`.`message` (
`id` BIGINT NOT NULL AUTO_INCREMENT ,
`message` TEXT NOT NULL ,
`creation_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
`pullpoint_id` INT NOT NULL ,
PRIMARY KEY (`id`, `pullpoint_id`) ,
UNIQUE INDEX `id_UNIQUE` (`id` ASC) ,
INDEX `FK_messages_pullpoints_idX` (`pullpoint_id` ASC) ,
CONSTRAINT `FK_messages_pullpoints`
FOREIGN KEY (`pullpoint_id` )
REFERENCES `pullpoints`.`pullpoint` (`id` )
ON DELETE CASCADE
ON UPDATE NO ACTION)
ENGINE = InnoDB;
Queue: NotifyQueue
Det er en forudsætning, at HornetQ er konfigureret i den aktuelle applikationsserver, hvor NotificationBroker service skal deployeres. I følgende vises hvordan Standalone.xml opdateres med HornetQ konfigurationen, men opsætningen er også mulig igennem WildFly Administration Console. Markeret tekst er opsætningen specifikt til Adviseringsservice.
Hermed sættes Notify køen op og redelivery uden begrænsning på antal, med en forsinkelse givet i millisekunder mellem hvert redelivery-forsøg.
Bemærk at <max-size-bytes> beskriver max størrelsen i memory og tallet er bedste gæt.
Når <max-size-bytes> nås fortsætter paging på disk i størrelse af <page-size-bytes> pr. fil.
Desuden bør følgende fremhævede udsnit indsættes for at aktivere MDB (Message Driven Beans).
<subsystem xmlns="urn:jboss:domain:ejb3:2.0">
....
<mdb>
<resource-adapter-ref resource-adapter-name="${ejb.resource-adapter-name:hornetq-ra.rar}"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
....
</subsystem>
I toppen af standalone filen under extensions elementet indsættes:
<extension module="org.jboss.as.messaging"/>
<subsystem xmlns="urn:jboss:domain:messaging:2.0">
<hornetq-server>
<security-enabled>true</security-enabled>
<journal-file-size>102400</journal-file-size>
<connectors>
<http-connector name="http-connector" socket-binding="http">
<param key="http-upgrade-endpoint" value="http-acceptor"/>
</http-connector>
<http-connector name="http-connector-throughput" socket-binding="http">
<param key="http-upgrade-endpoint" value="http-acceptor-throughput"/>
<param key="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm" server-id="0"/>
</connectors>
<acceptors>
<http-acceptor http-listener="default" name="http-acceptor"/>
<http-acceptor http-listener="default" name="http-acceptor-throughput">
<param key="batch-delay" value="50"/>
<param key="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
</acceptors>
<security-settings>
<security-setting match="#">
<permission type="send" roles="guest"/>
<permission type="consume" roles="guest"/>
<permission type="createNonDurableQueue" roles="guest"/>
<permission type="deleteNonDurableQueue" roles="guest"/>
</security-setting>
</security-settings>
<address-settings>
<address-setting match="jms.queue.NotifyQueue">
<redelivery-delay>30000</redelivery-delay>
<max-delivery-attempts>-1</max-delivery-attempts>
<max-size-bytes>1048576000</max-size-bytes>
<page-size-bytes>10485760</page-size-bytes>
<address-full-policy>PAGE</address-full-policy>
</address-setting>
</address-settings>
<jms-connection-factories>
<connection-factory name="InVmConnectionFactory">
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/ConnectionFactory"/>
</entries>
</connection-factory>
<connection-factory name="RemoteConnectionFactory">
<connectors>
<connector-ref connector-name="http-connector"/>
</connectors>
<entries>
<entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
</entries>
</connection-factory>
<pooled-connection-factory name="hornetq-ra">
<transaction mode="xa"/>
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/JmsXA"/>
<entry name="java:jboss/DefaultJMSConnectionFactory"/>
</entries>
</pooled-connection-factory>
</jms-connection-factories>
<jms-destinations>
<jms-queue name="NotifyQueue">
<entry name="java:/jms/queue/NotifyQueue"/>
</jms-queue>
</jms-destinations>
</hornetq-server>
</subsystem>
Tabel: pullpoint
CREATE TABLE IF NOT EXISTS `pullpoints`.`pullpoint` (
`id` INT NOT NULL AUTO_INCREMENT ,
`pullpoint_id` VARCHAR(128) NOT NULL ,
`owner_id` VARCHAR(128) NOT NULL ,
`url` VARCHAR(128) NOT NULL ,
PRIMARY KEY (`id`) ,
UNIQUE INDEX `id_UNIQUE` (`id` ASC) ,
UNIQUE INDEX `pullpoint_id_UNIQUE` (`pullpoint_id` ASC) )
ENGINE = InnoDB;
Tabel: statistics
CREATE TABLE IF NOT EXISTS `pullpointstatistics`.`statistics` (
`id` INT NOT NULL AUTO_INCREMENT ,
`used_last_time` TIMESTAMP NULL ,
`creation_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ,
`messages_retrieved_count` BIGINT NOT NULL DEFAULT 0 ,
`pullpoint_id` VARCHAR(128) NOT NULL ,
`owner_id` VARCHAR(128) NOT NULL ,
`url` VARCHAR(128) NOT NULL ,
`destroyed_time` TIMESTAMP NULL ,
`opt_lock` BIGINT NOT NULL ,
`state` varchar(10) NOT NULL DEFAULT 'OK'
PRIMARY KEY (`id`, `pullpoint_id`) ,
UNIQUE INDEX `id_unique` (`id` ASC) ,
UNIQUE INDEX `pullpoint_id_unique` (`pullpoint_id` ASC) )
ENGINE = InnoDB;
CREATE INDEX statistics_last_used_state_idx ON pullpointstatistics.statistics (used_last_time ASC, state ASC);
Tabel: subscription
CREATE TABLE IF NOT EXISTS `subscriptions`.`subscription` (
`id` INT NOT NULL AUTO_INCREMENT ,
`subscription_id` VARCHAR(128) NOT NULL ,
`subscription_reference` VARCHAR(128) NOT NULL ,
`consumer_reference` VARCHAR(128) NOT NULL ,
`topic` VARCHAR(128) NOT NULL ,
`owner_id` VARCHAR(128) NOT NULL ,
`state` VARCHAR(45) NOT NULL ,
`idlist_id` INT NULL DEFAULT NULL ,
PRIMARY KEY (`id`, `subscription_id`) ,
UNIQUE INDEX `id_UNIQUE` (`id` ASC) ,
UNIQUE INDEX `subscription_id_UNIQUE` (`subscription_id` ASC) ,
INDEX `fk_subscription_idlist1_idx` (`idlist_id` ASC) ,
CONSTRAINT `fk_subscription_idlist1`
FOREIGN KEY (`idlist_id` )
REFERENCES `subscriptions`.`idlist` (`id` )
ON DELETE RESTRICT
ON UPDATE CASCADE)
ENGINE = InnoDB;
CREATE INDEX nsp_perf_subscription1 ON subscriptions.subscription (idlist_id ASC, state ASC, topic ASC);
Tabel: whitelist_config
CREATE TABLE IF NOT EXISTS whitelist.whitelist_config (
service_key VARCHAR(50) NOT NULL,
service_type VARCHAR(20) NOT NULL,
cvr CHAR(8) NOT NULL,
comment VARCHAR(100),
PRIMARY KEY (service_key, service_type, cvr))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;| id | bigint(10) | NO | PRI | NULL | |
| name | varchar(255) | NO | | NULL | |
| node | varchar(255) | YES | | NULL | |
| serviceUrl | varchar(255) | YES | | NULL | |
| useProxy | tinyint(1) | YES | | NULL | |
| timeout | bigint(20) | YES | | NULL | |
| idcardmaxage | int(11) | YES | | NULL | |
| doNotVerifySSLHostName | tinyint(1) | YES | | NULL | |
| wsaHeadersProcessing | varchar(32) | YES | | NULL | |
Teknologibeskrivelse
...