INDHOLD
Beskrivelse
National Adviseringsservice (NAS) 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 (NAS) - Leverancebeskrivelse
Forretningsanvendelse
Applikationsbeskrivelse
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;