[IT-dienstenleveranciers] extra technisch overleg 3/3/2020 : wijzigingen zoekgebeurtenis & aanpassingen datablok diensten.

Wo Feb 26 13:50:05 CET 2020

Wanneer : dinsdag 3 maart, 10.30 uur tot 12 uur

 Join Skype Meeting<https://join.ucrtc.dxc.com/meet/benny.de-buck/QQ3DDS8F>

Trouble Joining? Try Skype Web App<https://join.ucrtc.dxc.com/meet/benny.de-buck/QQ3DDS8F?sl=1>

Join by phone

+32-26-200-829 (Belgium, Brussels),,5584688619# (Belgium Attendees)                          Engels (Verenigde Staten)

0800-58-253 (Customers/Partners in Belgium),,5584688619# (Belgium Attendees)                       Engels (Verenigde Staten)

Find a local number<https://join.ucrtc.dxc.com/dialin?id=5584688619>

Conference ID: 5584688619

Forgot your dial-in PIN?<https://join.ucrtc.dxc.com/dialin> |Help<https://o15.officeredir.microsoft.com/r/rlidLync15?clid=1033&p1=5&p2=2009>

Skype-call, voor de mensen in BXL is zaal 1.G.65 gereserveerd.

Beste afnemers,

Zoals op het technisch overleg besproken willen we de aanpassingen aan de zoekGebeurtenis dienst (primaire & secundaire bestemmeling) met jullie bespreken.

in de huidige webservices niet mogelijk is om aan te geven of een bestemmeling primair is of niet.

We zien ons daarom genoodzaakt om een geefGebeurtenis V2 webservice te maken. Die zal dan een gebeurtenis V2 teruggeven i.p.v. een V1. Er zijn 2 verschillen tussen een Gebeurtenis V2 & Gebeurtenis V1:

  *   Gebeurtenis V2 heeft bij de bestemmelingen de mogelijkheid om aan te geven of de bestemmeling primair of niet is.
  *   De bronactor is nu verplicht. In V1 was die in het schema optioneel, maar werd een fout gegooid als die leeg was. Nu is dat niet meer mogelijk.

Daarnaast zullen we ook startGebeurtenis V3 aanpassen zodat er een gebeurtenis V2 moet meegegeven worden i.p.v. een V1. Die webservice is met release 2.70 in oefen gezet, maar we zullen de XSD's dus moeten wijzigen.

Tot slot is er dan ook nog zoekGebeurtenis V3. We zullen daarin de mogelijkheid voorzien om te filteren op gebeurtenissen waarin je primaire bestemmeling bent.

Met de aanpassing van primaire en secundaire bestemmeling valt volgens ons ook de noodzaak weg om te filteren op gebeurtenissen die je nog niet opgehaald hebt en mag de filter 'alle' dus weg uit zoekGebeurtenis V3.

Vandaar ook ons voorstel om in zoekGebeurtenis V3 de filter 'alle' weg te halen en filteren met behulp van een interval verplicht te maken.

Als we zoekGebeurtenis V3 met release 2.72 naar oefen willen brengen hebben we wel ten laatste volgende week vrijdag avond antwoord nodig of dit goed is. Dan kunnen we het in de laatste week van release 2.72 nog uitwerken.

In bijlage kan je ter voorbereiding van dit overleg als een aangepaste xsd vinden.

Daarnaast zijn we ook al een tijdje aan het kijken naar een generiek alternatief voor onze datablok diensten zodat die ‘flexibeler’ met nieuwe versies van datablokken of nieuwe datablokken zouden omkunnen.

Hierbij hebben we 3 alternatieven uitgewerkt, allen met hun voor en nadelen, die we met jullie willen toetsen :

1.       Key-Value:

     *   Voordelen:

        *   Het overzicht van de velden in een datablok is duidelijk leesbaar.
        *    xsd is eenvoudiger ten opzichte van het bestaande systeem.
        *   2 diensten voor het bewaren en ophalen van datablokken
        *   nieuwe datablokken hebben geen impact op de webservices
     *   Nadelen:

        *   We moeten een volledig nieuw systeem opzetten om de key-value pairs uit de xsd te halen en te kunnen valideren ten opzichte van de xsd van het datablok.
Deze validatie zal ook moeten gebeuren door de afnemers om een correcte xsd te kunnen doorsturen naar het uitwisselingsplatform. Het uitwerken van dit nieuwe systeem is veel werk, zowel voor de afnemers als voor ons ontwikkel team.
        *   Dit heeft geen meerwaarde ten opzichte van de base64 encoded oplossing, buiten dat het leesbaarder is.
        *   Doordat we de mapping van key-value pair naar xsd zelf moeten schrijven, kan dit fouten bevatten.

