AANSLUITEN BRONHOUDERS OP DE LANDELIJKE VOORZIENING WOZ MET OPENTUNNEL 1.6

Transcriptie

1 AANSLUITEN BRONHOUDERS OP DE LANDELIJKE VOORZIENING WOZ MET OPENTUNNEL 1.6

2 INHOUDSOPGAVE Inhoudsopgave... 2 Inleiding... 3 Digikoppeling... 3 COMMUNICATIE TUSSEN BRONHOUDER/GEMEENTE EN LV- WOZ... 3 EBMS COLLABORATION PROTOCOL AGREEMENT (CPA)... 3 AANLEVEREN BIJHOUDINGSBERICHTEN AAN OPENTUNNEL AANGEBODEN SERVICES LV- WOZ CONFIGURATIE OPENTUNNEL BIJ BRONHOUDER TUNNEL CONFIGURATIE BIJ BRONHOUDER LADEN VAN CPA IN OPENTUNNEL ARCHIVERING VAN BERICHTEN... 27

3 INLEIDING OpenTunnel is een integratiemakelaar en enterprise servicebus oplossing met ondersteuning voor alle Digikoppeling protocollen. Hieronder wordt uit de doeken gedaan hoe bronhouders via OpenTunnel met hun systemen kunnen aansluiten op de Landelijke Voorziening WOZ. Bijzonder is dat de Landelijke Voorziening zelf ook is gerealiseerd met OpenTunnel. Er is ook een aansluitdocument voor afnemers van de LV-WOZ in ontwikkeling. Deze richt zich op het bevragen van de LV-WOZ via ebms (asynchrone bevragingen met indirecte leveringen), WUS (synchrone bevragingen met een onmiddellijk antwoord) en de inzet van de OpenTunnel Grote Berichten Standaard Plugin voor het afleveren van de response op asynchrone bevragingen. Een bronhouder kan ook afnemer zijn, dus ook dit document voor afnemers kan relevant zijn. Maar dit document richt zich specifiek op het aanleveren van gegevens aan de LV-WOZ en is bedoeld voor leveranciers van WOZ systemen, gemeenten met zelfgebouwde WOZ systemen en geïnteresseerden die inzicht willen krijgen hoe OpenTunnel systemen kan koppelen aan Landelijke Voorzieningen. DIGIKOPPELING Digikoppeling (voorheen de Overheidsservicebus) is de 'postbode' voor de overheid. Digikoppeling bestaat uit een set standaarden voor elektronisch berichtenverkeer tussen overheidsorganisaties. Door deze eoverheid standaarden te adopteren kunt u digitaal berichten uitwisselen met collega-overheidsorganisaties. Landelijke registraties zoals het Omgevings Loket Online en de Landelijke Voorziening WOZ maken gebruik van Digikoppeling voor de gegevensuitwisseling. Digikoppeling is een protocolfamilie die nu bestaat uit ebms 2.0, WUS en de Grote Berichten Standaard. De Landelijke Voorziening WOZ (LV- WOZ) maakt gebruik van al deze protocollen. COMMUNICATIE TUSSEN BRONHOUDER/GEMEENTE EN LV-WOZ Tussen bronhouder en LV wordt voor het aanleveren van gegevens gebruik gemaakt van betrouwbare uitwisseling door middel van het ebms 2.0 protocol. COMMUNICATIE TUSSEN AFNEMER EN LV-WOZ Afhankelijk van het type afnemer staan er meerdere kanalen ter beschikking om de LV-WOZ te bevragen. Een bronhouder kan natuurlijk ook optreden als afnemer. Tussen afnemer en LV wordt voor asynchrone bevragingen gebruik gemaakt van betrouwbare uitwisseling door middel van het ebms 2.0 protocol. Synchrone bevragingen (vraag met een direct antwoord) gaan via webservices volgens het Digikoppeling WUS 2.0 profiel. Asynchrone (massale) bevragingen gaan op een bijzondere manier. De vraag wordt zoals hierboven gesteld aangeleverd via ebms. Het antwoord wordt asynchroon in de vorm van een bestand geleverd via de Grote Berichten Standaard. Een gemeente kan zich eventueel ook abonneren op de levering van WOZ mutaties die (waarschijnlijk) via Digilevering gerealiseerd zal worden. Indien een bronhouder de uitvoering van de WOZ administratie heeft uitbesteed aan een samenwerkingsverband kan toch worden beschikt over WOZ gegevens via massale bevragingen of een Digilevering abonnement. Voor afnemer communicatie met de LV-WOZ op basis van OpenTunnel is een ander document beschikbaar: Aansluiten afnemers op de Landelijke Voorziening WOZ met OpenTunnel 1.6.

