VISHUB Ontwerp. Onderwerp: Vishub. Datum: 15 oktober Slim geregeld, goed verbonden

VISHUB Ontwerp Onderwerp:

Vishub

Versie:

2. 12 Definitief

Datum:

15 oktober 2010

Auteur:

Slim geregeld, goed verbonden

In licentie gegeven op grond van een Creative Commons Licentie.

Historie: Versie 0.1 0.2 0.3 1.0 1.09 1.1 1.2 2.0

Auteur MvdP MvdP MvdP MvdP MvdP MvdP MvdP MvdP

2.01 2.02

MvdP MvdP

2.1

MvdP

2.11

MvdP

2.12

RAu

Toelichting Initiële opzet Aanpassingen nav overleg met RA, IG, TG, BK Sheet met commentaar verwerkt Use cases toegevoegd Opmerkingen Tobias en Robin verwerkt Structuur aangepast, opmerkingen Joost & Tobias verwerkt Correctieberichten,technical errors en andere issues verwerkt. Distributiemechanisme; xml > edi translatie; proces voor edi retourberichten en andere issues verwerkt en opgenomen Mijlpalen bijgewerkt en document tekstueel nagelopen Kolom RS eruit bij mijlpalen, text aangescherpt mbt de NLVISBASIS-TechnicalError-v1.11.xsd, opzet bericht volgnummer aangepast, aanlevering EDI berichten (xml data als basis gebruiken) Toevoegen mail als attachement Filter berichten op schip ID’s (change 295) Aanpassingen na review Rutger Gooszen Tekst aangepast nav review Rutger Gooszen en Tobias Groothuyze, nieuwe inzichten verkregen tijdens de implementatie Bevindingen van de normen 2 en 128 uit de Audit door PwC zijn verwerkt. Opmerking open source licentie toegevoegd op advies van Corvers.

Distributielijst: Naam Robin Audenaerdt Rutger Gooszen Iwanjka Geerdink Tobias Groothuyse Mike Bandhoesingh

Blad 1 van 42

Rol Casusmanager Architect Bouw Vishub Bouw Vishub Tester Vishub

Akkoord Ja/Nee Alleen Review Alleen Intake Alleen Intake Alleen Intake

Slim geregeld, goed verbonden.

Inhoudsopgave Inhoudsopgave ........................................................................................................................................ 2 1 Inleiding ........................................................................................................................................... 4 1.1 Achtergrond............................................................................................................................. 5 1.2 Scope ....................................................................................................................................... 6 1.3 De toekomst ............................................................................................................................ 6 1.4 Organisatorische context ........................................................................................................ 7 1.5 Gerelateerde documenten...................................................................................................... 8 1.6 Relatie met supd@x concept .................................................................................................. 8 2 Globale opzet .................................................................................................................................. 9 2.1 Samenhang van de componenten......................................................................................... 11 2.2 Beschrijving van de samenhang ............................................................................................ 11 2.2.1 Invulling van componenten met Open source en open standaarden........................... 12 2.3 Adressering en transport van berichten in relatie tot de AID............................................... 13 2.4 Bericht dialoog....................................................................................................................... 14 2.5 Adressering en transport van berichten van de visser aan Vishub ....................................... 14 3 Proces van verwerking .................................................................................................................. 15 3.1 Versturen bericht aan Vishub................................................................................................ 15 3.1.1 Use case:........................................................................................................................ 15 3.2 Ontvangst van berichten ....................................................................................................... 16 3.2.1 Model ............................................................................................................................ 16 3.2.2 Use case......................................................................................................................... 16 3.3 Bepalen van afnemers........................................................................................................... 19 3.3.1 Model ............................................................................................................................ 19 3.3.2 Use case......................................................................................................................... 19 3.4 Vertaal en verstuur berichten ............................................................................................... 21 3.4.1 Model ............................................................................................................................ 21 3.4.2 Use case......................................................................................................................... 21 3.5 Versturen van bericht uit vishub ........................................................................................... 23 3.5.1 Use case:........................................................................................................................ 23 3.6 Ontvang retour berichten ..................................................................................................... 24 3.6.1 Model ............................................................................................................................ 24 3.6.2 Use case......................................................................................................................... 24 3.7 Verwerk retour berichten...................................................................................................... 26 3.7.1 Model ............................................................................................................................ 26 3.7.2 Use case......................................................................................................................... 26 4 Beschrijving van de componenten ................................................................................................ 28 4.1 De publieke mailserver.......................................................................................................... 28 4.1.1 Eisen: ............................................................................................................................. 28 4.2 De private mailserver ............................................................................................................ 29 4.2.1 Eisen: ............................................................................................................................. 29 4.3 Message processing .............................................................................................................. 29 4.3.1 Eisen: ............................................................................................................................. 29 4.4 Maatwerk Java Functies ........................................................................................................ 30 4.5 Database................................................................................................................................ 31 4.6 Configuratie ........................................................................................................................... 31 4.6.1 Eisen: ............................................................................................................................. 31 Blad 2 van 42


5

6

7 8

4.7 De audittrail........................................................................................................................... 32 4.7.1 Eisen: ............................................................................................................................. 32 4.8 Logging .................................................................................................................................. 33 4.8.1 Eisen: ............................................................................................................................. 33 4.9 Schatting omvang data opslag .............................................................................................. 33 Datamodel ..................................................................................................................................... 34 5.1 Vissers.................................................................................................................................... 34 5.2 Schepen ................................................................................................................................. 34 5.3 Afnemers ............................................................................................................................... 34 5.4 Referenties tabel ................................................................................................................... 34 5.5 Audit trail............................................................................................................................... 35 5.6 Berichten ............................................................................................................................... 35 5.7 Distributielijst ........................................................................................................................ 36 5.8 XML met scheepsinfo ............................................................................................................ 37 5.9 Lijst van mijlpalen.................................................................................................................. 38 Beheer ........................................................................................................................................... 39 6.1 Toegang eisen........................................................................................................................ 39 6.2 Tools voor beheer.................................................................................................................. 39 6.3 Eisen aan beheer ................................................................................................................... 40 Niet functionele eisen ................................................................................................................... 41 Technische opzet........................................................................................................................... 42

Blad 3 van 42


1 Inleiding De vissector heeft te maken met verplichtingen die de administratieve lasten met 4,6 miljoen verzwaren. De sector zet de kennis van SGGV in om ervoor te zorgen dat informatie die vissers aanleveren, meervoudig kan worden gebruikt door verschillende overheden. Hiermee bespaart de sector 4,1 miljoen. Vanaf januari 2010 moeten vissers een elektronisch logboek bijhouden. Dit moet een einde maken aan grote verscheidenheid aan methodes die vissers hanteren om bij te houden waar, wat en wanneer ze hebben gevist. Vanaf januari 2010 geldt de verplichting voor grote schepen, anderhalf jaar later zijn de kleinere schepen aan de beurt. De informatie uit dit logboek is bestemd voor de Algemene Inspectie Dienst (AID), een onderdeel van het ministerie van LNV. De verplichting komt bovenop het verstrekken van informatie aan tal van andere overheidsinstanties. Zo wil Douane gegevens over de binnenkomst en het vertrek van schepen, en op termijn de te lossen lading ontvangen en wil de Koninklijke Marechaussee weten of zich buitenlandse bemanningsleden op het schip bevinden. De Inspectie Verkeer & Waterstaat en de KLPD hebben informatie nodig over de conditie van het schip en de Havenmeester wil weten wanneer schepen aankomen en vertrekken. De visafslagen willen vooraf weten welke vangsten er binnen komen en het Productschap Vis en het CBS zien halsreikend uit naar de statistische gegevens van de vaarten. Stuiver per kilo Momenteel zijn al deze informatiestromen gescheiden trajecten en verstrekken de vissers de gegevens vaak schriftelijk en achteraf. Omgerekend naar euro’s zijn ze daarmee op jaarbasis 4,6 miljoen euro kwijt. Op dit bedrag kunnen zij 4,1 miljoen euro besparen als zij de informatie digitaal en eenmalig aanleveren, heeft het programma Slim geregeld, goed verbonden van het ministerie van Economische Zaken berekend. Dat is een stuiver per kilogram vis. Doorspelen Het digitale logboek vervult hierin een sleutelrol. Dit logboek moet niet alleen de informatiestroom naar de AID verzorgen, maar de informatie tevens zo bewerken dat de andere informatievragers ook automatisch de verplichte gegevens krijgen. Doordat de overheden de gegevens zelf ook niet meer handmatig hoeven te verwerken, besparen zij daar op hun beurt 1,1 miljoen euro per jaar mee. Ketenoverleg Onder voorzitterschap van de Nederlandse Visafslagen werken het Productschap Vis, de AID, de Douane, de Koninklijke Marechaussee, het ministerie van LNV, Inspectie Verkeer & Waterstaat, de Havenmeesters, het CBS, GBO.Overheid de oplossingrichting van SGGV nu uit. SGGV ondersteunt de ketenpartners bij de daadwerkelijke totstandkoming van het elektronische logboek. Meervoudig gebruik In de eerste fase onderzoekt SGGV hoe het elektronische logboek voor de meldingen naar de AID moet worden ingericht. Ook begeleidt ze de testfase met het logboek, dat door zestien vissers wordt getest. De test moet ertoe leiden dat het elektronische logboek op 1 januari door de vissers in gebruik kan worden genomen. Parallel aan fase 1 loopt fase 2. Hierin onderzoekt SGGV hoe het elektronische Blad 4 van 42


