Het platform: verschil tussen versies

Uit DSP
Ga naar: navigatie, zoeken
(Gebruik van het Platform)
(Uitwisselen van berichten)
 
(13 tussenliggende versies door 5 gebruikers niet weergegeven)
Regel 13: Regel 13:
  
 
=Gebruik van het Platform=
 
=Gebruik van het Platform=
De deelnemers communiceren via het DSP met synchrone webservices met elkaar. De primaire taak van het DSP hierbij is het valideren, ontvangen en afleveren van aangeboden berichten. Het DSP valideert aangeboden berichten t.o.v. de afgesproken XSD’s en de status van het proces (bijv. een opdrachtgereed bericht wordt pas verwerkt als de relevante AG’s succesvol zijn beoordeeld). Als een bericht is verwerkt heeft het DSP de verantwoordelijkheid om het bericht bij de geadresseerde af te leveren. Mocht de geadresseerde niet bereikbaar zijn zal het DSP na 15 minuten, 2 uur en 24 uur een nieuwe poging doen. Tussen deze pogingen en daarna kan functioneel beheer het bericht op aanvraag handmatig opnieuw aanbieden.
+
De deelnemers communiceren via het DSP met synchrone webservices met elkaar. De primaire taak van het DSP hierbij is het valideren, ontvangen en afleveren van aangeboden berichten. Het DSP valideert aangeboden berichten t.o.v. de afgesproken XSD’s en de status van het proces (bijv. een opdrachtgereed bericht wordt pas verwerkt als de relevante AG’s succesvol zijn beoordeeld). Als een bericht is verwerkt heeft het DSP de verantwoordelijkheid om het bericht bij de geadresseerde af te leveren. Zie [[Aflevergarantie DSP]].
 
<br>
 
<br>
 
<br>
 
<br>
De communicatie via het DSP is beveiligd via encryptie, authenticatie en autorisatie op basis van SSL Tunneling, user en toegekende rol.
+
De communicatie met het DSP is beveiligd via encryptie op basis van SSL Tunneling, authenticatie en autorisatie.
  
 
=Gebruikte techniek=
 
=Gebruikte techniek=
In het technisch platform van het DSP zijn drie (identieke) applicatieservers beschikbaar; Development “dev”, Quality Assurance “qas”, Production “www”. De development omgeving is voor deelnemers beschikbaar om service en unittests uit te voeren. De Quality Assurance wordt gebruikt voor het uitvoeren van technische-, functionele- en ketentesten.
+
In het technisch platform van het DSP zijn 4 (identieke) applicatieservers beschikbaar.  
De applicatieservers zijn via 4 loadbalancers & firewalls verbonden met de deelnemers.
 
  
Inkomend: dev.dsplatform.nl (development)
+
De A-omgevingen (DSP-QAS en DSP Analytics (QAS))  worden door Mijn Aansluiting gebruikt om (keten)testen uit te voeren. . Deelnemers kunnen gebruik maken van deze omgevingen om bijv. connectiviteits- en integratietesten incl. DSP te kunnen doen.
  
Inkomend: qas.dsplatform.nl (quality assurance)
+
De applicatieservers zijn via loadbalancers & firewalls verbonden met de deelnemers.
 +
* Inkomend: qas.dsplatform.nl (acceptatie)
 +
* Inkomend: www.dsplatform.nl (productie)
  
Inkomend: www.dsplatform.nl (production)
+
Uitgaand verkeer naar de deelnemers gebeurt op basis van een outbound whitelist.
  
Uitgaand verkeer (outbound whitelist)
+
=Uitwisselen van berichten=
 +