4 EBMS COLLABORATION PROTOCOL AGREEMENT (CPA) Het berichtenverkeer tussen bronhouders en de landelijke voorziening wordt gereguleerd door een contract tussen twee partijen, de CPA. Hier worden de berichtsoorten en de eisen die gesteld worden aan de service gedefinieerd. Er is sprake van tweerichting verkeer, er gaan berichten van bronhouder naar LV-WOZ (dienstberichten) en tussen LV-WOZ en bronhouder (asynchrone foutberichten en verzoeken tot synchronisatie). De berichtuitwisselingen zijn gebaseerd op de WOZ berichtencatalogus zoals gedefinieerd door de Waarderingskamer. In de berichtcatalogus zijn ze gedefinieerd als WSDL. Ten behoeve van de communicatie tussen LV en bronhouder zijn er drie WSDL s van toepassing: woz0312_ontvangasynchroon_lv_mutatie_gemeente.wsdl woz0312_ontvangasynchroon_lv_mutatie_lv.wsdl woz0312_ontvangasynchroon_aansluitproces.wsdl Om de beheerinspanning te reduceren zijn de berichttypen zoals gedefinieerd in de WSDL in één CPA opgenomen. Alleen voor het gebruik van asynchrone leveringen en abonnementen op mutaties via Digilevering zijn eventueel nog extra CPA s nodig. Beide partijen in de twee-zijdige communicatie (LV en bronhouder) importeren de CPA en realiseren daarmee de verbinding, afgezien van de eisen die worden gesteld aan de netwerkverbindingen. De CPA is opgezet volgens het ebms 2.0 Digikoppeling profiel osb-rm. Dit houdt in dat de berichten verstuurd worden met een betrouwbaar profiel. Het partyid (OIN) in CPA en ebms bericht identificeert de bronhouder. Het TLS certificaat waarmee de beveiligde HTTPS sessie wordt opgezet identificeert de zender. De zender mag dus ook een andere partij zijn, bijvoorbeeld een samenwerkingsverband. De zender wordt herkend aan de hand van de OIN van deze partij in het certificaat. In onderstaande tabel worden de berichttypen en profielen opgesomd: Berichtnaam Van Naar Digikoppeling profiel nnpsa01 Gemeente LVWOZ osb-rm nnpsa03 Gemeente LVWOZ osb-rm npssa01 Gemeente LVWOZ osb-rm npssa03 Gemeente LVWOZ osb-rm swosa01-lvwoz Gemeente LVWOZ osb-rm swosa03-lvwoz Gemeente LVWOZ osb-rm swosh01-lvwoz Gemeente LVWOZ osb-rm swosh03-lvwoz Gemeente LVWOZ osb-rm vessa01 Gemeente LVWOZ osb-rm vessa03 Gemeente LVWOZ osb-rm wozsa01-lvwoz Gemeente LVWOZ osb-rm wozsa03-lvwoz Gemeente LVWOZ osb-rm wozsh01-lvwoz Gemeente LVWOZ osb-rm wozsh03-lvwoz Gemeente LVWOZ osb-rm wrdsa01-lvwoz Gemeente LVWOZ osb-rm wrdsa03-lvwoz Gemeente LVWOZ osb-rm wrdsh01-lvwoz Gemeente LVWOZ osb-rm wrdsh03-lvwoz Gemeente LVWOZ osb-rm BSKMB_Di01 Gemeente LVWOZ osb-rm BSWO_Di01 Gemeente LVWOZ osb-rm BWOZ_Di01 Gemeente LVWOZ osb-rm IBB_Di01 Gemeente LVWOZ osb-rm MBAG_Di01 Gemeente LVWOZ osb-rm MBE_Di01 Gemeente LVWOZ osb-rm MBG_Di01 Gemeente LVWOZ osb-rm MEL_Di01 Gemeente LVWOZ osb-rm

5 MHEF_Di01 Gemeente LVWOZ osb-rm MKEN_Di01 Gemeente LVWOZ osb-rm MKOZ_Di01 Gemeente LVWOZ osb-rm MSUB_Di01 Gemeente LVWOZ osb-rm NBSK_Di01 Gemeente LVWOZ osb-rm OSWO_Di01 Gemeente LVWOZ osb-rm OWOZ_Di01 Gemeente LVWOZ osb-rm UBB_Di01 Gemeente LVWOZ osb-rm VBSK_Di01 Gemeente LVWOZ osb-rm WASWO_Di01 Gemeente LVWOZ osb-rm WAWOZ_Di01 Gemeente LVWOZ osb-rm WGEM_Di01 Gemeente LVWOZ osb-rm WWSP_Di01 Gemeente LVWOZ osb-rm leegdatabasedi01 (alleen CT, AT,ET) Gemeente LVWOZ osb-rm leegdatabasedu01 (alleen CT, AT,ET) LVWOZ Gemeente osb-rm nnpsa03 LVWOZ Gemeente osb-rm npssa03 LVWOZ Gemeente osb-rm swosh03-lvwoz LVWOZ Gemeente osb-rm vessa03 LVWOZ Gemeente osb-rm wozsh03-lvwoz LVWOZ Gemeente osb-rm wrdsh03-lvwoz LVWOZ Gemeente osb-rm StUF:Fo01 LVWOZ Gemeente osb-rm StUF:Fo03 LVWOZ Gemeente osb-rm Berichtuitwisseling tussen bronhouder/gemeente en LV-WOZ Bij het vaststellen van de Digikoppeling-ebMS Servicespecificatie zijn lessen getrokken uit ervaringen met andere Landelijke Voorzieningen. Zo is de geldigheid van de CPA bepaald op 10 jaar. Dit betekent in de praktijk dat de PKI-o certificaten de levensduur van de servicerelatie bepalen (standaard 3 jaar). Bij het vervangen van deze certificaten hoeft de CPA niet te worden aangepast. Dit vermindert de beheerlast aanzienlijk. Via een aangepaste persistduration van 4 dagen zal een ebms adapter gedurende 4 dagen proberen een bericht alsnog af te leveren. Dit betekent dat indien onverhoopt een Digikoppeling adapter niet beschikbaar is tijdens een weekend het bericht na een herstart alsnog zal worden afgeleverd. Een van de verplichte onderdelen van een CPA vormen de certificaten die een rol spelen bij de uitwisseling van de berichten. Deze certificaten kunnen worden geïmporteerd in OpenTunnel als onderdeel van de CPA import of kunnen separaat worden geladen en dus ook worden vervangen zonder dat de CPA wordt geraakt. Dit sluit aan op de best practices van Digikoppeling zoals door Logius is geadviseerd. De bouwstenen voor een CPA volgens Digikoppeling zijn een ebms Service Specificatie en een ebms consumerspecificatie. De service specificaties zijn door JNet gemaakt en gepubliceerd in het Digikoppeling serviceregister bij Logius onder de bedrijfservice naam WDK.WOZ0312.GEM.ontvangAsynchroon. De ebms consumerspecificatie moet worden gemaakt ten behoeve van iedere bronhouder. Hieronder tonen wij een voorbeeld: <?xml version="1.0" encoding="utf-8"?> <osb-ebms-consumer-specificatie> <params> <partner name="gemeente"> <parameter name="cpaid" required="false"></parameter> <parameter name="startdate" required="false"> t00:00:00z</parameter> <parameter name="enddate" required="false"> t00:00:00z</parameter> <parameter name="partyname" required="true"/> <parameter name="partyid" required="true"/>