logboek ook de verplichte meldingen naar de Douane, de Marechaussee en andere instanties kan verspreiden. Voor de inrichting van het elektronische logboek en het meervoudig gebruik van gegevens maakt SGGV gebruik van eerder opgedane kennis bij de import van veterinaire goederen in de Rotterdamse haven. Daar hebben ketenpartners en SGGV een importconcept ontwikkeld waarin berichten automatisch naar alle betrokken partijen worden verstuurd. (BRON: persbericht 24-092009)

1.1 Achtergrond In november 2008 werd de Europese Verordening 1077/2008 gepubliceerd. In deze verordening wordt het verplicht een elektronisch logboek te voeren op visserijschepen. De Europese Commissaris voor visserij kondigde in april 2009 bovendien een herziening van het gemeenschappelijk visserijbeleid aan met de woorden “De verleiding om illegaal te vissen wordt te groot”.1 Betere controle op de hoeveelheid gevangen vis is nodig, waarbij de rol van de Europese Fisheries Control Agency versterkt moet worden. Teneinde de verplichting van de EU Verordening 1077/2008 te faciliteren is op initiatief van de Nederlandse Visafslagen een ketenoverleg gestart tussen bedrijfsleven en overheid. Op verzoek van GBO.Overheid is SGGV benaderd om te bezien of SGGV een bijdrage kan leveren door in deze keten een casus uit te voeren. EZ heeft vervolgens ingestemd met het uitvoeren van de intake voor dit casusvoorstel. Het ketenoverleg maakt goede vordering. Er ligt ook een nadrukkelijke deadline, 1 januari 2010 moet de oplossing op volle schaal geïmplementeerd zijn. De ketenpartners spreken uit behoefte te hebben aan een 'neutrale' partner die de bruggen tussen partijen kan slaan, die de kwaliteit van de oplossing kan bevorderen en bewaken, en die zo zal bevorderen dat het resultaat tijdig wordt behaald. De bijdrage van SGGV heeft er tot dusver toe geleid, dat niet alleen de urgente 'enkelvoudige' probleemstelling om vanwege een EU-richtlijn een verplichte elektronische berichtenstroom van visser naar de AID in te richten, wordt aangepakt. SGGV heeft als meerwaarde ingebracht, dat de visser centraal wordt geplaatst en dat ook andere verplichte berichtenstromen, naar douane, havenmeester, CBS en IVW, in deze - generiek inzetbare - oplossing worden meegenomen. Zonder de bijdrage van SGGV was die beweging in de keten niet tot stand gekomen. (Bron: intakerapportage 0806-2009)

Blad 5 van 42


1.2 Scope Scope voor dit functioneel ontwerp is om, in samenwerking met de e-logboek, de OTP en de AID systemen, de basisvoorziening leveren om aan de bovengenoemde Europese verordening 1077/2008 te voldoen. Hierbij vervult de vishup de ontvangst van berichten van de vissersschepen, verwerking van de berichten en aflevering van de berichten aan de AID. De aflevering vindt plaats met behulp van de OTP en gebeurt op basis van het door de EU voorgeschreven berichtformaat. Vishub zal het berichtformaat vaststellen van het bericht wat de vissers aan Vishub moeten sturen. In versie 2.0 is de scope uitgebreid met de aflevering van berichten aan de Douane, De IVW ( Inspectie Verkeer en Waterstaat),De Kmar ( Koninklijke Marechaussee), De KLPD (Korps Landelijke Politiediensten), De Haven (Den Helder), Het PVis (Productschap Vis), Het CBS (Centraal Bureau voor de Statistiek), Producenten Organisaties en visafslagen

1.3 De toekomst Per 1-1-2010 gaat de Vishub over naar beheer en zal het Productschap Vis eigenaar worden van het systeem.

Blad 6 van 42


1.4 Organisatorische context Vishub is een privaat systeem wat opereert in opdracht van het productschap Vis. Het vormt de kern van het verwerken van de berichtgeving van de elektronische logboeken die zijn geïnstalleerd op de Nederlandse visserijvloot. Alle vissersschepen die zijn uitgerust met een e-logboek ontvangen van het productschap een elektronische sleutel waarmee zij de berichten die ze aan Vishub sturen kunnen authenticeren en versleutelen (encryptie). Zodoende waarborgt het systeem de authenticiteit en kwaliteit van de berichtenstroom aan Vishub. Aan de andere kant ontsluit Vishub berichten aan overheidspartijen via de Overheids Transactie Poort (OTP). Zie ook onderstaand figuur: Producenten Organisaties (8) & Visafslagen (12) [email protected] [email protected]

Decryption Encryption Mailclient Decryption

encrypted messages [email protected]

[email protected]

Encryption Vishub mailserver

[email protected]

Vishub engine [email protected] [email protected]

[email protected]

eLogboek Software aan boord

[email protected] [email protected] ontvangen e-logboek bericht

Beheren distributielijst

Versturen retourberichten

ontvangen KVO/retour bericht XML translatie e-logboek bericht

OTP

[email protected]

Beheren adreslijsten Beheren accounts

haven @denhelder.nl

Opstellen sub berichten

haven @L_Oog.nl

verzenden sub-berichten Beheren autorisatie CBS/PO Decryptie van berichten Encryptie van retour berichten

[email protected]

Vishub Monitoren berichtverwerking Behandelen uitval

Monitoren berichtverwerking Behandelen uitval

Bedrijfsleven

Overheid

Figuur 1: Context van het Vishub systeem.

De interne verwerking van berichten door Vishub wordt in de volgende hoofdstukken nader uitgewerkt. NB. Het is als visser niet verplicht berichten aan te leveren aan de Vishub. De visser kan er ook voor kiezen berichten rechtstreeks op de OTP aan te bieden of deze via een andere intermediair aan te leveren.

Blad 7 van 42


1.5 Gerelateerde documenten De volgende documenten moeten in samenhang met dit document worden gelezen om een compleet beeld van het gewenste systeem te verkrijgen: 1. 2. 3. 4. 5.

Berichtstroomdefinitie eLogboek v10.pdf 090608 Intake rapportage eLogboek Visserij v11.pdf NLVIS Message Implementation Guide 1.11.pdf eLogboek encryptie-add-on ontwerp v0.1.doc Beveiligingsprotocol berichten Vishub v1.0.docx

1.6 Relatie met supd@x concept De opzet van het Vishub systeem is gebaseerd op het SUPD@X concept wat is ontwikkeld voor import van veterinaire containers in de haven van Rotterdam. Het Supd@x concept is uitgewerkt binnen het ICTU programma Slim geregeld, goed verbonden in opdracht van het Ministerie van Economische Zaken. Context voor deze ontwikkeling was de casus Import Veterinaire Goederen. De casus Visserij is een spin-off van de ‘veterinaire casus’ vandaar dat ook het technisch concept goed herbruikbaar is. In de praktijk zullen beide systemen hun eigen ontwikkeling en planning hebben en delen ze slechts een gezamenlijke achtergrond en een overeenkomstig concept. Basis voor dit ontwerp zijn dan ook het Linux Operating System, het Java platform, de open source database “MySQL” en de open source message processing engine “Mule”.

Blad 8 van 42


2 Globale opzet Vishub is opgebouwd uit een aantal componenten, deze zijn hieronder opgesomd en visueel weergegeven in Figuur 2: samenhang componenten. Daarnaast heeft Vishub verscheidene koppelvlakken zoals ook hieronder opgesomd en weergegeven in de figuur. Alle componenten en koppelvlakken worden toegelicht in de beschrijving van de componenten in paragraaf 4. De componenten: 1. Een publieke mailserver voor de externe email met vissers, producentenorganisaties en visafslagen 2. Een private mailserver , dedicated voor de email met de OTP voor alle achterliggende overheden 3. Een message processing engine (Mule) 4. Gegevensopslag bestaande uit a. Een database (MySQL) b. Flat file logging 5. Maatwerk functionaliteit bestaande uit: a. Een translatie voorziening b. Een audit trail c. Configuratietabellen d. Encryptie / decryptie van berichtinhoud e. Exception handling voor foutieve berichten of routering De koppelvlakken: 1. Uitwisseling van berichten met de OTP (zie ook de “Berichtstroomdefinitie eLogboek v10.” en de “Koppelvlak SMTP-MTA 2 0 Definitief.pdf”) 2. Uitwisseling van berichten met de vissersschepen en in het bijzonder met het elektronisch logboek wat de kapitein onderhoud. (Zie ook de “NLVIS Message Implementation Guide 1.11.pdf”) 3. Uitwisseling vanberichten met de producentenorganisaties en visafslagen Asynchroniteit De interactie van berichten tussen de koppelvlakken en het vishub systeem gebeurt asynchroon. Dit betekent dat berichten van vissers die aan het vishub systeem worden aangeboden enkel technisch worden geaccepteerd door de mail server en verder asynchroon verwerkt zullen worden. Na deze verwerken zal een uitgaand mail bericht naar het OTP aan de private mail server worden aangeboden. Een retourbericht van een partij op het OTP (Alleen AID/Douane) wordt aangeboden aan de private mail server van vishub, waarna deze asynchroon wordt verwerkt en doorgestuurd via de publieke mail server naar de correcte visser. Pas na ontvangst van een retourbericht van de AID mag een visser een nieuw bericht naar het vishub systeem insturen.

Blad 9 van 42


