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

Transcriptie

1 VISHUB Ontwerp Onderwerp: Vishub Versie: Definitief Datum: 15 oktober 2010 Auteur: Slim geregeld, goed verbonden In licentie gegeven op grond van een Creative Commons Licentie. Historie: Versie Auteur Toelichting 0.1 MvdP Initiële opzet 0.2 MvdP Aanpassingen nav overleg met RA, IG, TG, BK 0.3 MvdP Sheet met commentaar verwerkt 1.0 MvdP Use cases toegevoegd 1.09 MvdP Opmerkingen Tobias en Robin verwerkt 1.1 MvdP Structuur aangepast, opmerkingen Joost & Tobias verwerkt 1.2 MvdP Correctieberichten,technical errors en andere issues verwerkt. 2.0 MvdP Distributiemechanisme; xml > edi translatie; proces voor edi retourberichten en andere issues verwerkt en opgenomen 2.01 MvdP Mijlpalen bijgewerkt en document tekstueel nagelopen 2.02 MvdP Kolom RS eruit bij mijlpalen, text aangescherpt mbt de NLVIS- BASIS-TechnicalError-v1.11.xsd, opzet bericht volgnummer aangepast, aanlevering EDI berichten (xml data als basis gebruiken) Toevoegen mail als attachement 2.1 MvdP Filter berichten op schip ID s (change 295) Aanpassingen na review Rutger Gooszen 2.11 MvdP 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 RAu Opmerking open source licentie toegevoegd op advies van Corvers. Distributielijst: Naam Rol Akkoord Robin Audenaerdt Casusmanager Ja/Nee Rutger Gooszen Architect Alleen Review Iwanjka Geerdink Bouw Vishub Alleen Intake Tobias Groothuyse Bouw Vishub Alleen Intake Mike Bandhoesingh Tester Vishub Alleen Intake Blad 1 van 42

2 Inhoudsopgave Inhoudsopgave Inleiding Achtergrond Scope De toekomst Organisatorische context Gerelateerde documenten Relatie met supd@x concept Globale opzet Samenhang van de componenten Beschrijving van de samenhang Invulling van componenten met Open source en open standaarden Adressering en transport van berichten in relatie tot de AID Bericht dialoog Adressering en transport van berichten van de visser aan Vishub Proces van verwerking Versturen bericht aan Vishub Use case: Ontvangst van berichten Model Use case Bepalen van afnemers Model Use case Vertaal en verstuur berichten Model Use case Versturen van bericht uit vishub Use case: Ontvang retour berichten Model Use case Verwerk retour berichten Model Use case Beschrijving van de componenten De publieke mailserver Eisen: De private mailserver Eisen: Message processing Eisen: Maatwerk Java Functies Database Configuratie Eisen:...31 Blad 2 van 42

3 4.7 De audittrail Eisen: Logging Eisen: Schatting omvang data opslag Datamodel Vissers Schepen Afnemers Referenties tabel Audit trail Berichten Distributielijst XML met scheepsinfo Lijst van mijlpalen Beheer Toegang eisen Tools voor beheer Eisen aan beheer Niet functionele eisen Technische opzet...42 Blad 3 van 42

4 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

5 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 ) 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 ) Blad 5 van 42

6 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 gaat de Vishub over naar beheer en zal het Productschap Vis eigenaar worden van het systeem. Blad 6 van 42

7 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) Encryption Mailclient Decryption encrypted messages Vishub mailserver Decryption Encryption Vishub engine elogboek Software aan boord ontvangen e-logboek bericht Versturen retourberichten Beheren distributielijst ontvangen KVO/retour bericht XML translatie e-logboek bericht OTP Beheren adreslijsten Beheren accounts Opstellen sub berichten verzenden sub-berichten Beheren autorisatie CBS/PO Decryptie van berichten Encryptie van retour berichten 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

8 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. Berichtstroomdefinitie elogboek v10.pdf Intake rapportage elogboek Visserij v11.pdf 3. NLVIS Message Implementation Guide 1.11.pdf 4. elogboek encryptie-add-on ontwerp v0.1.doc 5. Beveiligingsprotocol berichten Vishub v1.0.docx 1.6 Relatie met concept De opzet van het Vishub systeem is gebaseerd op het concept wat is ontwikkeld voor import van veterinaire containers in de haven van Rotterdam. Het 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

9 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 met vissers, producentenorganisaties en visafslagen 2. Een private mailserver, dedicated voor de 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

10 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

11 2.1 Samenhang van de componenten In het model hieronder is de samenhang van logische componenten weergegeven Functionele componenten elogboek bericht Retourbericht Bericht aan PO en Visafslag Publieke Mailserver VISHUB Private Mailserver Bericht aan de OTP Retourbericht van de OTP 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

12 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 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

13 2.3 Adressering en transport van berichten in relatie tot de AID Visserij Sector GBO LNV software vaartuig OTP.NL Att: goed.XML Att: XML ERS POSTBUS Vishub XML Att: goed.XML ERS SERVICELAAG NL XML Att: goed.XML LNV-MAILADRES ERS VERWERKINGSLAAG NL BSN: Mail: 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, 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 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

14 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 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 prod.nlvis@vishub.nl 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 prod.nlvis@vishub.nl 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

15 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 verbonden en zijn ook de enige content die de mail mag bevatten 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 bericht wordt verzonden naar account prod.nlvis@vishub.nl op de Vishub publieke mailserver Indien deze mailserver niet bereikbaar is wordt het bericht bij de secundaire mailserver afgeleverd door middel van de DNS failover. 2. Het 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

16 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: Model elogboek bericht Mule Publieke Mailserver Get message from mail Decrypt & authenticate & validate message Store message Store transaction Alle ontvangen berichten worden opgeslagen in de database QUEUE Handle exception & Store transaction Creëer technical error message MySQL Log alle stappen in het proces Plaats het NLVIS-basis bericht in een queue Decript en authenticeer & valideer op basis van onze configuratie Bewaar het resultaat van de transactie in de audittrail configuratie Log QUEUE NLVIS- BASIS audittrail Storage MySQL Maatwerk Functionaliteit Transactie 1 Transactie 2 Figuur 4: Ontvangst en decryptie van berichten Use case Actoren: publieke mailserver; Mule; beheerder Trigger: Mule verwerkt elke 5 seconden de binnengekomen op de publieke mailserver. Blad 16 van 42

17 Flow: 1. Check op binnengekomen mail op de publieke mailserver. De berichten worden opgehaald van het 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 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 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 . 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 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

18 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

19 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 Model 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 afnemers Mule 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. Handle exception & Store transaction 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 Bewaar het resultaat van de transactie in de audittrail Log configuratie QUEUE NLVIS- BASIS QUEUE Afnemers audittrail MySQL Storage Maatwerk Functionaliteit Figuur 5: bepalen afnemers 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

20 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 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. Een timestamp 2. Het unieke transactienummer 3. Het resultaat van de activiteit (bijv. translatie succesvol) 4. Indien de activiteit niet succesvol is: alle exception details in de log opnemen. Blad 20 van 42