6 <parameter name="partyidtype" required="false"/> <parameter name="partyref" required="false"/> <parameter name="endpointuri" required="true"/> <parameter name="endpointurihttp" required="false"/> <parameter name="clientcert" required="true"/> <parameter name="servercert" required="true"/> <parameter name="retries" required="false"/> <parameter name="retryinterval" required="false"/> <parameter name="persistduration" required="false"/> </partner> </params> <parameters name="gemeente"> <! hier uw Gemeentenaam --> <parameter name="partyname">onsdorp</parameter> <! hier uw OIN --> <parameter name="partyid"> </parameter> <parameter name="partyidtype">urn:osb:oin</parameter> <parameter name="partyref"> <! De URL voor acknowledgements en StUF foutberichten --> <parameter name="endpointuri"> <parameter name="endpointurihttp"> /ebms/lv-woz/intg</parameter> <! Deze waarden worden niet meegenomen in de CPA Creatievoorziening --> <parameter name="startdate"> t00:00:00z</parameter> <parameter name="enddate"> t00:00:00z</parameter> <parameter name="retries">32</parameter> <parameter name="retryinterval">pt3h</parameter> <! De ebms adapter blijft het 4 dagen proberen om de gegevens te sturen --> <parameter name="persistduration">p4d</parameter> <parameter name="servercert"> <! Plak hierin de keyinfo uit de CPA ceratievoorziening --> <KeyInfo xmlns=" </KeyInfo> </parameter> <parameter name="clientcert"> <KeyInfo xmlns=" </KeyInfo> </parameter> </parameters> </osb-ebms-consumer-specificatie>