Uitgangspunten: 1. Alle berichtenverkeer loopt via SMTP en is asynchroon. 2. Berichten zijn altijd beveiligd tijdens transport. 3. Vishub doet zo min mogelijk controles en bewerkingen op de inhoud van het bericht. Foute waarden worden als foute waarden doorgestuurd naar de achterliggende partijen. Dit is ingegeven om de verantwoordelijkheden scherp te houden. De visser is verantwoordelijk voor een inhoudelijk goed bericht. De Overheidsafnemers moeten zelf valideren dat de inhoud van de berichten die ze ontvangen correct is. 4. Als in Vishub iets fout gaat (een exception optreedt) wordt dit altijd aan de beheerder gemeld en in de logging weggeschreven. Indien Vishub beheer het ontvangen bericht ook niet kan inzien zal Vishub een technical error message naar de afzender sturen. In alle andere gevallen wordt gebruik gemaakt van het AID foutbericht of een door Vishub ontwikkelde variant daarop.

Blad 10 van 42


2.1 Samenhang van de componenten In het model hieronder is de samenhang van logische componenten weergegeven

Functionele componenten VISHUB eLogboek bericht Retourbericht

Publieke Mailserver

Private Mailserver

Bericht aan de OTP Retourbericht van de OTP

Bericht aan PO en Visafslag

Message processing (Mule)

VISHUB Beheer tools mailcliënt

Maatwerk Java functies Database (MySQL)

audittrail configuratie Logging

Flat file Logging

Figuur 2: samenhang componenten

2.2 Beschrijving van de samenhang De gestippelde lijnen geven aan dat de componenten gebruik maken van elkaars voorzieningen. De vaste lijnen geven de informatie flow weer. De zwarte lijnen geven de aanlevering weer, de blauwe lijnen geven de retourberichten weer. De aanlevering van berichten aan Vishub vindt altijd encrypted plaats. De berichten zijn dus niet te lezen door andere partijen. Alleen het betreffende logboek en ons systeem, wat voorzien is van een unieke key, kan de berichten inhoudelijk inzien. De uitgaande berichten en de retourberichten aan OTP zijn niet encrypted, maar worden over een beveiligde verbinding uitgewisseld met het OTP. Wanneer Vishub een retourbericht van een overheidspartij ontvangt wordt deze versleuteld en verstuurt naar het logboek systeem aan boord. Ook hier geld weer dat alleen Vishub en het betreffende logboek het bericht kunnen inzien. Technische errors die in Vishub optreden worden met een niet-versleuteld bericht teruggestuurd naar de visser. Het logboeksysteem kan dan reageren met herinzending oid. Het Vishub beheer gedeelte bevat 4 views op het systeem, de mailclient, de audittrail, de configuratie en de logging. Deze views zijn door de beheerder vanuit een beveiligde omgeving te raadplegen met behulp van standaard tooling zoals omschreven in paragraaf 6.2.

Blad 11 van 42


Zoals in het model weergegeven wordt de logging van de mailservers, message processing en maatwerk functionaliteit op 1 plek weggeschreven. Inhoudelijke data wordt door deze componenten weggeschreven in de database. Het exacte model of type database voor de mailservers is afhankelijk van de ingekochte mailservers. Voor de Mule en maatwerk functionaliteit zal gebruik worden gemaakt van de MySQL database.

2.2.1 Invulling van componenten met Open source en open standaarden Bovenstaande opzet van logische componenten kan worden ingevuld op basis van open source componenten. Voor de mailservers wordt hmailserver gebruikt maar kan ook een andere mailserver worden ingezet. Voor de message Processing is Mule gekozen. De basis is een open source omgeving waarvoor geen licentiekosten worden gemaakt. Indien gewenst kan echter ook worden gekozen voor een professionelere, betaalde versie van de diverse open source oplossingen waarmee een hogere betrouwbaarheid is gegarandeerd van de software en de ondersteuning. Voor de maatwerk functionaliteit is gekozen voor Java en het gebruik van open source libraries. Voor de database is MySQL gekozen. Dit is een veelgebruikte open source database.

Blad 12 van 42


2.3 Adressering en transport van berichten in relatie tot de AID Visserij Sector

GBO

LNV Van:[email protected] Aan:[email protected] Att: 33535-goed.XML

software vaartuig

ERS POSTBUS

OTP.NL Van:[email protected] Aan:[email protected] Att: 33535.XML

33535.XML

Vishub

Van:[email protected] Aan:[email protected] Att: 33535-goed.XML

ERS SERVICELAAG NL

33535.XML

LNV-MAILADRES

Van:[email protected] Aan:[email protected] Att: 33535-goed.XML

ERS VERWERKINGSLAAG NL

BSN: 123456789 Mail: [email protected]

ERS Database

Figuur 3: transport van berichten aan de AID

Bovenstaand figuur geeft een beeld van de berichtafhandeling van logboekberichten naar het systeem (ERS) van de AID in relatie tot de Vishub. Uitgangspunten hierbij zijn: • •

• •

•

•

Vishub heeft één mailbox bij OTP, [email protected] Vishub is geen relatie van LNV , de visser is de relatie. Deze wordt in het bericht opgenomen met een unieke identifier en gekoppeld aan het mailadres [email protected]. Vishub zorgt ahv de identifier voor de aflevering aan de juiste visser. Correct Berichtenverkeer tussen kapitein en Vishub is een verantwoordelijkheid van de sector Foutberichten op de AID verwerkingslaag worden teruggemeld aan het mailadres dat bij de kapitein als LNV-relatie is vastgelegd (De kapitein moet bij gebruik van de Vishub dus het adres van de Vishub vast laten leggen als mailadres) Goedberichten op de AID verwerkingslaag worden teruggemeld aan het mailadres dat bij de kapitein als LNV-relatie is vastgelegd (De kapitein moet bij gebruik van de Vishub dus het adres van de Vishub vast laten leggen) De AID stuurt nav elk bericht één retourbericht. Wanneer het berichtvolgnummer door de AID niet te herleiden is wordt door de AID volgnummer 999 in het retourbericht gebruikt. Volgnummer 999 in het NLRET:NR element betekend dus dat het bericht inhoudelijk ook niet te lezen is.

Blad 13 van 42


2.4 Bericht dialoog De vaste lijnen uit Figuur 2 geven een informatiestroom weer. Deze is in de onderstaande berichtdialoog verder uitgewerkt. De verdere details van de berichtdialoog en de berichtdefinities zijn opgenomen in het document “NLVIS Message Implementation Guide 1.11.pdf”. Een beknopte uitwerking van de berichtedialoog is opgenomen in paragraaf 2.5.

2.5 Adressering en transport van berichten van de visser aan Vishub Vissers adresseren hun berichten aan de Vishub of rechtstreeks aan de AID indien ze geen gebruik willen maken van de Vishub. In onderstaand model wordt er van uitgegaan dat berichten altijd via de Vishub verlopen: 1. De visser mailt een NLVIS-Basis Bericht met daarin een NL*** element aan Vishub account [email protected] 2. De visser ontvangt van Vishub een NLRET retourbericht. Dit retourbericht wordt naar het mailadres van de visser verstuurd wat in onze database is vastgelegd. Het kan ook zijn dat er een exception optreed. In dat geval stuurt de Vishub een technical error message naar de visser (op basis van schema NLVIS-BASIS-TechnicalError-v1.11.xsd). 3. De Visser mailt mogelijk een NLVIS-Basis Bericht met daarin een NLCOR element (correctie) aan Vishub account [email protected] 4. De visser ontvangt van Vishub een NLRET retourbericht. Vervolgens begint het proces weer van voor af aan of de visser stuurt weer een correctie en het proces herhaalt stap 3 en 4…

Blad 14 van 42


3 Proces van verwerking Onderstaande paragraaf beschrijft het proces van verwerking van de berichten binnen het Vishub systeem. Het totale proces is opgedeeld in 6 delen: 1. Versturen bericht aan Vishub 2. Ontvangst en decryptie van berichten 3. Bepalen van afnemers 4. Vertalen en versturen berichten 5. Ontvangen van retourberichten 6. Verwerk retourbericht Alle zes de delen worden in de onderstaande paragraven nader uitgewerkt en gespecificeerd met behulp van use cases.

3.1 Versturen bericht aan Vishub Het proces van verwerking begint altijd met een visser die een bericht instuurt aan de Vishub. Het bericht wat wordt ingestuurd zal altijd gecomprimeerd en encrypted moeten zijn. Zie voor de details het “Beveiligingsprotocol berichten Vishub v1.0.docx”. Berichten die niet encrypted worden aangeleverd zullen niet worden verwerkt en resulteren in een error retourbericht. Bericht files worden als bijlage aan de email verbonden en zijn ook de enige content die de mail mag bevatten. 3.1.1 Use case: Actoren: Visser; publieke mailserver; Trigger: De schipper klikt op verzenden (het bericht is al gecomprimeerd, encripted & ondertekend), afhankelijk van het e-logboek kan dit anders werken maar uitgangspunt is dat de schipper minimaal in de mailcliënt op verzenden klikt om zijn bericht daadwerkelijk aan te bieden aan de Vishub mailserver. Flow: 1. Het email bericht wordt verzonden naar account [email protected] op de Vishub publieke mailserver. 1.1. Indien deze mailserver niet bereikbaar is wordt het bericht bij de secundaire mailserver afgeleverd door middel van de DNS failover. 2. Het email bericht wordt ontvangen door de mailserver, de verwerking wordt gelogd en het bericht wordt opgeslagen in de database. (standaard mailserver functionaliteit) 3. De Vishub publieke mailserver meld aan de verzendende mailserver dat het bericht is geaccepteerd. (standaard mailserver functionaliteit) 3.1. Indien om wat voor reden ook het bericht niet wordt geaccepteerd zal deze fout worden doorgegeven aan alle tussenliggende mailservers en na verloop van tijd (afhankelijk van tussenliggende mailservers) aan de mailcliënt van de schipper. (standaard mailserver functionaliteit)