Communicatie met het DSP gebeurt op basis van het SOAP 1.1 protocol: Er wordt een XML bericht gestuurd en de ontvanger dient met een synchrone response te antwoorden. Dit kan een zogenaamde "OK"-response zijn of een SOAP Fault. Een "OK"-response is een XML bericht dat voldoet aan de MT_CommonResponse definitie (te vinden in de WSDL's).
 +
 
 +
Om te zorgen dat berichten naar de juiste deelnemer gaan, dient de netbeheerder in het Opdrachtbericht het veld Opdrachtnemer van de juiste aannemer te voorzien. Als de aannemer dan het Opdrachtbericht heeft ontvangen, is de koppeling tussen netbeheerder en aannemer gemaakt en zullen verder berichten worden uitgewisseld op basis van het Opdracht-ID.
 +
 
 +
SOAP Faults dienen door deelnemers '''alleen''' gebruikt te worden bij technische, oplosbare problemen. Het DSP zorgt ervoor dat berichten aan de afgesproken algemene technische en functionele afspraken voldoen. Denk hierbij aan validatie ten opzichte van de XSD's en functionele validaties van het AGAssets bericht.
 +
 
 +
Indien een bericht niet voldoet aan specifieke afspraken tussen een netbeheerder en aannemer zal de ontvanger toch altijd een "OK"-response als antwoord naar het DSP moeten sturen. Vervolgens kan de ontvanger een Bijstelling of Beoordeling bericht sturen om het niet voldoen aan de specifieke afspraken terug te koppelen. Indien deelnemers zich hier niet aan houden kan het proces vastlopen, omdat het DSP een bericht nooit succesvol afgeleverd zal krijgen.
 +
 
 +
Het DSP hanteert een timeout van 5 minuten en zal een bericht na 5 minuten beschouwen als niet afgeleverd en een foutafhandelingsproces starten om aan de [[Aflevergarantie DSP]] te voldoen.
 +
 
 +
De maximale grootte van een bericht inclusief eventuele bijlagen is 50000 kB
 +
 
 +
== Outbound IP adres DSP ==
 +
Mocht de deelnemer inbound whitelisting op basis van IP-adressen willen toepassen dan dient het volgende IP-adres gewhitelist te zijn om DSP berichten te kunnen ontvangen: '''204.79.147.97'''. <br> Dit IP-adres geldt zowel voor alle omgevingen.

Huidige versie van 14 apr 2022 om 09:45

Basisprincipes DSP

Bij het doorlopen van het opdrachtproces bewaakt het DSP de overeengekomen business rules.

  1. Minimale informatie van de opdracht (adres, aannemer, netbeheerder, etc.) wordt eenmalig opgeslagen.
    • In latere berichten worden deze gegevens niet opnieuw verstuurd.
  2. Bij de start van het opdrachtproces worden het OpdrachtID, de aannemer en de netbeheerder aan elkaar gekoppeld.
    • Op basis van het OpdrachtID wordt bepaald of een netbeheerder/aannemer een actie mag uitvoeren voor een opdracht en of deze juist is geadresseerd.
  3. Een bericht wordt alleen verwerkt als het opdrachtproces zich in de juiste status bevindt.
    • Er is altijd maar 1 partij verantwoordelijk voor de volgende stap in het proces. (bijvoorbeeld; als een verzoek tot bijstelling is gedaan door de aannemer moet de netbeheerder de herziene opdracht hebben verstuurd voordat de aannemer een technischgereedbericht mag versturen).


Er zijn 2 uitzonderingen op 3a:

  1. Het versturen van een verzoek tot annuleren door de netbeheerder tussen versturen opdracht en ontvangen TG. Hierdoor wordt het reguliere proces beëindigd en start het annuleringsproces.
  2. De aannemer kan meerdere planningberichten na elkaar sturen zonder tussenkomst van een bericht van de netbeheerder.

Gebruik van het Platform

De deelnemers communiceren via het DSP met synchrone webservices met elkaar. De primaire taak van het DSP hierbij is het valideren, ontvangen en afleveren van aangeboden berichten. Het DSP valideert aangeboden berichten t.o.v. de afgesproken XSD’s en de status van het proces (bijv. een opdrachtgereed bericht wordt pas verwerkt als de relevante AG’s succesvol zijn beoordeeld). Als een bericht is verwerkt heeft het DSP de verantwoordelijkheid om het bericht bij de geadresseerde af te leveren. Zie Aflevergarantie DSP.

De communicatie met het DSP is beveiligd via encryptie op basis van SSL Tunneling, authenticatie en autorisatie.

Gebruikte techniek

In het technisch platform van het DSP zijn 4 (identieke) applicatieservers beschikbaar.

De A-omgevingen (DSP-QAS en DSP Analytics (QAS)) worden door Mijn Aansluiting gebruikt om (keten)testen uit te voeren. . Deelnemers kunnen gebruik maken van deze omgevingen om bijv. connectiviteits- en integratietesten incl. DSP te kunnen doen.

De applicatieservers zijn via loadbalancers & firewalls verbonden met de deelnemers.

  • Inkomend: qas.dsplatform.nl (acceptatie)
  • Inkomend: www.dsplatform.nl (productie)

Uitgaand verkeer naar de deelnemers gebeurt op basis van een outbound whitelist.

Uitwisselen van berichten

Communicatie met het DSP gebeurt op basis van het SOAP 1.1 protocol: Er wordt een XML bericht gestuurd en de ontvanger dient met een synchrone response te antwoorden. Dit kan een zogenaamde "OK"-response zijn of een SOAP Fault. Een "OK"-response is een XML bericht dat voldoet aan de MT_CommonResponse definitie (te vinden in de WSDL's).

Om te zorgen dat berichten naar de juiste deelnemer gaan, dient de netbeheerder in het Opdrachtbericht het veld Opdrachtnemer van de juiste aannemer te voorzien. Als de aannemer dan het Opdrachtbericht heeft ontvangen, is de koppeling tussen netbeheerder en aannemer gemaakt en zullen verder berichten worden uitgewisseld op basis van het Opdracht-ID.

SOAP Faults dienen door deelnemers alleen gebruikt te worden bij technische, oplosbare problemen. Het DSP zorgt ervoor dat berichten aan de afgesproken algemene technische en functionele afspraken voldoen. Denk hierbij aan validatie ten opzichte van de XSD's en functionele validaties van het AGAssets bericht.

Indien een bericht niet voldoet aan specifieke afspraken tussen een netbeheerder en aannemer zal de ontvanger toch altijd een "OK"-response als antwoord naar het DSP moeten sturen. Vervolgens kan de ontvanger een Bijstelling of Beoordeling bericht sturen om het niet voldoen aan de specifieke afspraken terug te koppelen. Indien deelnemers zich hier niet aan houden kan het proces vastlopen, omdat het DSP een bericht nooit succesvol afgeleverd zal krijgen.

Het DSP hanteert een timeout van 5 minuten en zal een bericht na 5 minuten beschouwen als niet afgeleverd en een foutafhandelingsproces starten om aan de Aflevergarantie DSP te voldoen.

De maximale grootte van een bericht inclusief eventuele bijlagen is 50000 kB

Outbound IP adres DSP

Mocht de deelnemer inbound whitelisting op basis van IP-adressen willen toepassen dan dient het volgende IP-adres gewhitelist te zijn om DSP berichten te kunnen ontvangen: 204.79.147.97.
Dit IP-adres geldt zowel voor alle omgevingen.