7 Een van de voorwaarden voor een bronhouder om toegang te krijgen tot de LV-WOZ is het verkrijgen van een CPA. Deze wordt aangevraagd bij de CPA creatievoorziening van Logius ( De beheerder van de Landelijke Voorzieningen krijgt dan via mail ook een kopie van de CPA. Indien de CPA bij zowel bronhouder / samenwerkingsverband als Landelijke Voorziening wordt geladen is de verbinding tot stand gebracht (afgezien van allerlei maatregelen op netwerkniveau zoals inregelen firewall). Toegang tot de Landelijke Voorziening kan zowel via DigiNetwerk als via Internet. Hiervoor zijn separate CPA sjablonen (Servicespecificaties) beschikbaar bij de creatievoorziening. Voordat een organisatie als zendende partij toegang kan krijgen tot de conformiteitstoetsdienst, externe testdient voor leveranciers, aansluittoetsdienst of normale dienst in de productieomgeving dient de organisatie te beschikken over een productie PKI-Overheids servercertificaat met daarin opgenomen een HandelsRegisterNummer (HRN) of OverheidsIdentificatieNummer (OIN) van de organisatie. Meer informatie over Digikoppeling en de verkrijging van een OIN kunt u vinden op de volgende URL: Meer informatie over het aanvragen van CPA s kunt u vinden op de volgende URL: Hoofdstuk 5 bespreekt de stappen die een service requester dient uit te voeren. Indien een bronhouder de WOZ uitvoering heeft gedelegeerd aan een samenwerkingsverband dan is het certificaat in de CPA die van het samenwerkingsverband. De laatste partij verzendt en ontvangt de berichten. Ook het transport-endpoint in de CPA is die van het samenwerkingsverband! In de regel worden bovenstaande activiteiten door de leverancier (JNet) uitgevoerd die hier veel ervaring mee heeft. In het kort de stappen uit te voeren door een service requester (bronhouder/leverancier): 1. KeyInfo uit certificaat halen via URL 2. Aanpassen sjabloon t.b.v. Digikoppeling ebms Consumer specificatie. De keyinfo uit de vorige stap moet worden geplakt in het bestand bij de elementen ClientCert en ServerCert. 3. Het aanvragen van de CPA via URL Voor de LV-WOZ dienen de volgende stappen worden uitgevoerd: a. Het invoeren van het ServiceID. Deze kunnen worden gevonden in het Digikoppeling ServiceRegister. Per omgeving zijn er voor de verschillende diensten en mogelijke wijze van toegang (internet en diginetwerk) Digikoppeling ebms Servicespecificaties opgenomen. Dit aantal kan oplopen tot 12. De lijst met service-ids wordt ook hieronder getoond. Ze zijn nog niet allemaal beschikbaar in het Digikoppeling serviceregister. ServiceID Omgeving Dienst Verbinding WDK.WOZ0312.GEM.ontvangAsynchroon.INTG.NORMAAL.INET Integratie Normaal (standaard dienst) internet WDK.WOZ0312.GEM.ontvangAsynchroon.INTG.CTO.INET Integratie Conformiteittoets internet

8 WDK.WOZ0312.GEM.ontvangAsynchroon.INTG.ATO.INET Integratie Aansluittoets internet WDK.WOZ0312.GEM.ontvangAsynchroon.FTO.NORMAAL.INET Functionele test Normaal (standaard dienst) internet Functionele Conformiteittoets internet WDK.WOZ0312.GEM.ontvangAsynchroon.FTO.CTO.INET test Functionele Aansluittoets internet WDK.WOZ0312.GEM.ontvangAsynchroon.FTO.ATO.INET test WDK.WOZ0312.GEM.ontvangAsynchroon.PROD.NORMAAL.INET Productie Normaal (standaard dienst) internet WDK.WOZ0312.GEM.ontvangAsynchroon.PROD.CTO.INET Productie Conformiteittoets internet WDK.WOZ0312.GEM.ontvangAsynchroon. PROD.ATO.INET Productie Aansluittoets internet WDK.WOZ0312.GEM.ontvangAsynchroon. PROD.ETO.INET Productie Leverancierstest internet WDK.WOZ0312.GEM.ontvangAsynchroon.PROD.NORMAAL.DIGINET Productie Normaal (standaard dienst) Diginetwerk WDK.WOZ0312.GEM.ontvangAsynchroon.PROD.CTO.DIGINET Productie Conformiteittoets Diginetwerk WDK.WOZ0312.GEM.ontvangAsynchroon.PROD.ATO.DIGINET Productie Aansluittoets Diginetwerk WDK.WOZ0312.GEM.ontvangAsynchroon.PROD.ETO.DIGINET Productie Leverancierstest Diginetwerk

9 b. Het selecteren van de in stap 2 voorbereide consumerspecificatie

10 c. Het vullen van de start- en eind-datum. Door een bug in de creatievoorziening wordt de geldigheidstermijn gedefinieerd in de consumer specificatie niet overgenomen. De startdatum dient vandaag te zijn, de einddatum 10 jaar in de toekomst. Zo wordt voorkomen dat een CPA elk jaar moet worden vervangen. Het certificaat is maximaal 3 jaar geldig. Het certificaat bepaalt dan tevens de geldigheidstermijn van de koppeling.

11 d. Het vullen van de juiste rolnamen: LVWOZ voor de publisher rol en gemeente voor de consumerrol e. Het invullen van uw naam en adres. Na het drukken op versturen kunt u de CPA downloaden. De publisher (Landelijke Voorziening) krijgt de CPA via toegezonden.

12

13 AANLEVEREN BIJHOUDINGSBERICHTEN AAN OPENTUNNEL OpenTunnel biedt vele opties hoe berichten aangeleverd kunnen worden. Dit speelt zowel op berichtinhoud als op protocolniveau. Op berichtniveau ondersteunt OpenTunnel standaard de volgende formaten: WOZ 3.12 StUF-XML SOAP bericht met als body WOZ 3.12 StUF-XML SOAP bericht met een WS-Addressing SOAP Header met als body WOZ 3.12 StUF-XML Indien de WS-Addressing info dezelfde action naam bevat als die nodig is in het ebms bericht kunnen deze worden overgenomen. Maar OpenTunnel kan ook geconfigureerd worden met tunnelvariabelen die de waarden uit de input koppelt aan de uitgaande ebms berichten (zie tabellen hieronder). Dit maakt het omgaan met Digikoppeling vanuit het perspectief van een belastingsysteem een stuk eenvoudiger. Een van de doelstellingen van OpenTunnel is immers de eisen die Digikoppeling stelt te verbergen voor interne systemen. Toekomstige wijzigingen in de Digikoppeling standaard zullen dan geen invloed hebben op deze systemen. In bijzondere gevallen kan OpenTunnel ook met volledig andere in en output formaten overweg waarbij OpenTunnel zorg draagt voor de omzetting naar StUFberichten. Hierbij is dan wel sprake van maatwerk waarvoor in OpenTunnel transformaties moeten worden gedefinieerd. StUF:Functie in Di01 Root element naam ebms action WOZ-BSKMB BSKMB_Di01 BSKMB_Di01 WOZ-BSWO BSWO_Di01 BSWO_Di01 WOZ-BWOZ BWOZ_Di01 BWOZ_Di01 WOZ-IBB IBB_Di01 IBB_Di01 WOZ_MBAG MBAG_Di01 MBAG_Di01 WOZ-MBE MBE_Di01 MBE_Di01 WOZ-MBG MBG_Di01 MBG_Di01 WOZ-MEL MEL_Di01 MEL_Di01 WOZ-MHEF MHEF_Di01 MHEF_Di01 WOZ-MKEN MKEN_Di01 MKEN_Di01 WOZ-MKOZ MKOZ_Di01 MKOZ_Di01 WOZ-MSUB MSUB_Di01 MSUB_Di01 WOZ-NBSK NBSK_Di01 NBSK_Di01 WOZ-OSWO OSWO_Di01 OSWO_Di01 WOZ-OWOZ OWOZ_Di01 OWOZ_Di01 WOZ-UBB UBB_Di01 UBB_Di01 WOZ-VBSK VBSK_Di01 VBSK_Di01 WOZ-WASWO WASWO_Di01 WASWO_Di01 WOZ-WAWOZ WAWOZ_Di01 WAWOZ_Di01 WOZ-WGEM WGEM_Di01 WGEM_Di01 WOZ-WWSP WWSP_Di01 WWSP_Di01 aansluitproces_leegdatabase leegdatabasedi01 leegdatabasedi01 MAPPING StUF dienstberichten naar SOAP / ebms actions Root element naam nnpsa01 nnpsa03 ebms action nnpsa01 nnpsa03

14 npssa01 npssa01 npssa03 npssa03 swosa01-lvwoz swosa01-lvwoz swosa03-lvwoz swosa03-lvwoz swosh01-lvwoz swosh01-lvwoz swosh03-lvwoz swosh03-lvwoz vessa01 vessa01 vessa03 vessa03 wozsa01-lvwoz wozsa01-lvwoz wozsa03-lvwoz wozsa03-lvwoz wozsh01-lvwoz wozsh01-lvwoz wozsh03-lvwoz wozsh03-lvwoz wrdsa01-lvwoz wrdsa01-lvwoz wrdsa03-lvwoz wrdsa03-lvwoz wrdsh01-lvwoz wrdsh01-lvwoz wrdsh03-lvwoz wrdsh03-lvwoz nnpsa03 nnpsa03 npssa03 npssa03 swosh03-lvwoz swosh03-lvwoz vessa03 vessa03 wozsh03-lvwoz wozsh03-lvwoz wrdsh03-lvwoz wrdsh03-lvwoz Fo01Bericht StUF:Fo01 Fo03Bericht StUF:Fo03 Bv03Bericht StUF:Bv03 Mapping StUF synchronisatie en foutberichten naar ebms actions De koppeling tussen binnenkomend bericht en uitgaand ebms bericht moet worden gedefinieerd in de tunnelconfiguratie. Een tunnel definieert hoe/waar een bericht binnenkomt, welke operaties op het bericht plaatsvinden en op welke plekken de output moet worden afgeleverd. Een ebms contract (CPA) is op losse wijze gekoppeld aan een of meerdere tunnels. Bovendien kunnen meerdere CPA s worden gekoppeld aan een tunnel. Om te bepalen welke CPA van toepassing is en welke meta-data in het uitgaande ebms bericht moeten worden opgenomen zijn drie variabelen nodig die gebruikt worden bij de bepaling van het juiste partnership uit de CPA: action. Deze wordt bepaald door het inkomende bericht. In het geval van een inkomend WOZ 3.12 StUF-XML bericht vanuit het belastingsysteem kan de waarde van action gelijk zijn aan de naam van het eerste element in het bericht. Indien de mapping gebeurt op basis van de waarde van het StUF:functie element zoals getoond in bovenstaande tabellen dient een mapping tabel te worden gevuld voor deze variabele. Hieronder volgt een schermafdruk van deze runtime variabele in een ebms tunnel (op basis van naam eerste element):

15 service. De servicenaam uit de CPA. otherpartyid. Het partyid van de andere zijde (kadaster vanuit bronhouder gezien, bronhouder vanuit kadaster gezien). Voor service en otherpartyid moeten ook waarden worden toegekend of een tunnel variabele mapping. Bij het Kadaster wordt vanuit een tunnel met vele parties / bronhouders gecommuniceerd. In dat geval moet er voor de variabele otherpartyid een mapping worden aangelegd tussen inputbericht of protocolproperty en uitgaand partyid (=OIN). Indien er sprake is van één partij kan worden volstaan met constante waarden. De mappings worden gedefinieerd als onderdeel van de CPA import wizard. Naast het berichtformaat zijn er voor bronhouders/leveranciers meerdere interne protocolopties om een bericht af te leveren bij OpenTunnel die deze via ebms doorzet naar de Landelijke Voorziening WOZ. De meest voor de handliggende zijn HTTP(S), JMS en eventueel via filesysteem. Voor de laatste optie biedt OpenTunnel FileEntry- en FileExit-Points waarbij individuele of samengestelde StUF berichten verwerkt kunnen worden. Foutafhandeling op basis van het plaatsen van asynchrone retourberichten vanuit LV-WOZ in het filesysteem is lastig te implementeren. OpenTunnel kan alleen de aflevering in het filesysteem garanderen, niet de verdere verwerking. Transactioneel is dit dus niet sluitend te krijgen en gezien de forse hoeveelheid berichten verdient deze optie niet de voorkeur.

16 AANGEBODEN SERVICES LV-WOZ Ofschoon de Landelijke Voorzieningen benaderd worden via de Digikoppeling adapter is het nuttig inzicht te hebben in de diensten die de LV-WOZ ter beschikking stelt. Voor de LV-WOZ zijn er diverse omgevingen beschikbaar (productie, acceptatie, functionele testomgeving, integratie). Per omgeving worden er verschillende diensten afgenomen voor verschillende typen gebruikers: CT dienst voor het vaststellen van conformiteit van een leverancier AT dienst voor de aansluittoets van gemeenten ET dienst voor externe testen door leveranciers Normale productie dienst voor gemeenten en afnemers In iedere omgeving zijn al deze diensten opgenomen in één of meerdere OpenTunnel configuraties. Iedere dienst heeft zijn eigen entrypoints voor het aanleveren van berichten en bevragingen. Bovendien zijn deze entrypoints voorzien van een versienummer. Toekomstige versies van de WOZ berichtencatalogus krijgen dan een nieuwe URL waardoor er meerdere versies ondersteund kunnen worden. De LV-WOZ koppelt ook zaken terug aan de bronhouder systemen. Foutmeldingen en verzoeken tot synchronisatie worden vanuit LV-WOZ gedaan via ebms protocol naar de lokale OpenTunnel broker. De verschillende diensten en een voorbeeld hoe omgegaan wordt met meerdere LV-WOZ versies wordt in onderstaand component diagram getoond. OpenTunnel diensten in LV-WOZ omgeving bij Kadaster De diensten worden dus onderscheiden door een contextpad (bijv: /lv-woz-ato/312/ebms/aanleveren). De omgevingen zelf worden onderscheiden door een DNS naam van het kadaster. De integratie-omgeving bijvoorbeeld heeft als DNS naam service30.integratie.kadaster.nl.

17 CONFIGURATIE OPENTUNNEL BIJ BRONHOUDER Een belastingapplicatie communiceert direct met OpenTunnel of via een ander systeem zoals een servicebus. De applicatie kan de volgende berichtensoorten uitsturen: 1. Bijhoudingsberichten (StUF gebeurtenis georiënteerde dienstberichten volgens WOZ catalogus) 2. StUF synchronisatieberichten (zelfstandig geïnitieerd of naar aanleiding van verzoek uit LV) 3. Synchrone vraagberichten 4. Asynchrone (massale) bevragingen Berichtsoorten 1, 2 en 4 worden via ebms uitgestuurd. De andere via het zogenaamde Digikoppeling WUS kanaal. Asynchrone en synchrone bevragingen gaan via eigen tunnels met een eigen URL. Het gewenste gedrag van OpenTunnel zal anders moeten zijn en behoeft derhalve een andere tunnel configuratie. De configuratie voor asynchrone bevragingen wordt besproken in een separaat document Aansluiten afnemers op de Landelijke Voorziening WOZ met OpenTunnel 1.6 OpenTunnel kan flexibel worden geconfigureerd maar hieronder doen we toch een suggestie hoe de tunnels kunnen worden aangesproken. De berichten worden door de belastingapplicatie ingeschoten in een entrypoint die onderdeel uitmaakt van een tunnel. Een OpenTunnel instantie kan gebruikt en geconfigureerd worden per LV-WOZ dienst maar er kunnen ook LV-WOZ diensten gedeeld worden. In onderstaand diagram worden de entrypoints voor de aansluittoets in dezelfde server opgenomen als waar de productie entrypoints zich bevinden. De verschillende diensten worden door een naamgevingsconventie uit elkaar gehouden. De aansluittoets-entrypoints zijn herkenbaar aan ato in het contextpad (/lvwozato/.). De productie-entrypoints hebben geen aparte aanduiding (/lvwoz/ ). De LV-WOZ tunnels communiceren via exitpoints met de LV-WOZ (die op haar beurt weer entrypoints heeft om de berichten op te vangen). OpenTunnel luistert behalve naar binnenkomende berichten van een interne belastingapplicatie ook naar berichten uit de LV-WOZ.

18 Voorbeeldconfiguratie OpenTunnel diensten bij de bronhouder op basis van HTTP(S) De ebms berichten die ontvangen kunnen worden uit de LV-WOZ zijn de volgende: 1. StUF Foutberichten die doorgezet worden naar het belastingsysteem 2. StUF synchronisatieberichten indien de LV-WOZ een volledig nieuwe opbouw wil maken van een WOZ object. Ook deze worden doorgezet aan het belastingsysteem. 3. Berichten volgens de Digikoppeling Grote Berichten Standaard. Verzoeken voor een massale levering worden in eerste instantie door een belastingsysteem (of andere applicatie) via OpenTunnel doorgegeven aan de LV-WOZ. De Landelijke Voorziening verwerkt deze verzoeken in de achtergrond en maakt een bestand aan. Via ebms wordt door het kadaster vanuit hun GDS2 systeem een notificatie gestuurd volgens de Digikoppeling Grote Berichten Standaard. Deze wordt door OpenTunnel aan de bronhouder/afnemer zijde opgevangen. De ingebouwde Grote Berichten Standaard implementatie in OpenTunnel zorgt ervoor dat het bestand via HTTPS wordt opgehaald en geplaatst wordt op een geconfigureerde locatie. Deze locatie wordt geconfigureerd in een bestandstunnel. In bovenstaand figuur worden deze berichtsoorten verdeeld over twee entrypoints:

19 Eén voor de LV-WOZ communicatie (berichtsoort 1 en 2 met entrypoint contextpad /opentunnel/ebms/lvwoz/ 312/terugkoppelinglevering/prd en één voor de Grote Berichten Standaard communicatie (/opentunnel/ebms/gb /10/gds2/prd). Ook kunt u uit deze figuur aflezen dat een CPA standaard is gekoppeld aan twee tunnels omdat de communicatie vanuit twee zijden kan worden opgebouwd. TUNNEL CONFIGURATIE BIJ BRONHOUDER De ebms communicatie voor het aanleveren van WOZ gegevens gaat in twee richtingen, er zijn daarom per omgeving-dienst combinatie twee tunnels nodig: 1. Tunnel voor ontvangst van kennisgeving- en synchronisatie- berichten vanuit het belastingsysteem en vervolgens doorzenden naar de LV-WOZ 2. Tunnel voor ontvangst van foutberichten - en synchronisatieverzoeken vanuit de LV-WOZ naar het belastingsysteem of servicebus. De ebms protocol bevestigingen komen hier ook binnen. Deze tunnels met entrypoints en exitpoints moeten vooraf worden gedefinieerd. OpenTunnel kan zelf het TLS verkeer initiëren en beëindigen. Hiertoe moeten de juiste certificaten worden opgenomen in OpenTunnel, als stap in de CPA import of separaat. Maar in sommige gevallen vindt SSL offloading plaats. In dat geval wordt de inkomende SSL communicatie beëindigd op een Gateway of loadbalancer. Voor het uitgaande OpenTunnel kan d.m.v. HTTP headers een gateway / loadbalancer instrueren naar welke partij het bericht verstuurd moet worden. Voor iedere communicatiepartij kan dit worden opgenomen in een OpenTunnel mapping. Deze configuratiestap is onderdeel van de CPA import.

20 Routering uitgaand verkeer via proxy/loadbalancer gebruikmakend van HTTP header en een mapping tabel Hieronder geven wij een voorbeeld van mogelijke entrypoints die gedefinieerd kunnen worden voor de standaard dienst in de LV-WOZ. Ieder entrypoint wordt opgenomen in een tunneldefinitie die bepaalt welke verwerking het bericht ondergaat en waar en hoe het afgeleverd moet worden. De entrypoints zijn hier gebaseerd op HTTP(S). Voor het externe Digikoppeling verkeer is dit verplicht. Bij de aansluiting van een belastingsysteem of servicebus op de Digikoppeling adapter biedt OpenTunnel meer protocollen om uit te kiezen. EntryPoint Naam Contextpad van URL Intern / Extern Bronhouder naar LV-WOZ Aanleveren Entrypoint /opentunnel/lvwoz/aanleveren/ (intern is versienummering in URL niet nodig) intern Bronhouder naar LV-WOZ synchrone vragen Entrypoint /opentunnel/lvwoz/synchroon/ (intern is versienummering in URL niet nodig) intern Bronhouder naar LV-WOZ asynchrone vragen Entrypoint /opentunnel/lvwoz/asynchroon/ (intern is versienummering in URL niet nodig) intern LV-WOZ naar Bronhouder ebms terugkoppel Entrypoint (Dit entrypoint moet gelijk zijn aan het transportreceiver /opentunnel/ebms/lvwoz/312/prd/aanleverenantwoord Extern

21 endpoint in de CPA tenzij OpenTunnel niet zelf het TLS endpoint is, maar SSL offloading wordt toegepast) LV-WOZ naar Bronhouder ebms terugkoppel Entrypoint (optioneel indien gebruik gemaakt wordt van massale bevragingen) opentunnel/ebms/gb/10/gds2/prd Extern Voorbeeld OpenTunnel entrypoints tbv LV-WOZ bij de bronhouder In onderstaande schermafdruk ziet u een voorbeeld van een OpenTunnel entrypoint waar een belastingapplicatie haar berichten kan afleveren. In dit geval is gekozen voor HTTP en gewone StUF XML berichten. De contextpad syntax is voor de single-tenant versie. Voorbeeld EntryPointConfiguratie voor berichten van belastingapplicatie naar LV-WOZ Er is ook een entrypoint nodig waar de LV-WOZ haar berichten kan afleveren. Deze moeten gebruik maken van HTTPS, het berichtformaat is ebms (met een StUF WOZ Payload). Aan dit entrypoint waarop OpenTunnel luistert naar inkomende berichten van de LV-WOZ is een certificaat gekoppeld. Dit certificaat maakt ook deel uit van de CPA maar kan ook separaat geïmporteerd zijn in de OpenTunnel certificaatkluis.

22 Voorbeeld EntryPointConfiguratie voor berichten van LV-WOZ naar belastingapplicatie De volgende stappen zijn de definitie van de exitpoints (waar moet het bericht worden afgeleverd), transformaties (welke omzettingen er gepleegd worden op het bericht), verzoekprofielen (welke andere operaties er nodig zijn op bericht) en de tunnels waar entrypoint, exitpoint(s) en verzoekprofielen/transformer(s) aan elkaar worden gekoppeld en de servicekarakteristieken worden bepaald (synchroon/asynchroon, bewaartermijn, archivering, berichtvalidatie, authenticatie/autorisatie, tunnelvariabelen voor parametrisering van transformaties etc). Nu presenteren wij de exitpoints waar OpenTunnel de LV-WOZ berichten aflevert. In dit overzicht is ook de asynchrone bevraging opgenomen die verder besproken wordt in het aansluitdocument voor afnemers. ExitPoint Naam Contextpad van URL Intern / Extern ebms LV-WOZ Productie /lv-woz/312/ebms/aanleveren Extern (Dit exitpoint moet gelijk zijn aan het transportreceiver endpoint in de CPA bij het kadaster als LV-WOZ beheerder) WUS Synchroon LV-WOZ Productie /lv-woz/312/wus/beantwoordvraag Extern (Voor bevraging op LV-WOZ) ebms Asynchrone Bevragingen LV-WOZ Productie /lv-woz/312/ebms/asynchronevraag Extern (voor asynchrone (massale) bevragingen)

23 Terugkoppeling LV-WOZ naar bronhoudersysteem voor leveringen (StUF foutberichten en synchronisatie verzoeken) In overleg met leverancier/bronhouder Intern Terugkoppeling LV-WOZ naar bronhoudersysteem voor asynchrone vragen (StUF foutberichten) In overleg met leverancier/bronhouder Intern Voorbeeld OpenTunnel exitpoints tbv LV-WOZ bij de bronhouder In onderstaande schermafdruk een voorbeeld van een exitpoint bestemd voor de aflevering van LV-WOZ berichten via ebms naar het Kadaster als beheerder van de LV-WOZ. Er is bij Digikoppeling verkeer sprake van tweezijdig TLS/SSL verkeer vandaar dat ook de OpenTunnel server haar client-certifcaat aanbiedt tijdens het opzetten van de TLS/SSL verbinding. Voorbeeld ExitPointConfiguratie voor berichten van belastingsysteem via OpenTunnel naar LV-WOZ Berichtomzetting gebeurt in OpenTunnel met behulp van transformers. Dit kunnen sjablonen zijn gebaseerd op XSLT en FreeMarker of programatuur. Voor ebms levert OpenTunnel standaard een transformer mee. Deze kan worden geparametriseerd met waarden van OpenTunnel run-time variabelen die opgenomen worden in de transformatie sjablonen. De runtime variabelen kunnen gebaseerd zijn op constanten (bijv. gemeentecode) of op basis van een element in het inkomend bericht of resultante van een OpenTunnel functie. OpenTunnel beschikt ook over een set run-time variabelen met een voorgedefinieerd gedrag. Denk aan generatie van tijdstip elementen, messageids en het ophalen en plaatsen in sjabloon van waarden uit een OpenTunnel mappingtabel. Transformers kunnen ook in een keten worden opgenomen zodat de output van ene transformer input is voor de volgende. Eerst kan een inkomend XML of tekst bericht worden aangepast en dan met een tweede transformer worden omgezet in een ebms- of SOAP-bericht.

24 LADEN VAN CPA IN OPENTUNNEL Hieronder volgt een beschrijving van de CPA import wizard van OpenTunnel. Deze wizard maakt het mogelijk een CPA te koppelen aan twee voorgedefinieerde tunnels (inkomend en uitgaand ten behoeve van ebms tweerichting verkeer). Er kunnen vele CPA s worden gekoppeld aan dezelfde tunnel hetgeen het beheer vereenvoudigd. Indien het uitgaande verkeer via een niet-transparante proxy verloopt (firewall, XML gateway, loadbalancer) kunnen routeringinstructies worden meegegeven in de vorm van HTTP headers. Dit kan ook worden geconfigureerd tijdens de import. Als u de multi-tenant versie van OpenTunnel gebruikt dient u eerst de juiste organisatie te selecteren. Er wordt namelijk gecontroleerd of de geselecteerde partij in OpenTunnel overeenkomt met een van de partijen in de CPA. OpenTunnel herkent ook de rol die de organisatie speelt in de CPA (gemeente of LV, SR of SP) Druk op importeren en selecteer het CPA bestand. Na selectie wordt de CPA geanalyseerd, dit kan enkele tientallen seconden duren. Het CPA inhoud overzicht verschijnt dan:

25 In deze eerste stap kunt u de certificaten importeren voor zover deze nog niet bestaan. Met name kunnen op deze wijze de certificaten van de andere partij worden opgenomen in de OpenTunnel certificatenkluis. Op deze wijze geeft u aan deze te vertrouwen waardoor vanuit OpenTunnel een beveiligde sessie mag worden opgebouwd met de andere partij. De certificaten van uw eigen organisatie zullen wel reeds aanwezig zijn in OpenTunnel. Deze worden dan niet nogmaals geïmporteerd. Druk op volgende en u komt in de tweede stap waarbij u de mogelijkheid krijgt de CPA aan een ingaande en/of uitgaande tunnel te koppelen.

26 Selecteer eerst de inkomende tunnel en daarna de uitgaande tunnel door de juiste checkbox aan te vinken. Voor zover tunnelsettings anders zijn dan die in de CPA kunnen deze worden overgeschreven. Dit is aanbevolen omdat de CPA leidend dient te zijn. De laatste stap is het toevoegen van mappings voor action en otherpartyid. Met andere woorden: op welke CPA moet het uitgaande verkeer worden gebaseerd en naar welke partij moet het bericht worden gestuurd. Voor verkeer vanuit de bronhouder is dit eenduidig, er is maar 1 afleveradres. De andere partij kan dan worden opgenomen als constante. Indien deze gebaseerd is op een expressie (bijvoorbeeld de gemeentecode in een StUF bericht) dan kan een mapping worden toegevoegd tussen gemeentecode (bron) en het partyid van de bestemming (=OIN). Indien het exitpoint van de uitgaande tunnel niet wijst naar het daadwerkelijke endpoint maar naar een interne loadbalancer / firewall / proxy dan kan de proxy via http headers geïnstrueerd worden waar de berichten moeten worden afgeleverd. Indien de exitpoint van de uitgaande tunnel anders is dan die gedefinieerd is in de CPA dan wordt deze mapping optie geactiveerd. Het afleverendpoint uit de CPA is dan de doelwaarde, de bron kan bijvoorbeeld een gemeentecode zijn uit het StUF bericht of een tunnelvariabele.

27 Indien u op de knop Afsluiten drukt wordt de CPA gekoppeld aan de geselecteerde tunnel(s). ARCHIVERING VAN BERICHTEN Indien u als aanbieder van berichten aan de Landelijke Voorziening de verzonden en/of ontvangen berichten wilt bewaren voor een langere termijn kunt u gebruik maken van onze archiveringserver. De OpenTunnel runtime database wordt gebruikt voor betrouwbare aflevering van gegevens. Na aflevering worden deze normaliter verwijderd na een door u instelbare tijd. Deze runtime database is dus niet geschikt voor archivering voor bijvoorbeeld onweerlegbaarheidseisen. De OpenTunnel archiveringoplossing is zeer flexibel en schaalbaar. Er wordt gebruik gemaakt van een of meerdere aan elkaar gekoppelde MongDB servers voor horizontale schaalbaarheid en replicatie. De archiveringserver wordt aan OpenTunnel gekoppeld als exitpoint en in een tunnel opgenomen als archivering exitpoint. Berichten kunnen ook worden gearchiveerd in een DMS (via CMIS of FTP) of via WebDAV protocol, maar de archiveringserver biedt meer schaalbaarheid en de mogelijkheid om zelf de metadata bij een bericht/tunnel te definiëren en daar ook weer op te kunnen zoeken. Bij het archiveren kunnen vier stadia van berichtverwerking worden gearchiveerd: 1. Zoals het bericht is binnengekomen 2. Zoals het bericht is afgeleverd bij een exitpoint En indien er sprake is van een synchrone vraag/antwoord tunnel

28 3. Zoals het antwoord is binnengekomen 4. Zoals het antwoord is uitgeleverd Hieronder een voorbeeld definitie van een achivering exitpoint: Op de configuratie tab worden de parameters die nodig zijn voor de koppeling naar de MongDB NoSQL database. De database en collectie (tabel in relationele database terminologie) wordt dynamisch gecreeerd. Hieronder volgt een voorbeeld configuratie voor de metadata. De parameters die gedefinieerd zijn worden dynamisch als

29 metadatakolommen toegevoegd aan de collectie. Deze metadata kolommen zijn ook doorzoekbaar via de gebruikersinterface van de archiveringserver. De metadata kunnen zoals iedere OpenTunnel variabele gebaseerd zijn op een waarde uit het brondocument, een constant, een resultante van een functie of de waarde van een andere tunnelvariabele. De laatste stap die moet worden verricht is het koppelen van het zojuist gedefinieerde exitpoint aan een tunnel. Dit kan alleen indien aangegeven is dat het bericht moet worden gearchiveerd in een van de vier hierboven genoemde verwerkingstadia.