Blad 15 van 42


Resultaat: 1. Goed: het verstuurde bericht staat op de publieke mailserver van de Vishub. 2. Fout: het bericht blijft in de mailcliënt of server van de schipper. De schipper krijgt een foutmelding van het mailsysteem. Logging: De mailserver heeft de verwerking of de fout gelogd. De exacte logging zal afhangen van de gekozen mailserver.

3.2 Ontvangst van berichten Alle berichten van de visser worden eerst opgeslagen op de mailserver. Mule verwerkt de berichten die op de publieke mailserver binnenkomen. In een tweede transactie worden de opgeslagen berichten verwerkt. Zie onderstaand model:

3.2.1 Model Mule eLogboek bericht

Publieke Mailserver

Store message

Store transaction

Handle exception & Store transaction

Alle ontvangen berichten worden opgeslagen in de database

MySQL

Decrypt & authenticate & validate message

Get message from mail

Creëer technical error message

QUEUE

Plaats het NLVIS-basis bericht in een queue

Log alle stappen in het proces

Bewaar het resultaat van de transactie in de audittrail

Decript en authenticeer & valideer op basis van onze configuratie

configuratie QUEUE

audittrail

NLVISBASIS

Log MySQL

Maatwerk Functionaliteit

Storage Transactie 1

Transactie 2

Figuur 4: Ontvangst en decryptie van berichten

3.2.2 Use case Actoren: publieke mailserver; Mule; beheerder Trigger: Mule verwerkt elke 5 seconden de binnengekomen email op de publieke mailserver.

Blad 16 van 42


Flow: 1. Check op binnengekomen mail op de publieke mailserver. De berichten worden opgehaald van het [email protected] account en in zijn geheel in Mule opgeslagen voordat de mail op de mailserver wordt verwijderd. (Transactie 1) Mule kan alleen berichten verwerken met base64 encoding. Multipart mime wordt ondersteund maar singlepart heeft de voorkeur. Ook is het bij multipart mime verboden om andere parts van content te voorzien, slechts een part mag content bevatten. 2. Start voor elk binnengekomen bericht een proces ‘Ontvangst van berichten’. Originele berichten en correctieberichten worden op dezelfde manier verwerkt. Per proces doorloopt transactie 2 de volgende stappen, zie ook Figuur 4: Ontvangst en decryptie van berichten. (Transactie 2) 2.1. Decrypt en decomprimeer het bericht op basis van het Ontcijferproces wat is beschreven in “Beveiligingsprotocol berichten Vishub v1.0.docx”. (De public ECC key van de verzender is opgeslagen in onze database en te herleiden op basis van het SID) 2.2. Authenticeer de afzender op basis van de in het bericht opgenomen SID en de SID die in de vissers tabel hoort bij de public key waarmee het bericht is versleuteld. 2.3. Valideer het ontvangen bericht op basis van het xsd wat in de Vishub configuratie is vastgelegd. Zie ook “NLVIS Message Implementation Guide 1.11.pdf” 2.4. Sla het plain xml bericht op in de ‘NLVIS-Basis’ queue. 2.5. Sla het transactie resultaat op in de audit trail (mijlpaal nr 1) Ook het originele bericht wordt onversleuteld weggeschreven in de berichten tabel en gerelateerd aan de audittrail. Alternatieve Flow: 1. Indien in stap 1 een exception optreed (waarschijnlijk omdat de mail een foute encoding bevat) wordt de mail weggeschreven in het log en de audit trail (Mijlpaal 25), ook wordt de beheerder genotificeerd via email. Vervolgens wordt de mail van de mailserver verwijderd. 2. Indien een exception optreed tijdens stap 2.1 t/m 2.4 Sla dan het transactie resultaat en de foutmelding op in de audit trail met als mijlpaal nummer 2, 3, 4 of 5 (afhankelijk van het moment waarop de fout optreed) en als opmerking de foutboodschap. 3. Stuur het audit record in een email aan de beheerder. 4. Bepaal de afzender van het oorspronkelijke bericht aan de hand van het from adres in de mail. 5. Creëer een technical error message. De errorSource is VISHUB, de errorMessage is de mijlpaal en de errorDetail bevat aanvullende informatie over de exception als die er is. Error berichten dienen in dit stadium van de verwerking altijd te worden gestuurd aan de afzender van het oorspronkelijke bericht. Resultaat: 1. Goed: Het bericht is in de queue geplaatst. Deze queue vorm de basis voor verdere verwerking van het bericht in het proces “verstuur berichten” 2. Fout: Er is een retourbericht aan de mailserver gestuurd en de beheerder is geïnformeerd.

Blad 17 van 42


Logging: Mule logt één record per activiteiten welke in de bovenstaande flow en alternatieve flow worden uitgevoerd. Één record bevat altijd: 1. Een timestamp 2. Het unieke transactienummer 3. Het resultaat van de activiteit (bijv. decomprimeren succesvol) 4. Indien de activiteit niet succesvol is: alle exception details in de log opnemen.

Blad 18 van 42


3.3 Bepalen van afnemers Nadat berichten door Mule zijn ontvangen en verwerkt worden ze via een queue aangeboden aan het onderstaande “Bepaal afnemers” proces. Dit proces zorgt voor dynamische aflevering van de berichten bij verschillende afnemers. Per afnemer wordt bepaald of deze is toegestaan door de visser, vervolgens wordt gekeken of het bericht inhoudelijk ook relevant is voor de afnemer (filtering). Per relevante afnemer wordt een exacte kopie van het bericht in de afnemers queue geplaatst.

3.3.1 Model

Bepaal afnemers

In onze configuratie is vastgelegd wie de visser heeft gemachtigd om een afschrift van het bericht te ontvangen. Het aantal afnemers is dus dynamisch. Sommige afnemers zijn verplicht

Bepaal op basis van een expressie in de configuratie of de afnemer in aanmerking komt voor dit specifieke bericht. De lijst met alle afnemers wordt gefilterd op basis van de inhoud van het bericht.

Mule

Get message from queue

Bepaal afnemers op basis van SID

Pas filter toe per afnemer


Plaats per afnemer een kopie in de queue

Store transaction


configuratie

Log QUEUE

QUEUE

NLVISBASIS

Afnemers

audittrail

MySQL

Storage


Figuur 5: bepalen afnemers