2.       Base 64 encoded string (CDATA):

Het datablok gaan we wrappen in een base 64 encoded string. De bewaarDatablok en geefDatablok gaan dus een string versturen en ontvangen.
De backend gaat deze string achterliggend decoderen naar het datablok, die we dan kunnen valideren tegenover de bestaande datablok xsd's.

     *   Voordelen:

        *   Is makkelijk te implementeren
        *   de validatie kan achterliggend gebruik maken van de validatie die we reeds hebben, zonder een nieuw systeem te implementeren
        *   2 diensten voor het bewaren en ophalen van datablokken
        *   deze werkwijze wordt ook gebruikt door DTP.
        *   weinig werk
        *   nieuwe datablokken hebben geen impact op de webservices
        *   xsd is eenvoudiger ten opzichte van het bestaande systeem

     *   Nadelen:

        *   verzoek/repliek zijn minder leesbaar dan key-value.

3.       Microservices:

Voor elk datablok zouden we een aparte webservice maken.

     *   Voordelen:

        *   Webservices zijn zeer klein, het toevoegen van een nieuw datablok en dus ook een nieuwe webservice is minder werk dan nu het geval is.
        *   Webservices zijn compleet onafhankelijk van elkaar

     *   Nadelen:

        *   De eerste opzet is veel werk voor ontwikkelteam en afnemers (+600 nieuwe webservices)
        *   Is het nog overzichtelijk hoeveel webservices er gaan zijn.
        *   Voor elk nieuw databalok moet er door ons en de afnemers, 2 nieuwe webservices geïmplementeerd worden.

Momenteel gaat onze voorkeur naar de base64-encoded string, deze bevat, volgens ons, het minste werk en de minste kans op fouten.

Met vriendelijke groeten

Team Omgevingsloket

DEPARTEMENT OMGEVING

https://www.omgevingsloket.be/main <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.omgevingsloket.be%2Fmain&data=02%7C01%7Cpieter.lamote%40vlaanderen.be%7C529fa5a478a64b35a7b208d6cf97652b%7C0c0338a695614ee8b8d64e89cbd520a0%7C0%7C0%7C636924646482720816&sdata=pb3lvMMuvmb8Fh9zlkU2aeQqE47P4YSHiqfnqJOIcXo%3D&reserved=0>

------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <http://list.milieuinfo.be/pipermail/oml_it/attachments/20200226/5687034e/attachment-0001.html>
------------- volgend deel ------------
Een niet-tekst bijlage is gescrubt...
Naam: niet beschikbaar
Type: text/calendar
Grootte: 8641 bytes
Omschrijving: niet beschikbaar
URL : <http://list.milieuinfo.be/pipermail/oml_it/attachments/20200226/5687034e/attachment-0001.ics>
------------- volgend deel ------------
Een niet-tekst bijlage is gescrubt...
Naam: BewaarDatablokV3-Base64-Repliek.xml
Type: text/xml
Grootte: 2720 bytes
Omschrijving: BewaarDatablokV3-Base64-Repliek.xml
URL : <http://list.milieuinfo.be/pipermail/oml_it/attachments/20200226/5687034e/attachment-0004.xml>
------------- volgend deel ------------
Een niet-tekst bijlage is gescrubt...
Naam: BewaarDatablokV3-Base64-Verzoek.xml
Type: text/xml
Grootte: 1816 bytes
Omschrijving: BewaarDatablokV3-Base64-Verzoek.xml
URL : <http://list.milieuinfo.be/pipermail/oml_it/attachments/20200226/5687034e/attachment-0005.xml>
------------- volgend deel ------------
Een niet-tekst bijlage is gescrubt...
Naam: GebeurtenisV2.xsd
Type: text/xml
Grootte: 6899 bytes
Omschrijving: GebeurtenisV2.xsd
URL : <http://list.milieuinfo.be/pipermail/oml_it/attachments/20200226/5687034e/attachment-0006.xml>
------------- volgend deel ------------
Een niet-tekst bijlage is gescrubt...
Naam: ZoekGebeurtenisVerzoek.xsd
Type: text/xml
Grootte: 5354 bytes
Omschrijving: ZoekGebeurtenisVerzoek.xsd
URL : <http://list.milieuinfo.be/pipermail/oml_it/attachments/20200226/5687034e/attachment-0007.xml>