3.3.2 Use case Actoren: private mailserver; Mule; beheerder Trigger: Mule verwerkt automatisch de binnengekomen berichten op de queue ‘NLVIS-Basis’. Flow: (Zie ook Figuur 5: bepalen afnemers) 1. Haal het bericht op van de “NLVIS-Basis” queue. (Hier zijn de berichten in plain xml formaat ingezet door het proces ”Ontvangst van berichten” 2. Bepaal de afnemers op basis van het SID of het XR (Uitwendig kenteken van het schip) van de afzender en de distributielijst tabel.

Blad 19 van 42


3. Voer per afnemer het filter toe. Voldoet de afnemer niet aan het filter verwijder de afnemer dan van de interne lijst van afnemers voor dit unieke bericht. Filtering kan plaatsvinden op basis van de lijst met vissers of de lijst met schepen. 4. Plaats per afnemer een kopie van het bericht in de “afnemers”queue en geef de id van de afnemer mee in de metadata van de kopie. 5. Sla de het transactie resultaat op in de audit trail (mijlpaal nr 6). Alternatieve Flow: 1. Indien een exception optreed tijdens stap 2 t/m 5 Sla dan het transactie resultaat en de foutmelding op in de audit trail met als mijlpaal nummer 7, 8, 9 of 10 (afhankelijk van het moment waarop de fout optreed) en als opmerking de foutboodschap. 2. Stuur het audit record in een email aan de beheerder

Resultaat: 1. Goed: Het bericht 1 of meerdere keren opgeslagen in de “afnemers” queue 2. Fout: De beheerder is geïnformeerd en de exception is als onderdeel van het audit record opgeslagen in de database. Logging: Mule logt één record per activiteiten welke in de bovenstaande flow en alternatieve flow worden uitgevoerd. Één record bevat altijd: 1. 2. 3. 4.

Een timestamp Het unieke transactienummer Het resultaat van de activiteit (bijv. translatie succesvol) Indien de activiteit niet succesvol is: alle exception details in de log opnemen.

Blad 20 van 42


3.4 Vertaal en verstuur berichten Nadat berichten door Mule zijn ontvangen, verwerkt en nadat de afnemers zijn bepaald worden ze via een queue aangeboden aan het onderstaande “vertaal en verstuur berichten” proces. Dit proces zorgt voor de aanmaak en de aflevering van de overheidspecifieke berichten aan alle afnemers. Onderstaand proces wordt per relevante afnemer doorlopen per ingekomen bericht. 3.4.1 Model

Vertaal en verstuur bericht Publieke Mailserver

Mule

Get message from queue

Vervang bericht volgnummer

Translate & validate message

Creëer en verstuur mail

Store transaction

Private Mailserver



Bepaal welke translatie moet worden uitgevoerd op basis van de configuratie


configuratie

Log

MySQL

QUEUE

audittrail

Afnemers

Alle verstuurde berichten worden opgeslagen in de database MySQL



Figuur 6: vertaal en verstuur berichten

3.4.2 Use case Actoren: private mailserver; Mule; beheerder Trigger: Mule verwerkt automatisch de binnengekomen berichten op de queue ‘NLVIS-Basis’. Flow: (Zie ook Figuur 5: ) 1. Haal het bericht op van de “NLVIS-Basis” queue. (Hier zijn de berichten in plain xml formaat ingezet door het proces ”bepaal afnemers” Het afnemers ID wordt als metadata aan dit proces meegegeven 2. Vervang het originele bericht volgnummer (RN) door een in Vishub gegenereerd bericht volgnummer (Het gegenereerde berichtvolgnummer bestaat uit de SID gevolgd door het originele berichtvolgnummer)en sla beide nummers op in de referenties tabel. a. Als het originele bericht volgnummer al voorkomt herbruik dan het eerder gegenereerde bericht volgnummer.

Blad 21 van 42


3.

4. 5.

6.

b. Als het bericht een correctiebericht is vervang dan ook het originele berichtnummer (RN in het NLRET element) in het eerder gegenereerde bericht volgnummer. Vertaal het bericht op basis van de in de configuratie opgenomen details die horen bij het afnemers ID. Bepaal eerst het Soort transformatie, XML betreft een transformatie op basis van een XSLT, EDI betreft een transformatie op basis van een Java JAR. De XML transformatie gebeurd op basis van de in de afnemers tabel aangegeven translatie (xslt) voor deze afnemer. De EDI transformatie gebeurd op basis van de afnemers tabel aangegeven translatie jar en een in de software opgenomen xml file(Zie HS 5, Datamodel). Valideer het nieuwe bericht met behulp van de in de configuratie opgenomen xsd voor deze afnemer. Creëer een email en verstuur het aan de private of publieke mailserver(doe dit op basis van de routering settings in de tabel afnemers). Geadresseerde is de afnemer ID, meegegeven in de metadata (het actuele mailadres is in de tabel afnemers opgenomen), afzender is de Vishub, de body van de mail is als mime singlepart geconfigureerd en base64 encoded. (De OTP maakt een .txt bijlage van onze body. )NB. Mail via de publieke mailserver wordt alleen beveiligd indien de afnemer dit vraagt. De afnemer is zelf verantwoordelijk voor de beveiliging van deze berichten. De beveiliging zal in samenspraak met de afnemer worden ingericht. Sla het transactie resultaat op in de audit trail (mijlpaal nr 10) ook het nieuw aangemaakte bericht wordt als plain xml of edi weggeschreven in de berichten tabel en gerelateerd aan de audittrail.

Alternatieve Flow: 1. Indien een exception optreed tijdens stap 2 t/m 5 Sla dan het transactie resultaat en de foutmelding op in de audit trail met als mijlpaal nummer 11, 12, 13 of 14 (afhankelijk van het moment waarop de fout optreed) en als opmerking de foutboodschap. 2. Indien in stap 2 een berichtnummer van één visser voor de tweede keer is aangeboden aan Vishub dan moet de eerder gemaakte referentie worden herbruikt1. En wordt dus 2 x bericht met volgnummer B aangeboden aan de AID. Dit zal resulteren in een foutmelding bij de AID die Vishub dan weer terugstuurt aan de visser. Indien een correctiebericht refereert aan een origineelvolgnummer wat niet in de referentiestabel is te vinden maken Vishub gewoon een nieuw volgnummer aan en wordt het bericht aangeboden aan de AID. Dit zal ook resulteren in een foutmelding bij de AID die Vishub dan weer terugsturen aan de visser. 3. Stuur het audit record in een email aan de beheerder

Resultaat: 1. Goed: Het bericht is ontvangen door de publieke of private mailserver. 2. Fout: De beheerder is geïnformeerd en de exception is als onderdeel van het audit record opgeslagen in de database. 1

Er komt bijvoorbeeld een bericht aan met volgnummer 1234. Seconde later komt nog een bericht van dezelfde visser(zelfde SID) met ook volgnummer 1234. Beide keren vertaalt Vishub 1234 in 5678. De AID e ontvangt dus ook 2x een bericht met eenzelfde volgnummer en zal een foutmelding op het 2 bericht geven indien dit geen correctiebericht is.

Blad 22 van 42


Logging: Mule logt één record per activiteiten welke in de bovenstaande flow en alternatieve flow worden uitgevoerd. Één record bevat altijd: 1. 2. 3. 4.

Een timestamp Het unieke transactienummer Het resultaat van de activiteit (bijv. translatie succesvol) Indien de activiteit niet succesvol is: alle exception details in de log opnemen.

3.5

Versturen van bericht uit vishub

Voor deze generieke use case zijn de actoren in te vullen door een aantal concrete actoren. De geldige combinaties die moeten worden ondersteund zijn de volgende: 1. Vishub mail server: private mailserver Mail server ontvanger: mail server van het OTP 2. Vishub mail server: public mailserver Mail server ontvanger: mail server van de visser 3. Vishub mail server: public mailserver Mail server ontvanger: mail server van de afnemer die niet op OTP is aangesloten 3.5.1 Use case Actoren: Vishub; vishub mailserver, mail server ontvanger Trigger: Vishub biedt een mail bericht aan bij de vishub mail server. Flow: 1. 2. 3. 4. 5.

Vishub biedt een mail bericht aan bij de vishub mail server. De vishub mail server accepteert het bericht. De vishub mail server logt het bericht De vishub mail server verstuurd het bericht naar de mail server van de ontvanger. De mail server van de ontvanger verstuurd een acceptatie terug naar de vishub mail server.

Resultaat: 1. Goed: het verstuurde bericht staat op de mailserver van de ontvanger. 2. Fout: het bericht blijft in de vishub mail server omdat na verloop van tijd het bericht nog niet kan worden aangeboden op de mail server ontvanger. 3. Fout: de vishub mail server is niet beschikbaar. Er wordt een exceptie audit trail weggeschreven met mijlpaal 14.

Blad 23 van 42


Logging: De mailserver heeft de verwerking of de fout gelogd. De exacte logging zal afhangen van de gekozen mailserver.

3.6 Ontvang retour berichten Retourberichten zijn berichten die aan de visser worden geadresseerd. De retourberichten worden aangeboden op onze private OTP mailserver en zijn afkomstig van de AID (NLRET.xml) of Douane(NLBB16.edi) De AID Stuurt altijd maar 1 retourbericht op basis van een origineel bericht. Indien de AID het bericht niet kan lezen sturen ze ook een retourbericht met origineelvolgnummer(nlret rn attribuut) 999. De Douane stuurt ook altijd 1 retourbericht op basis van het door ons ingestuurde NLBB01 of NLBB02 bericht. Retourberichten worden altijd eerst opgeslagen in een queue. In een tweede transactie wordt de routering bepaald. Zie onderstaand model: 3.6.1 Model

Ontvang retour bericht Mule

Retour bericht

Private Mailserver

Afzender is niet douane

Get message from mail Bepaal afzender en routering

Afzender is douane

Translate NLBB16 EDI naar een NLRET bericht

Store message

Store transaction

QUEUE



MySQL

Alle ontvangen berichten worden opgeslagen in de database

configuratie QUEUE

Log

audittrail

NLRET

MySQL



Transactie 2

Figuur 7: verwerk retour bericht

3.6.2 Use case Actoren: private mailserver; Mule; beheerder Trigger: vanuit het OTP is een retourbericht (NLRET of NLBB16) op de mailserver geplaatst.

Blad 24 van 42


Flow: 1. Check elke 5 seconden op binnengekomen mail op account [email protected] van de private mailserver. De berichten moeten in zijn geheel in Mule zijn opgeslagen voordat de mail op de mailserver wordt verwijderd. (Transactie 1) 2. Start voor elk bericht op de queue een proces “Ontvang retour bericht”. Per proces doorloop je de volgende stappen, zie ook Figuur 7: verwerk retour bericht. (Transactie 2) 2.1. Bepaal de afzender van het retourbericht op basis van het from element in de email header. Als de afzender douane (*bdsbb*@otpnet.nl2) is dan stap 2.2 uitvoeren anders stap 2.2 overslaan en direct doorgaan naar stap 2.3. 2.2. Translate het NLBB16 edi bericht naar een AID NLRET xml bericht op basis van de in de configuratie gespecificeerde xslt en valideer de aangemaakte xml op basis van de NLERS.xsd. 2.3. Sla het retourbericht op in de “NLRET” queue 2.4. Sla de het transactie resultaat op in de audit trail (mijlpaal nr15). Alternatieve Flow: 1. In Stap 2 blijkt het bericht niet leesbaar. Dan exception opslaan in de audit trail met als mijlpaal nummer 16 2. Indien een exception optreed tijdens stap 2.2 of 2.3 Sla dan het transactie resultaat en de foutmelding op in de audit trail met als mijlpaal nummer 17 of 18 (afhankelijk van het moment waarop de fout optreed) en als opmerking de foutboodschap. 3. Stuur het audit record in een email aan de beheerder Resultaat: 1. Goed: Het bericht is staat in het xml formaat in de NLRET queue. 2. Fout: De beheerder is geïnformeerd en de exception is als onderdeel van het audit record opgeslagen in de database. Logging: Mule logt één record per activiteiten welke in de bovenstaande flow en alternatieve flow worden uitgevoerd. Één record bevat altijd: 1. 2. 3. 4.

2

Een timestamp Het unieke transactienummer Het resultaat van de activiteit (bijv. compression succesvol) Indien de activiteit niet succesvol is: alle exception details in de log opnemen.

Het exacte adres moet vast worden gesteld na de configuratie van de Vishub private mailserver.

Blad 25 van 42


3.7 Verwerk retour berichten Retourberichten zijn berichten die aan de visser worden geadresseerd. In onderstaand proces worden de opgeslagen retourberichten op een eenduidige manier verwerkt. Zie onderstaand model: 3.7.1 Model

Verwerk retour bericht Mule

Herleid bericht volgnummer & Bepaal ontvanger

Translate & Validate message

Publieke Mailserver

Compress & encrypt message

Send message

Store transaction



MySQL

Valideer op basis van onze configuratie

Alle verstuurde berichten worden opgeslagen in de database

configuratie

Log QUEUE

audittrail

NLRET

MySQL



Figuur 8: verwerk retour bericht

3.7.2 Use case Actoren: publieke mailserver; Mule; beheerder Trigger: vanuit Mule is een bericht op de “NLRET” queue geplaatst. Flow: 1. Herleid de SID en het originele bericht volgnummer uit de tabel referenties op basis van het unieke Vishub berichtvolgnummer(zit in NLRET [RN]). Overschrijf het volgnummer in het bericht (NLRET RN)weer met het originele volgnummer uit onze referenties tabel. 2. Valideer het bericht op basis van de NL_ERS xsd en translate de message van de NL_ERS definitie naar de NLVIS-Basis definitie. Raadpleeg de configuratie voor de actuele versie van de xslt. Valideer het bericht op basis van het NLVIS-Basis XSD. 3. Encrypt en comprimeer het bericht op basis van het versleutelproces wat is beschreven in “Beveiligingsprotocol berichten Vishub v1.0.docx”. (De public ECC key van de ontvanger is opgeslagen in onze database en te herleiden op basis van het SID) Blad 26 van 42


4. Creëer een email, bepaal het ’to’ e-mail adres op basis van de SID uit de referenties tabel, de afzender is Vishub. De body van de mail bevat het gecomprimeerde en encrypte retour bericht. Verstuur het email bericht aan de publieke mailserver. 5. Sla de het transactie resultaat op in de audit trail (mijlpaal nr 19). Ook het nieuw aangemaakte bericht wordt als plain xml weggeschreven in de berichten tabel en gerelateerd aan de audittrail. Alternatieve Flow: 1. In Stap 1 blijkt het bericht geen berichtvolgnummer te bevatten dat Vishub herkent. Dan exception opslaan in de audit trail met als mijlpaal nummer 20 2. In Stap 1 blijkt het bericht te refereren aan berichtvolgnummer 999. Het betreft dan een exception bij de AID. In dit geval moet er ook een exception bij Vishub optreden. Dan exception opslaan in de audit trail met als mijlpaal nummer 21. 3. Indien een exception optreed tijdens stap 2 t/m 4 Sla dan het transactie resultaat en de foutmelding op in de audit trail met als mijlpaal nummer 22, 23 of 24 (afhankelijk van het moment waarop de fout optreed) en als opmerking de foutboodschap. Het kan dus ook zijn dat er een exception optreed naar aanleiding van een (fout)bericht van de AID. 4. Stuur het audit record in een email aan de beheerder Resultaat: 1. Goed: Het bericht is ontvangen door de publieke mailserver. 2. Fout: De beheerder is geïnformeerd en de exception is als onderdeel van het audit record opgeslagen in de database. Logging: Mule logt één record per activiteiten welke in de bovenstaande flow en alternatieve flow worden uitgevoerd. Één record bevat altijd: 1. 2. 3. 4.

Een timestamp Het unieke transactienummer Het resultaat van de activiteit (bijv. compression succesvol) Indien de activiteit niet succesvol is: alle exception details in de log opnemen.

Blad 27 van 42


4 Beschrijving van de componenten Onderstaande paragraaf beschrijft de logische componenten in meer detail en stelt algemene eisen aan de componenten.

4.1 De publieke mailserver Dit is een standaard mailserver. De initiële NLVIS-Basis berichten worden door de visser aan deze mailserver aangeboden. Retourberichten worden door deze mailserver aan de visser aangeboden. De mailserver logt alle verwerking. Er wordt geen kopie van de verstuurde berichten opgeslagen, de mailserver logt alleen dat het bericht is verstuurd.

4.1.1 Eisen: 1. De mailserver slaat ontvangen berichten direct op in de database 2. De mailserver handelt alle ontvangst en verstuur opdrachten transactioneel af zodat er nooit berichten kwijt kunnen raken. 3. De mailserver logt alle activiteiten. 4. Uitgaande berichten worden direct verstuurden, werkt dit niet dan worden ze altijd in de delivery queue vastgehouden totdat ze alsnog kunnen worden verstuurd. 5. De mailserver is voor email verkeer vrij toegankelijk vanuit het publieke domein en zal berichten ontvangen van alle mailaccounts van een geregistreerd domein. 6. De mailaccounts van de vissers(schepen) moeten opgenomen kunnen worden in een “safe sender” lijst zodat email van de vissers nooit als spam kan worden gewaarmerkt. 7. De mailserver moet spamfiltering ondersteunen. 8. De publieke mailserver moet altijd bereikbaar zijn

Blad 28 van 42


4.2 De private mailserver Dit is een standaard mailserver. Daarnaast is de mailserver via een VPN tunnel aangesloten op het private domein van het OTP. Berichten die verstuurd worden vanuit Vishub aan een overheidspartij worden door de mailserver afgehandeld en aangeboden aan de OTP. De mailserver logt alle verwerking. Er wordt geen kopie van de verstuurde berichten opgeslagen. De mailserver logt alleen dat het bericht is verstuurd. 4.2.1 Eisen: 1. De mailserver slaat ontvangen berichten direct op in de database 2. De mailserver handelt alle ontvangst en verstuur opdrachten transactioneel af zodat er nooit berichten kwijt kunnen raken. 3. De mailserver logt alle activiteiten. 4. Uitgaande berichten worden direct verstuurden, werkt dit niet dan worden ze altijd in de delivery queue vastgehouden totdat ze alsnog kunnen worden verstuurd. 5. De mailserver is voor email verkeer alleen toegankelijk vanuit het private OTP domein vanuit ons eigen Vishub domein. 6. De mailserver is niet bekend in het publieke domein en kan ook geen mail versturen of ontvangen van en naar het publieke domein. 7. De beheerder moet via de vpn verbinding wel de mailaccounts van de private mailserver kunnen inzien en beheren.

4.3 Message processing Het message processing component is gebaseerd op Mule3. Hierin worden stateless processen gedefinieerd die als één transactie door Mule worden afgehandeld. 4.3.1 Eisen: 1. Alle stateless processen worden transactioneel afgehandeld. 2. De message processing engine moet in staat zijn om uitgebreid alle handelingen en exceptions te loggen. 3. De message processing engine moet schaalbaar en beheersbaar zijn met behulp van standaard tooling en voorzieningen. 4. De message processing engine moet kunnen connecten naar Java, mail adapters, queuing, database connectors, flat files en zelf ontwikkelde connectors. 5. De message processing engine moet transport en transformatie van (en naar) database, xml en edi kunnen uitvoeren. 3

Meer uitgebreide beheersmogelijkheden (bijv. software failover en management tools) zijn te koop, dit is een overweging die beheer moet maken. Zie www.mulesoft.com voor een compleet overzicht van alle opties en functies van de message processing engine.

Blad 29 van 42


4.4 Maatwerk Java Functies De maatwerk Java functies worden aangeroepen vanuit Mule om specifieke taken uit te voeren. Deze functies zijn: •

• •

•

• • •

•

•

• •

Het ophalen en opslaan van een mailbericht binnen een enkele transactie; de mail wordt dus pas van de mailserver verwijderd wanneer deze is opgeslagen in de message processing engine. Decryptie; het uitpakken van een encrypted(versleutelde) bijlage.* Authenticatie van vissers; het uitgepakte bericht bevat een signature. Deze zal door ons systeem worden vergeleken met de beschikbare signature in ons systeem. Er is dus onderscheid tussen enerzijds encryptie als beveiliging van het bestand tijdens transport en anderzijds authenticiteit van de afzender te waarborgen. Valideren berichten; wanneer decryptie of translatie heeft plaatsgevonden zal Vishub het nieuw verkregen bericht altijd valideren. In eerste instantie wordt gekeken of er wel een xml bestand is aangeleverd, in tweede instantie wordt de xml bestandsstructuur op basis van de in Vishub vastgelegde XSD gevalideerd. Na deze validatie is wat Vishub betreft het bericht volledig gevalideerd. Er worden geen businessrules opgenomen die ook moeten worden gevalideerd. Transactie wegschrijven in de audit trail; van alle afgeronde transacties wordt een record weggeschreven in de database. Creëren retourbericht; indien de ontvangst van een NLVIS-Basis bericht niet goed gaat creëert deze functie een retourbericht. Vervangen van de bericht volgnummers; De bericht volgnummers die de vissers meegeven in de berichten worden door Vishub vervangen voordat een bericht wordt doorgestuurd. Bij retourberichten vervangt Vishub het volgnummer weer door het originele nummer. Translatie van berichten; Voordat een bericht wordt afgeleverd bij een van de overheidspartijen vertaalt Vishub het bericht naar het specifieke formaat van de afnemer. Dit formaat en de benodigde translatie zijn vastgelegd in de Vishub configuratie en zal per afnemer verschillen. Exceptions registreren en beheerder notificeren; wanneer een exception optreed, bijvoorbeeld als een bericht niet valide is, een visser niet bij ons bekend (meer) is of een translatie niet lukt, zal altijd een mail worden verstuurd naar de beheerder. Ook zal de informatie over de exception worden weggeschreven in de audittrail. De logfile bevat altijd alle detailinformatie over exceptions. Encryptie van retourberichten; het inpakken van een nog niet versleutelde bijlage* Het transactioneel afleveren van een mailbericht aan de mailserver; berichten mogen in Mule pas verwijderd worden als de mail in door de mailserver is geaccepteerd en opgeslagen.

* Naast encryptie (ECC) wordt ook compressie (GZIP) toegepast op de bericht bijlage om bandbreedte te besparen. Daarnaast zal een stukje software worden opgeleverd voor de compressie, encriptie en authenticatie aan boord van het schip. Voor dit stukje software zal een separaat ontwerp worden gemaakt.

Blad 30 van 42


4.5 Database Er wordt een standaard relationele database op basis van MySQL ingezet. De database wordt gebruikt als datastore voor de message processing engine en het queuing mechanisme. Verder zullen een aantal eigen tabellen worden opgeslagen in de database om de vissers, de afnemers, de ontvangen berichten, de configuratie, de audit trail, referenties en wellicht nog andere technische hulptabellen op te slaan. De database voor de mailservers wordt nog bepaald en is afhankelijk van het gekozen mailplatform.

4.6 Configuratie De configuratie van het systeem moet worden opgeslagen in de database. Voor het aanpassen van de configuratie is een standaard database editing tool nodig. Deze is in de vorm van de MYSQL workbench gratis beschikbaar. Hiermee kan de beheerder de tabellen raadplegen en wijzigen. 4.6.1 Eisen: 1. De configuratie van het systeem moet worden opgeslagen in de database. 2. De configuratie waarden worden elke keer dat ze nodig zijn opgevraagd bij de database. 3. Een aanpassing van de configuratie waarden heeft direct effect. 4. De configuratie bevat minimaal de tabellen zoals gespecificeerd in hoofdstuk 5

Blad 31 van 42


4.7 De audittrail De audittrail slaat alle mijlpalen in het verwerkingsproces op. Tevens wordt in relatie tot de audittrail ook het originele bericht en het verstuurde bericht in de tabel berichten opgeslagen. De ontvangen NLVIS-Basis berichten komen encrypted binnen en worden encrypted opgeslagen. Voor retourberichten geld ook dat Vishub de ontvangen berichten opslaan. De door ons encrypte en verstuurde retourberichten worden ook opgeslagen. Dit om onomstotelijk vast te kunnen stellen wat Vishub verwerkt heeft. Daarnaast worden de volgende waarden in de audit trail records opgeslagen: • • • • • • • •

de Process instance ID (geeft een referentie naar het transactieproces en de bijbehorende logging van Mule) Visser SID [fk] (geeft een referentie naar de gebruiker die het bericht heeft ingestuurd indien het bericht is ingestuurd door een visser) Afnemer ID [fk] (geeft een referentie naar de afnemer indien de afnemer in de transactie al bekend is) Message type (geeft aan welk type bericht is ontvangen, vooral ook relevant bij retourberichten) Volgnummer Vishub (Geeft de unieke referentie van het bericht aan waarmee de retourberichten aan het oorspronkelijke bericht te relateren zijn. Volgnummer origineel bericht (Geeft de unieke referentie van het bericht aan waarmee de retourberichten aan het oorspronkelijke bericht te relateren zijn. Timestamp (huidige datum en tijd tot op de seconde) Mijlpaal resultaat (omschrijving van het resultaat van de transactie, alle mogelijke mijlpalen zijn opgenomen in paragraaf 5.8.

4.7.1 Eisen: 1. De audittrail van het systeem moet worden opgeslagen in de database. 2. Voor het inzien van de audittrail is een standaard database editing tool nodig. Hiermee kan de beheerder de tabellen raadplegen. 3. De records van de audittrail moeten kunnen worden gesorteerd en gefilterd met behulp van de standaard tool. 4. De berichten en de bijbehorende audit trail worden bewaard totdat deze handmatig worden verplaatst of verwijderd. 5. Verplaatsen of verwijderen van records dient door de beheerder te gebeuren op basis van de overeengekomen bewaartermijn. 6. Bij de berekende opslagcapaciteit is voor de audittrail uitgegaan van een maximale bewaartermijn van 5 jaar. 7. Voor performance redenen moet data uit de audittrail (en daarmee ook de ontvangen en verstuurde berichten) al na een jaar in een secundaire database worden geplaatst. Dit beperkt de indexeer last op de database en verbeterd de responsetijd van de database.

Blad 32 van 42


4.8 Logging De mailservers, Mule en Java functies loggen interne bewerkingen en bovenal de exceptions die optreden. Log records bevatten altijd timestamps en de unieke referenties van processen en berichten. 4.8.1 Eisen: 1. Logging wordt na 3 maanden overschreven om de dataopslag te beperken. 2. Indien gewenst kan de logging worden weggeschreven naar externe media voordat deze wordt overschreven(dit is dan wel een handmatige beheer procedure). 3. De logfile is toegankelijk via een remote fileshare.

4.9 Schatting omvang data opslag In de onderstaande paragraaf is een schatting gedaan van de benodigde opslagcapaciteit •

Schatting omvang: 276.000 ontvangen berichten * 5kb (gecomprimeerd NLVIS-Basis bericht) = 1.380.000 KB ofwel 1,4 GB per jaar.

•

1.564.000 berichten tussen Vishub en OTP * + 267.000 berichten = ongeveer 2miljoen transacties in Mule * 10kb per audit record = 20 GB per jaar.

•

Eenmalig 50 GB reserveren voor programmatuur hulptabellen en configuratie

•

2 miljoen transacties in Mule per jaar = 500.000 per Kwartaal * 20kb logging = 10GB Eenmalig.

•

Om te beginnen 81,4 GB opslag reserveren voor het eerste jaar en rekening houden met een mogelijke groei naar 230 GB voor de opslag gedurende 5 jaar. Dit is exclusief de benodigde opslag ruimte voor de operating Systems en de mailservers (minimaal 20 GB Max 150GB).

Bij de opzet van de infrastructuur dient men rekening te houden met een mogelijke groei naar een totaal van 400GB aan dataopslag.

Blad 33 van 42


5 Datamodel Onderstaande paragraaf geeft een opzet voor het datamodel wat nodig is om voor de maatwerk functionaliteit gegevens op te slaan.

5.1 Vissers Vissers SID Name Email Public Key

Toelichting Relatienummer van de schipper bij het PVis. Bijv. 1 Bijv. Kapitein Rob Bijv. [email protected] Bijv. Key 1234567890

Tabel 1: Tabel met alle gegevens van de vissers.

5.2 Schepen Vissers Scheeps kenteken Name

Toelichting Uitwendig kenteken van he tschip. Bijv. UK158 Bijv. Willem Jacob

Tabel 2: Tabel met alle gegevens van de Schepen.

5.3 Afnemers Afnemers ID Name Email Routering

Toelichting Bijv. 1 Bijv. AID Bijv. [email protected] Via ‘OTP’ of ‘niet via OTP’

Tabel 3: Tabel met gegevens van alle afnemers van berichten

5.4 Referenties tabel Referenties Visser SID [fk]

Volgnummer origineel bericht Volgnummer Vishub Creation date

Toelichting ID van de visser die het NLVIS-Basis bericht heeft aangeboden. Of voor wie het retourbericht is bestemd. Bijv. 1 Dit is het volgnummer wat het eLogboek meegeeft aan het bericht en wat uniek is per afzender. Dit is het volgnummer van de Vishub genereert en wat uniek is per bericht. Dit is de datum waarop de referentie is aangemaakt

Tabel 4: Tabel met referenties tussen de originele volgnummers en de door ons gegenereerde(unieke) volgnummers.

Blad 34 van 42


5.5 Audit trail Audit trail Process instance ID Visser SID [fk]

Afnemer ID [fk]

Message type Volgnummer Vishub [fk] Volgnummer origineel bericht [fk] Timestamp Mijlpaal resultaat Toelichting resultaat Bron Bericht ID [fk] Resultaat Bericht ID [fk]

Toelichting Intern nummer van Mule, uniek voor deze transactie ID van de visser die het NLVIS-Basis bericht heeft aangeboden. Of voor wie het retourbericht is bestemd. Bijv. 1 ID van de afnemer, indien al bekend in het vertaal en verstuur proces. Of het ID van de partij die het retourbericht stuurt. Bijv. 1 Is het een NLVIS-Basis bericht of een NLRET bericht Intern Vishub referentienummer van het bericht hiermee is het bericht binnen de Vishub uniek. Dit is het volgnummer wat het eLogboek meegeeft aan het bericht en wat uniek is per afzender. Tijd van wegschrijven van het record in de database Omschrijving van de mijlpaal Inhoudelijke foutmelding van de exception indien deze is opgetreden. Verwijzing naar het bronbericht bijv. 1001 Verwijzing naar het resultaat bericht wat is geproduceerd bijv. 100

Tabel 5: Tabel met audit trail records. Per transactie in Mule moet een record worden weggeschreven. Deze tabel dient als bewijslast van onze verwerking en historie op basis waarvan verwerking kan worden gereproduceerd. (reproductie van de verwerking is geen functioneel onderdeel van het vishup systeem.

5.6 Berichten Berichten ID Value

Toelichting Bijv. 1001 Bijv. BLOB met encrypted tekst

Tabel 6: Tabel met alle ontvangen NLVIS-Basis berichten (encrypted opgeslagen)

Blad 35 van 42


5.7 Distributielijst Distribution list Vissers ID [fk] Scheeps kenteken [fk]

Afnemer ID [fk] Filter conditie Bericht definitie Soort transformatie Translatie versie

Toelichting Bijv. Visser ID = 1 (Of ID = ALL, iedereen stuurt verplicht berichten aan deze afnemer.) Bijv. Scheeps kenteken = UK158 (Of kenteken = ALL, Alle schepen sturen berichten aan deze afnemer.) Bijv. 1 Bijv. Alleen versturen als het bericht een NLPRN of NLRTP of element bevat Referentie naar de xsd. Bijv. AID.xsd Aangeven of het de transformatie op basis van XSLT of Java gebeurt. Bijv. XML of EDI Referentie naar de xslt of JAR. Bijv. basis_to_aid_v1.xslt of basis_to_douane_v1.jar

Tabel 7: Tabel met de distributie details en instructies. Alle records hebben verplicht een ingangsdatum en zijn dus tijdgebonden. Voor verplichte distributie van berichten is 1 record voor alle Vissers voldoende.

Blad 36 van 42


5.8 XML met scheepsinfo Hieronder is het model van de xml met scheepsinfo opgenomen.

Blad 37 van 42


5.9 Lijst van mijlpalen proces Ontvangst van berichten

Bepaal Afnemers

Verstuur berichten

Ontvang retour berichten

Verwerk retour berichten

Diversen

Nr 1

Mijlpaal omschrijving Bericht ontvangst succesvol verwerkt

Resultaat Verwerking succesvol

2 3 4 5 6 7 8 9 10

Exception tijdens decryption Exception tijdens authenticatie Exception tijdens validatie input Exception tijdens opslag Bepalen afnemers succesvol verwerkt Exception tijdens bepalen afnemers Exception tijdens filteren afnemers Exception tijdens opslag kopieën Bericht succesvol verstuurd

Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking Verwerking succesvol Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking Verwerking succesvol

11 12 13 14

Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking

15

Exception tijdens vervangen referentienummer Exception tijdens transformatie Exception tijdens validatie output Exception tijdens aanbieden bericht aan private mailserver Retourbericht succesvol ontvangen

16 17 18 19

Exception tijdens uitlezen retourbericht Exception tijdens translatie douane retourbericht Exception tijdens opslaan retourbericht Retourbericht succesvol verwerkt

Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking Verwerking succesvol

20 21 22 23 24

Exception vervangen bericht volgnummer Volgnummer 999: Technische fout AID Exception tijdens validatie retour Exception tijdens encryptie Exception tijdens aanbieden retour bericht aan publieke mailserver Exception tijdens ophalen email

Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking Exception tijdens verwerking

25

Verwerking succesvol

Exception tijdens verwerking

Tabel 8: Lijst met mogelijke mijlpalen voor de audit trail.

Blad 38 van 42


6 Beheer Omdat het Vishub systeem asynchrone transacties afhandelt en niet alle exceptions aan de eindgebruiker worden gepresenteerd is beheer van essentieel belang. Beheer moet dan ook proactief zijn betrokken bij de dagelijkse operatie van het Vishub systeem. Voor zover mogelijk wordt beheer bij de componenten ingekocht als een zogenaamde gehoste applicatie. Met name voor de mailservers is dit gewenst en gebruikelijk. (Het onderhouden van een mailserver is ook arbeidsintensief en specialistisch werk).

6.1 Toegang eisen • • • • •

De omgeving (het domein) waarop het Vishub systeem draait is beveiligd. Alleen de publieke mailserver kan mail ontvangen en versturen met het publieke domein. Alleen de private mailserver kan mail ontvangen en versturen met het private OTP domein. De beheerder kan middels een VPN verbinding toegang krijgen tot de omgeving waarbinnen alle Vishub servers opereren. De beheerder kan alle files, tabellen en operating systemen op de Vishub servers raadplegen en indien nodig aanpassen en beheren.

6.2 Tools voor beheer De beheerder heeft de beschikking over diverse standaard tools de onderstaande beheerstaken uit te kunnen voeren: Tool Altova XML Spy Altova Mapforce MySQL Workbench Mailclient

Blad 39 van 42

Beheerstaken Aanpassen en documenteren berichtdefinities Aanpassen en documenteren mappings en translaties Raadplegen en aanpassen tabellen Periodiek de spam verwijderen en safe-sender lijst onderhouden


6.3 Eisen aan beheer Voor een gegarandeerde werking van de ontwikkelde software dienen de volgende eisen aan beheer te worden ingevuld: •

• • • • •

een upgrade naar een betaalde Mule Enterprise omgeving. De kosten hiervoor worden nog nagegaan bij de leverancier. Deze upgrade biedt: o Performance & Stability High availability and failover Retry policies for self-healing connectivity Multi-resource transactions o Management Tools Management and monitoring Patch management Migration tools o Documentation & Support Commercial-grade documentation Online knowledge base Technical support Platform certification een hosted public & private mail environment. Inclusief een secundaire mailserver voor failover op basis van IP of DNS routering. Gebruik een SAN voor de opslag van data, dit voorziet in een hoge betrouwbaarheid en beveiliging. Een VPN verbinding voor de beheerder om remote het systeem te kunnen benaderen. Standaard tooling om de database tabellen en content te kunnen beheren. Periodiek moet de spam worden doorgenomen en verwijderd.

Blad 40 van 42


7 Niet functionele eisen •

• • • •

• • • • • • •

•

Voor de correcte werking van Vishub is operationeel beheer nodig in de minimale vorm van een applicatiebeheerder en een functioneel beheerder. Uitgangspunt is dat het PVis dit organiseert. De private mailserver moet een aansluiting hebben op de OTP productie omgeving. Hosting van de fysieke machines in een professionele omgeving is vereist om stabiliteit te waarborgen. Het gebruik van de encrytie-key moet als randvoorwaarde voor het gebruik van het systeem door vissers worden afgedwongen. Inkomende email berichten moet binnen 5 minuten weer zijn verwerkt tot 1 of meerdere Uitgaande berichten. Uitgaande van de berichtvolumes genoemd in de “Berichtstroomdefinitie eLogboek v10.” Het systeem moet 99,5 % uptime per jaar bieden. Met een maximaal aaneengesloten downtime van 6 uur. De publieke mailserver moet altijd benaderbaar zijn en voorzien zijn van een secundair afleveradres. De publieke mailserver moet dubbel zijn uitgevoerd, bijvoorbeeld door een hot standby of alternatief afleveradres. Na een hardware of software crash moet het systeem binnen een uur hersteld kunnen zijn. Failover & back-up moeten zijn ingeregeld. Back-up off-site regelen, ook voor het SAN. Behalve verticaal te opschalen met meer CPU en meer memory moet ook horizontaal opschalen een mogelijkheid zijn. Dit is mogelijk door meerdere Mule instanties om 1 mailserver te laten draaien. (Met behulp van Mule Enterprise high availability is horizontaal schalen over meerdere machines goed in te regelen. Horizontaal schalen bereikt veel minder snel een limiet dan verticaal schalen.) Gezien de te verwachten bericht volumes is 1 krachtige multi-core machine meer dan genoegen om de te verwachten load met Mule te verwerken.

Blad 41 van 42


8 Technische opzet Voorbeeld voor een stack van fysieke componenten om de logische componenten in te plaatsen:

Functioneel is ingeschat dat het systeem de volgende technische voorzieningen omvat: • • • • • •

4

Een dedicated server met een gehost OS en daarop een gehoste e-mail voorziening. 4 Een dedicated server met een gehost OS en daarop een door ons beheerde message processing applicatie op basis van Mule & Java5 Een dedicated server met een volledig gehost OS en daarop een gehoste e-mail voorziening voor niet publieke routering van berichten met de OTP.6 Een centrale opslagvoorziening (SAN) om alle inhoudelijke data van bovenstaande voorzieningen in op te kunnen slaan7 Een router voor het opzetten van de dedicated (ipsec) vpn tunnel met het OTP. Een cliënt vpn connectie naar het domein waarbinnen bovenstaande voorzieningen draaien. Dit om beheer uit te kunnen voeren op door ons beheerde applicaties en de configuratie tabellen.

Deze dienst moet door middel van redundantie of failover altijd (99,9%) beschikbaar zijn.

5

Deze dedicated server moet in de productie situatie zijn uitgerust met een hardwarematige security key (hoogstwaarschijnlijk in de usb poort), een hoge (99,5%) beschikbaarheid hebben en in geval van failover moet de server binnen een uur weer up zijn inclusief een (alternatieve) security key. 6

De OTP ofwel Overheidstransactiepoort is gebaseerd op een beveiligd netwerk voor de routering van berichten tussen de overheid en het bedrijfsleven. 7

De centrale opslagvoorziening moet dagelijks worden gebackuped en door middel van redundantie of failover altijd (99,9%) beschikbaar zijn.

Blad 42 van 42


VISHUB Ontwerp. Onderwerp: Vishub. Datum: 15 oktober Slim geregeld, goed verbonden

Recommend Documents