Landelijke Voorziening - laatste 4 releases

De geometrievalidatie gaf ten onrechte een fout BGT-I-0-113 (afstand binnenring-buitenring kleiner dan 0.5 mm) op een vervallen object. Deze fout is hersteld.

In het kader van IMGEO 2.2 wordt conform het wijzigingsvoorstel IMGEO 2.2 de controle op plaatsbepalingspunten (PBP) uitgezet. Dit betekent dat in deze release de controle op PBP’s bij een aanlevering aan de registratieservice of bij de controles van de controleservice vervalt.

Dit heeft de volgende gevolgen:

  • BGT-objecten kunnen aangeleverd worden zonder PBP, aanleveringen worden hier niet meer op gecontroleerd.

  • In de controleservice is de optie om al dan niet de PBP’s te controleren verwijderd.

Later dit jaar of begin volgend jaar zal bij aanlevering van mutatiebestanden een filter worden ingebouwd op PBP’s. Dit filter laat alleen PBP’s door die liggen op goed idealiseerbare objecten waarbij een beperkt aantal typen inwinningsmethoden zijn toegestaan. Zie ook het wijzigingsvoorstel IMGEO 2.2.

Deze release bevat een wijziging van de geometrische controle van polygonen.

Verschil met vorige versie

Geometrische controle bij polygonen met binnenringen aangepast

De geometrische controle keurde objecten goed waarvan de binnenring op de buitenring ligt zonder dat er een tussenpunt op de buitenring aanwezig is. Deze controle is zodanig aangepast dat een object afgekeurd wordt als de afstand van de binnenring tot de buitenring kleiner is dan 0.5 millimeter. De binnenring mag de buitenring raken op 1punt waarbij er een punt op de buitenring aanwezig moet zijn.

Bij foutsituaties kunnen de volgende fouten gemeld worden in het verwerkingsverslag:
- BGT-I-01-113
Objectaanlevering met id 123 van type BegroeidTerreindeel is niet valide, ring ligt niet op binnen- of buitenring maar bevat bijna rakende ringen met een tolerantie van 0.5 mm bij coördinaat (123456,455123) Zie te downloaden gml-bestand.
- BGT-I-01-114
Objectaanlevering met id 123 van type BegroeidTerreindeel is niet valide, ring ligt niet op binnen- of buitenring maar bevat bijna rakende ringen met een tolerantie van 0.5 mm bij boog/lijn ((123456,455123), (123457,455124)) Zie te downloaden gml-bestand.

Beide wijzigingen zijn gedaan in het kader van wijzigingsvoorstel IMGEO 2.2. Lees het wijzigingsvoorstel op Geostandaarden.nl

Verschil met vorige versie:

• Controle op OngeclassificeerdObject

In het kader van het wijzigingsvoorstel IMGEO 2.2 vervalt het BGT-object OngeclassificeerdObject (OCO). Er is een controle ingebouwd die het aanleveren van nieuwe OCO’s afkeurt. Wanneer er een aanlevering aangeboden wordt met een nieuwe OCO volgt er een foutmelding “BGT-I-01-110” in het verwerkingsverslag en krijgt de aanlevering de status Fout. Het laten vervallen en muteren van een OCO is nog wel toegestaan.

• Controle op OverigeScheiding

In het kader van het wijzigingsvoorstel IMGEO 2.2 vervalt het BGT-object OverigeScheiding. Er is een controle ingebouwd die het aanleveren van nieuwe OverigeScheidingen afkeurt. Wanneer er een aanlevering aangeboden wordt met een nieuwe OverigeScheiding volgt er een foutmelding “BGT-I-01-110” in het verwerkingsverslag en krijgt de aanlevering de status Fout. Het laten vervallen en muteren van een OverigeScheiding is nog wel toegestaan.

BRAVO

De release 22.1.0 voor BRAVO is op 12 april 2022 beschikbaar gesteld

Verschil met vorige versie

  • Filtering op redundantie van plaatsbepalingspunten

Bij de introductie van de filtering op redundante Plaatsbepalingspunten (PBP’s) op 27 december 2021 werden leveringen in sommige gevallen onterecht afgekeurd omdat er een technische fout optrad. Daarom besloten we om deze filtering tijdelijk uit te zetten. Dit is inmiddels hersteld en met ingang van deze release worden aangeleverde PBP’s weer gefilterd volgens de richtlijnen die daarvoor zijn opgesteld in het kader van IMGEO 2.2.

De release 21.3.2 voor BRAVO is op 27 december 2021 beschikbaar gesteld. Dit is een functionele release met:

  • filtering op redundantie van plaatsbepalingspunten (IMGEO 2.2)
  • verbeterde functionaliteit voor marktpartijen die met machtigingen werken
  • oplossingen voor enkele incidenten

Verschil met vorige versie

• Filtering op redundantie van plaatsbepalingspunten

Met ingang van deze release zullen aangeleverde Plaatsbepalingspunten (PBP’s) worden gefilterd conform de richtlijnen die daarvoor zijn opgesteld in het kader van IMGEO 2.2 Deze filtering vindt als volgt plaats:
Wanneer een mutatielevering aan BRAVO wordt aangeboden worden uit deze aanlevering alleen de plaatsbepalingspunten (PBP’s) waarop het onderstaande van toepassing is geregistreerd in BRAVO en in de LV-BGT en daaropvolgend teruggeleverd via actualiseringsberichten.

  • Inwinningsmethode is terrestrisch, laser, fotogrammetrisch of panoramabeelden
  • Het PBP behoort toe aan een goed idealiseerbaar object dat aanwezig is binnen de aanlevering.

Opsomming met goed-idealiseerbare objecten

  • Wegdeel
  • Ondersteunend wegdeel
  • Spoor
  • Pand
  • Overigbouwwerk met uitzondering van bassin, schuur, bunker, voedersilo
  • Scheiding met uitzondering van walbescherming, hek, draadraster, faunaraster
  • Kunstwerkdeel
  • Overbruggingsdeel
  • Tunneldeel
  • Gebouwinstallatie
  • Inrichtingselementen: bak, bord, installatie, kast mast, paal, put, sensor, straatmeubilair, waterinrichtingselement, weginrichtingselement

Dit impliceert ook het volgende:

  1. Alle PBP’s die niet aan bovenstaande voorwaarden voldoen zullen niet worden geregistreerd en dus ook niet via de abonnementenservice worden teruggeleverd.
  2. Bij het bestellen van een nulstand of het aanmaken van een aanvullende nulstand na gebiedsuitbreiding van een abonnement zullen er geen PBP’s worden opgenomen in het nulbestand die niet aan bovenstaande criteria voldoen.
  3. Aanleveringen die uitsluitend PBP’s bevatten niet zullen worden geaccepteerd omdat deze na filtering in een ‘lege’ aanlevering zouden resulteren hetgeen niet toegestaan is. In dat geval zal de levering tijdens de validatie door BRAVO worden afgekeurd. De aanbieder ontvangt hiervan bericht via het portaal en indien van toepassing via het automatisch berichtenverkeer.

• Voorkomen dat automatisch berichtenverkeer vastloopt door numeric overflow

Af en toe liep het automatisch berichtenverkeer vast. Dit bleek te worden veroorzaakt door een globale variabele in het databaseschema. Doordat de webservices hun sessie altijd in de lucht houden, blijft deze variabele maar ophogen. Op enig moment bereikt de variabele de maximale waarde en kan dan niet meer opgehoogd worden. Vanaf nu zullen de webservices iedere dag herstart worden waardoor deze variabele automatisch gerest wordt.

• Marktpartij heeft geen inzage meer in abonnementen van andere marktpartijen

Een medewerker van een marktpartij (MP) kon ook de abonnementen benaderen die door andere marktpartijen waren besteld die door dezelfde bronhouder waren gemachtigd. Dit is nu als volgt gewijzigd: een medewerker van een marktpartij heeft read-only toegang tot de abonnementen van een bronhouder die deze marktpartij gemachtigd heeft plus de abonnementen van die marktpartij zelf (CRUD).

• Fout in MD5 checksum bij abonnementsberichten opgelost

In uitzonderlijke gevallen (bestandsgrootte = (x * 32767) + 1 ) werd er bij het genereren van een abonnements-bestand 1 bit te weinig naar de fileserver geschreven. Dit leverde een verschil op met de MD5-checksum die in het ophaalverzoek (opvdi01) vermeld staat. Controles in de ontvangende BGT software signaleerden daardoor een foutsituatie. Het probleem is opgelost doordat in dit soort gevallen nu ook het laatste bit wordt weggeschreven naar de fileserver.

• Parallelle validatie van aanleveringen door marktpartij namens verschillende bronhouders

Wanneer een aanlevering van een door meerdere bronhouders gemachtigde dataleverancier in validatie was, werd een aanlevering die door diezelfde dataleverancier namens een andere machtigende bronhouder was gedaan niet gedownload en dus ook niet in validatie genomen zolang die eerdere levering in validatie was. Dit is nu aangepast zodat een nieuwe aanlevering die door een marktpartij namens bronhouder Y wordt gedaan wel zal worden opgehaald en in verwerking genomen terwijl een aanlevering die door dezelfde marktpartij namens bronhouder X is gedaan nog in validatie is.

• Parallelle afhandeling van abonnementssignalen als aanbieder meerdere kanalen heeft

De werking van BRAVO was zodanig dat wanneer een aanbieder meerdere kanalen heeft die aan verschillende abonnementen gekoppeld zijn er, zodra in 1 van die kanalen de verwerking vastloopt, ook geen berichten meer over de andere kanalen werden verzonden. Dit is als volgt opgelost: Een aanbieder heeft kanalen X en Y die gekoppeld zijn aan abonnementen A respectievelijk B van dezelfde aanbieder. Als het berichtenverkeer in kanaal X (abonnement A) door een storing is vastgelopen, zal het berichtenberkeer over kanaal Y (abonnement B) gewoon door blijven lopen. Dit principe geldt ook als er sprake is van meer dan 2 verschillende kanalen.

• Medewerker marktpartij heeft geen inzage meer in de signalen van andere aanbieders

Een medewerker van een marktpartij kon in het scherm ‘Berichtenverkeer’ behalve zijn eigen signalen ook die van alle andere aanbieders zien. Vanaf nu kan een medewerker van een marktpartij in het scherm ‘Berichtenverkeer’ alleen de signalen zien waarvan die marktpartij zelf de aanbieder is (dus de signalen die over de eigen kanalen van die marktpartij lopen).

• Aanpassing in het opvoeren van een nieuwe organisatie (beheerdersfunctionaliteit)

Oude situatie: Bij het opvoeren van een nieuwe organisatie stond de radio button ‘werkt via Machtigingenmodule’ standaard op ‘Nee’ ipv ‘Ja’. Deze waarde kon niet gewijzigd worden.
Nieuwe situatie: Bij het opvoeren van een nieuwe organisatie staat de radio button ‘werkt via Machtigingenmodule’ standaard op ‘Ja’. Deze waarde kan indien gewenst gewijzigd worden.

• Onterechte browsermelding weggenomen

Wanneer in het detailscherm van een abonnement in de tab ‘Bestanden’ op het ‘details’-linkje van een abonnementsbestand werd geklikt, reageerden alle webbrowsers met een melding dat ‘de pagina niet verlaten kan worden, omdat er niet-opgeslagen wijzigingen zouden zijn’. Nu opent het scherm met de bestandsdetails zonder deze onterechte melding.

• Juiste bronhouder vermeld in notificatiemail rakende vooraankondiging

Wanneer een bronhouder geraakt wordt door een vooraankondiging gaat er ook een notificatiemail naar de marktpartijen die door deze rakende bronhouder gemachtigd zijn. In deze mail stond als machtigende bronhouder per abuis de initiërende bronhouder vermeld in plaats van de rakende bronhouder. Dit is nu verbeterd, zodat de mail aan de marktpartij de rakende bronhouder als machtigende bronhouder vermeldt.

• Marktpartij kan zijn kanaal niet meer koppelen aan abonnementen van andere marktpartijen

Marktpartijen bleken hun berichtenkanalen ook te kunnen koppelen aan abonnementen van andere aanbiedende organisaties, waardoor ze die abonnementen over hun eigen kanalen zouden kunnen afnemen. Deze mogelijkheid is nu ongedaan gemaakt, waardoor marktpartijen hun berichtenkanalen uitsluitend kunnen koppelen aan abonnementen die zij zelf hebben besteld.

• Bij downloadproblemen wordt het nieuwe in plaats van het oude berichtenkanaal uitgezet

Sinds de introductie van de Machtigingenmodule zijn de stuurgegevens van de berichtenkanalen veranderd, zodat behalve bronhouders ook marktpartijen hun eigen berichtenkanalen kunnen hebben. De berichtenkanalen ‘oude stijl’ zijn ongedaan gemaakt maar nog wel voorhanden. Wanneer er een time-out optreedt tijdens het downloaden van een door de bronhouder klaargezet bestand hoort BRAVO na verloop van tijd het betreffende berichtenkanaal uit te zetten. Ook wordt er dan een notificatiemail gestuurd. BRAVO bleek in zo’n geval echter niet het nieuwe kanaal maar het ‘oude’ kanaal uit te zetten. Het gevolg was dat de retry-procedure op het nieuwe kanaal ‘eindeloos’ bleef doorgaan (dat was immers niet uitgezet) zodat de bronhouder van dit kanaal elke minuut een nieuwe notificatie ontving. Dit probleem treedt nu niet meer op omdat het nieuwe kanaal wordt uitgezet en niet het ‘oude’.

• Geen email meer versturen naar bronhoudersorganisaties met een ‘unknown’ e-mailadres

Wanneer bij bronhouders-organisaties geen toepasselijk geldig organisatie-e-mailadres bekend is staat in plaats daarvan ‘unknown@bronhoudersnaam.nl’ in de beheertabel vermeld. Er is nu een aanpassing gedaan die voorkomt dat BRAVO in voorkomende gevallen toch notificatiemails naar dat e-mailadres probeert te sturen. Het is namelijk gebleken dat sommige firewalls die aan de domeinen van bronhouders zijn gekoppeld er moeite mee hebben als dit herhaaldelijk geprobeerd wordt.

• Buurtwijkrelatie werd ten onrechte aangepast bij mutatie van Buurt-object

Bij het muteren van een BUURT-object werd ten onrechte tijdens de XML-transformatie de ligtIn-info in het WORDT-gedeelte veranderd. Dit probleem, dat veroorzaakt werd door een niet goed geïnitialiseerde variabele in de code, is nu verholpen zodat er geen onterechte wijzigingen in het WORDT-gedeelte worden aangebracht.

• Toelichting uit VAVDi01 werd niet overgenomen in de details van een automatische vooraankondiging

Bij een vooraankondiging die via het ABV werd gedaan werd de inhoud van de <toelichting>-tag in de vavDi01 niet overgenomen in het veld ‘Opmerkingen’ van het detailscherm van de vooraankondiging. Dit is nu opgelost, zodat de <toelichting> wordt overgenomen in de ‘Opmerkingen’ van de vooraankondiging.

De release 21.2.4 voor BRAVO is vandaag (5 oktober 2021) beschikbaar gesteld.  

Verschil met vorige versie

Release BRAVO 21.2.4 is een herstelrelease van de vorige versie (21.2.3):

  • Verbeterde URL voor BRT achtergrondkaart

De BRT achtergrondkaart wordt getoond bij de weergave van abonnements- en vooraankondigingsgebieden.
In release 21.2.3 is per abuis een verkeerde url meegegeven voor de BRT achtergrondkaart. In release 21.2.4 is de correcte url https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0?request=getcapabilities&service=wmts opgenomen.

De release 21.2.3 voor BRAVO is op 30 september 2021 beschikbaar gesteld. 

Verschil met vorige versie

Release BRAVO 21.2.3 bevat het volgende verschil ten opzichte van de vorige versie (21.2.2):

• Nieuwe URL voor BRT achtergrondkaart

De oude URL van de BRT achtergrondkaart komt per 28 oktober te vervallen. De nieuwe URL is: https://service.pdok.nl/brt/achtergrondkaart/wmts/v2_0?request=getcapabilities&service=wmts
De BRT achtergrondkaart wordt getoond bij de weergave van abonnements- en vooraankondigingsgebieden.

De release 21.2.2 voor BRAVO is vandaag (26 juli 2021) beschikbaar gesteld. Deze release (waarin ook release 21.1.1 is opgenomen) is een herstel-release die oplossingen bevat voor restpunten uit release 21.2.0 (‘Bravo Portaal Upgrade’). 

Verschil met vorige versie

Release BRAVO 21.2.2 bevat het volgende verschil ten opzichte van de vorige versie (21.2.0):

  • Wachtwoordgenerator aangepast

Bij het automatisch genereren van nieuwe wachtwoorden werden soms wachtwoorden gegenereerd met daarin een ">" of "<" teken. Dit teken werd in de html-opmaak van de emails waarmee het nieuwe wachtwoord naar de gebruiker van het betreffende account werd gestuurd automatisch vervangen door ‘&gt’ of ‘&lt’. Wanneer de gebruiker dit uit de email overnam werkte het nieuwe wachtwoord niet. Daarom is de wachtwoordgenerator zodanig aangepast dat deze geen wachtwoorden meer genereert met daarin een ">" of "<".

  • Schermnavigatie ‘Beheer parameters’ verbeterd

Bij het verlaten van het scherm ‘Beheer parameters’ (alleen beschikbaar voor de applicatiebeheerder) kwam men terug in het verkeerde keuzemenu. Dat is nu gecorrigeerd.

  • Default leveringstatus ‘Compleet’ ontbrak

Na het handmatig opvoeren van een mutatielevering via het BRAVO-portaal krijgt de mutatielevering de status ‘Opgevoerd’. Van hier uit kan men vanuit een keuzelijst de status ‘Compleet’ kiezen waarna de mutatielevering in validatie wordt genomen. Gebruikers waren gewend dat deze keuzelijst na het opvoeren van een levering per default de status ‘Compleet’ laat zien zodat men alleen maar op ‘Opslaan’ hoefde te drukken om de levering op ‘Compleet’ te zetten. Het bleek dat deze defaultstatus na de vorige release (21.2.0) niet meer getoond werd, zodat men bij het ‘Opslaan’ per ongeluk een ‘lege’ status koos zodat de mutatielevering niet in validatie werd genomen. Dat is nu gecorrigeerd door na het opvoeren van een levering als vervolgstatus weer de defaultwaarde ‘Compleet’ in de keuzelijst te tonen.

  • Opgeslagen rapportage filters bleven niet beschikbaar in een volgende sessie

Het BRAVO portaal biedt de mogelijkheid om zelfgekozen filterinstellingen per scherm op te slaan (via Acties/Rapport Opslaan) voor toekomstig gebruik. Sinds release 21.2.0 bleek dat na uitloggen en weer inloggen met hetzelfde account de eerder opgeslagen filterinstellingen verdwenen waren. Dat is nu opgelost zodat de gebruiker na opnieuw inloggen de in een eerdere sessie opgeslagen filters kan hergebruiken.

  • Niet langer benodigde package uit de applicatiecode verwijderd

Een niet langer benodigde package (APEX P_Debug) is overal uit de code verwijderd. De gebruiker zal hier niets van merken.

  • Autorisatie-issues voor de rol ‘Helpdesk Raadpleger’ opgelost

Wanneer een gebruiker was ingelogd met de rol ‘Helpdesk Raadpleger’ was er sprake van enkele autorisatie issues. De raadpleger kreeg daardoor ten onrechte toegang tot knoppen waarmee wijzigingen konden worden aangebracht. Deze knoppen zijn nu verwijderd voor de betreffende rol. Het betreft:

  1. De knop ‘Nieuw kanaal’ is uit het detailscherm ‘Kanaal’ (836) verwijderd
  2. De knop ‘Nieuwe marktpartij’ is uit het detailscherm ‘Marktpartij’ (160) verwijderd
  3. De knop ‘Opslaan’ is uit het detailscherm ‘organisatie’ (838) verwijderd
  • Knop ‘Definitief fout’ werkte niet

Wanneer een signaal in het automatisch berichtenverkeer niet kan worden uitgevoerd (‘signaal mislukt’) of in een retry-modus komt (‘signaal opnieuw verzenden’) kan de beheerder ingrijpen door dit signaal af te breken. De knop ‘Definitief fout’ waarmee dit gedaan kan worden werkte sinds release 21.2.0 niet meer. Dit probleem is nu opgelost.

De nummers tussen []’s duiden het ticketnummer in de Transfer Solutions servicedesk aan.

Monitor op downloadservice [2704]

De laatste maanden is het regelmatig voorgekomen dat de BRAVO-downloadservice bleef hangen. Dit werd niet tijdig geconstateerd omdat hierop niet automatisch gemonitord werd. Daardoor konden de wachtrijen flink oplopen voordat dit geconstateerd werd. Er is nu een check ingebouwd die iedere 5 minuten controleert of een bepaalde download langer dan 5 minuten draait (deze termijn is in te stellen via een beheerparameter). In dat geval wordt een alertering gestuurd naar applicatiebeheer.

Monitor op verwerkingsduur [2701]

Er is een check ingebouwd die om het hele uur wordt uitgevoerd en controleert of er een verwerkingsjob is (voor mutatieleveringen) die langer draait dan een bepaald aantal minuten, in te stellen via een beheerparameter (default ingesteld op 60 minuten). In dat geval wordt een alertering gestuurd naar applicatiebeheer.

Performanceverbetering bij opvragen van logginggegevens [2700/2699]

De SVB-BGT beheerder kan bepaalde logging gegevens opvragen via het Bravo portaal. De performance van deze query is verbeterd door de indexering aan te passen en oude records uit de loggingtabel op te schonen.

Aanbieder van abonnement valt weg als de einddatum gewijzigd wordt [2697]

Wanneer een gebruiker de einddatum van een abonnement aanpaste en deze wijziging opsloeg dan werd de kolom ‘Aanbieder’ ten onrechte leeggemaakt. Hierdoor bevatten de abonnementssignalen ook geen gegevens van de Aanbieder meer waardoor medewerkers van marktpartijen deze signalen niet meer in het portaal konden zien. Dit probleem is nu opgelost.

Ophaalverzoeken waarin de aanbiedende bronhouder een andere was dan de verantwoordelijke bronhouder werden ten onrechte geaccepteerd [2696]

Een ophaalverzoek (opvDi01 bericht) met een bronhoudercode in de <Organisatie> tab van de stuurgegevens en een andere bronhoudercode in de berichtidentificatie werd toch geaccepteerd. Het gevolg was een levering met een andere bronhouder als ‘Aanbieder’ dan de verantwoordelijke bronhouder. Dit is niet toegestaan want bronhouders kunnen elkaar niet machtigen. In het vervolg zal zo’n ophaalverzoek worden afgekeurd via een FO03 bericht met de vermelding “Zendende organisatie heeft geen geldige machtiging voor aangegeven bronhouder”.

Fout in de controle of een bericht al eerder verstuurd is [2695]

Wanneer BRAVO van dezelfde zender (zendende organisatie) een ophaalverzoek ontvangt met hetzelfde berichtreferentienummer als een eerder ontvangen ophaalverzoek dat al afgehandeld is moet het nieuwe ophaalverzoek niet meer in behandeling worden genomen. In plaats daarvan moet alleen hetzelfde response-bericht (Bv03 of FO03) dat bij het eerdere ophaalverzoek was verzonden opnieuw verzonden worden. De fout was dat BRAVO bij het zoeken naar een bericht met hetzelfde referentienummer eventueel later binnengekomen signalen van dezelfde zender raadpleegde. Deze waren nog niet afgehandeld en hierdoor werd ten onrechte een Fo03-bericht terug gestuurd. De query is aangepast waardoor Bravo nu alleen naar eerder binnengekomen berichten kijkt.

Eerder verzonden response wordt niet opnieuw verstuurd [2694]

Dit scenario kwam voor wanneer een aanbieder een identiek ophaalverzoek (opvDi01) nogmaals naar BRAVO verstuurde. BRAVO moet dan hetzelfde response-bericht (Bv03 of Fo03) als bij het vorige (identieke) bericht terug sturen. Maar wanneer om de een of andere reden dit vorige response-bericht niet in de database kon worden teruggevonden zou BRAVO een Fo03-bericht moeten versturen. Dit bericht werd echter nooit verstuurd. Deze fout is hersteld waardoor BRAVO voortaan in het voorkomende geval een Fo03-bericht zal verzenden met de tekst “Referentienummer is al eerder door zender gebruikt, maar eerder gegeven response kon niet teruggevonden worden.”

Signalen preview scherm toont signalen niet in de juiste volgorde [2692]

In het scherm dat geopend wordt wanneer men in de detailgegevens van een berichtenkanaal op de knop ‘Signalen preview’ drukt werden de signalen in een willekeurige volgorde getoond. Nu worden ze in volgorde van tijdstip getoond (meest recente eerst).

Diverse issues met zelftest door Beheerder SVB-BGT opgelost [2691]

Er gingen diverse dingen niet goed als de beheerder SVB-BGT een zelftest wilde doen namens een marktpartij:

  • De selectlist voor de marktpartij van het te testen kanaal toonde alleen ‘-1’.
  • Soms toonde de select list niet een -1 maar een bronhouder: dat was de laatst gekozen bronhouder in de schermen voor automatisch berichtenverkeer.
  • De select list met het kanaal toonde niet de naam maar het ID van het kanaal.
  • Het overzicht met signalen bleef altijd leeg voor de beheerder SVB-BGT.

Deze problemen zijn nu opgelost door middel van een aangepaste werkwijze:

  1. Kies in het scherm "Kanalen" een kanaal van de betreffende aanbieder (marktpartij of bronhouder).
  2. Ga via de editknop naar de detailgegevens van het kanaal.
  3. Navigeer van daaruit via de knop "Zelftest" naar de zelftestpagina.
  4. De select list voor bronhouders is op de zelftestpagina vervolgens alleen zichtbaar als de aanbieder een bronhouder was, en niet een marktpartij.

Zelftest-berichten worden geweigerd als in de stuurgegevens van de envelop geen ‘zelftest’ wordt vermeld [2690]

Als gevolg van configuratie-issues aan de zijde van de bronhouder kon het gebeuren dat BRAVO via automatisch berichtenverkeer een ‘zelftest’ bericht ontving waarbij de stuurgegevens van de bericht-envelop ten onrechte geadresseerd waren aan S0001/BRAVO/SVB-BGT terwijl het bericht zelf correct geadresseerd was aan S0001/ZELFTEST/SVB-BGT. BRAVO handelde deze situatie niet goed af, waardoor er in plaats van het uitvoeren van een zelftest een levering werd aangemaakt die ter registratie werd aangeboden aan de LV-BGT. In het vervolg zal BRAVO in dit soort gevallen het ophaalverzoek niet in verwerking nemen maar via een FO03-response een foutcode StuF010 retourneren

Gemachtigde dataleverancier moet dezelfde notificaties krijgen als de bronhouder zelf [2684]

Wanneer er naar aanleiding van een mutatielevering of vooraankondiging een notificatiemail naar de initiërende en/of rakende bronhouder wordt gestuurd zal dezelfde e-mail in het vervolg ook naar de door deze bronhouder(s) gemachtigde dataleverancier(s) gestuurd worden. Deze dataleverancier(s) bleken wel een melding maar geen e-mail te krijgen. Dat is nu dus wel het geval.

Alertering bij verlopen of intrekken van machtiging [2671]

Marktpartijen kunnen op basis van een machtiging abonnementen bestellen. Wanneer die machtiging verloopt of ingetrokken wordt zullen de abonnementen die op grond van deze machtiging besteld zijn door een dagelijkse batchjob automatisch worden beëindigd. Het beëindigen van abonnementen heeft wel impact. Daarom vindt er in het vervolg een alertering plaats. Wanneer een machtiging de einddatum nadert zullen er enkele dagen van tevoren (instelbaar door de beheerder, standaard op 14, 7 en 1 dag van tevoren alsmede op de vervaldag zelf) alerteringsmails naar de bronhouder én naar de door deze bronhouder gemachtigde dataleverancier(s) gestuurd worden om deze daarop te wijzen. Hiervoor wordt het e-mailadres van de Organisatie gebruikt.
Wanneer de bronhouder een machtiging intrekt wordt er eerst om een bevestiging gevraagd. Op het moment dat de machtiging daadwerkelijk ingetrokken wordt, wordt er een e-mail verstuurd naar de dataleverancier op wie de machtiging betrekking had.

Helpdesk Raadpleger moet ook abonnementsgebied kunnen bekijken [2637]

Er is nu een knop "Gebied bekijken" voor gebruikers met het profiel HELPDESK_RAADPLEGER. Daarmee kan het abonnementsgebied worden bekeken maar niet gewijzigd.

Onterechte WAS-WAS fout bij OPR-objecten [2702]

Bij het verwerken van OPR-objecten traden in sommige gevallen onterechte foutmeldingen op. In de gevallen waarbij dit optrad had het WAS object geen koppeling met een ORL (openbare ruimte label). De code die de oorzaak was van deze onterechte afkeuring is nu verbeterd

De nummers tussen []’s duiden het ticketnummer in de Transfer Solutions servicedesk aan.

Machtigingenmodule

  • Wanneer een vooraankondiging raakt aan de objecten van een bepaalde bronhouder, ontvangt deze bronhouder een melding in Bravo (Meldingenscherm). Er is nu een wijziging aangebracht waardoor ook de marktpartijen die een lopende machtiging van de betreffende bronhouder hebben een melding in Bravo krijgen wanneer een vooraankondiging deze bronhouder raakt. Medewerkers van de marktpartij kunnen deze melding dan voor ‘gezien’ afvinken in het Meldingenscherm. [2661]
  • Het uitvoeren van een zelftest wordt verplicht gesteld voordat men in een kanaal het attribuut ‘Automatisch berichtenverkeer’ op ‘Aan’ kan zetten. [2666] Dit doet zich voor en wel in de volgende gevallen:
    • Er is een nieuw kanaal aangemaakt en met wil dit op ‘Aan’ zetten. Dat kan pas nadat er een zelftest is uitgevoerd (ongeacht het resultaat van die zelftest)
    • De stuurgegevens van een bestaand kanaal zijn gewijzigd en men wil deze wijzigingen opslaan. In dat geval wordt het kanaal automatisch op ‘Uit’ gezet en kan men het pas weer op ‘Aan’ zetten nadat er een zelftest op dit kanaal is gedaan (ongeacht het resultaat van die zelftest)
  • Als een gemachtigde marktpartij een opgevoerde levering wijzigde verdween het veld ‘Aanbieder’ uit het scherm. Dit probleem is nu opgelost. [2679]
  • De keuzelijst om bij het aanmaken van een nieuwe machtiging een ‘Aanbieder’ te kiezen bevatte behalve de marktpartijen ook alle bronhouders. Nu worden alleen nog de marktpartijen getoond. [2675]
  • Een bronhouder zag in het scherm ‘Berichtenverkeer’ niet alleen zijn eigen signalen, maar ook de signalen van aanbiedende marktpartijen die door deze bronhouder gemachtigd waren. Dit leverde verwarring op en daarom is dit aangepast zodat een bronhouder alleen zijn eigen signalen (waarbij hij zelf de ‘aanbieder’ is) te zien krijgt. [2665]
  • Medewerkers van de helpdesk (KCC BGT) hebben read-only toegang gekregen tot de schermen van de machtigingenmodule (Machtigingen Overzicht, Organisaties overzicht, Marktpartijen overzicht, Rollen Scherm inclusie details en gebruikers per Organisatie). [2664]
  • Wanneer de stuurgegevens van een kanaal niet correct zijn ingevuld gaf de zelftest een onjuiste melding waarbij naar het niet meer bestaande oude ‘Stuurgegevens’ scherm werd verwezen. Deze foutmelding is aangepast naar ‘Vul bij het kanaal de juiste stuurgegevens in om een testbericht te kunnen sturen’. [2663]

Opvulproces

  • Er zijn voorbereidingen getroffen om de 4e ronde van het opvulproces uit te kunnen voeren:
    • Op tile-basis weergeven van de resultaten van opvulronde 4 [2676]
    • Meldingen die vanuit opvulronde 4 naar MMS gaan voorzien van de aanduiding ‘Melding uit Opvulronde 4’ [2676]
  • De resultaten van de offline gedraaide 3e opvulronde worden in een aparte tile-laag getoond [2657]

Overig

  • Een kennisgeving van een wijziging, waarbij het ORL van een OPR wordt verwijderd werd in een bepaalde situatie (levering 440260) niet overgenomen in het mtbLVBDi01-bericht en dus niet correct verwerkt in de LV-BGT en in de productiedatabase van BRAVO. Dit probleem is opgelost en ook is geverifieerd dat de LV-BGT en Bravo hierdoor niet uit sync zijn geraakt. [2665]

Bekende issues

  • Wanneer een vooraankondiging raakt aan de objecten van een bepaalde bronhouder, kan deze bronhouder een notificatie-email ontvangen. Er is een wijziging nodig waardoor ook de marktpartijen die een lopende machtiging van de betreffende bronhouder hebben een notificatie-email kunnen ontvangen.
  • Wanneer de machtiging van een bronhouder aan een marktpartij verloopt omdat de einddatum is bereikt zullen de abonnementen die de marktpartij op basis van deze machtiging hebben geactiveerd automatisch worden opgeheven. Om te voorkomen dat dit op een ongewenste wijze plaatsvindt moeten zowel de machtigende bronhouder als de gemachtigde marktpartij automatisch genotificeerd worden wanneer een machtiging op het punt staat te verlopen. De notificatietermijn moet instelbaar zijn.

Functionele wijzigingen

[2640] Uitbreiden van rapportages naar Cloud Database Tableau

Uitbreiding van de gegevens die automatisch ter beschikking worden gesteld aan de rapportagedatabase van Tableau.

[2501] Afstemmen van nulstand-aanvragen op het registreren van mutaties

Er worden alleen begonnen met het aanmaken van een nieuwe nulstand op het moment dat er geen registratie van een mutatielevering loopt of er een levering klaarstaat om geregistreerd (=opgeslagen in de ‘productiedatabase’) te worden. De abonnementen-jobs voor het aanmaken van nulstanden worden automatisch weer opgepakt zodra alle (klaarstaande) registraties van mutatieleveringen afgerond zijn. Hierdoor worden de nulstand-jobs naar een ‘rustiger’ moment verschoven zodat de kans op lange wachtrijen in de abonnementsverwerking afneemt. Deze functionaliteit kan met behulp van een databaseparameter ‘on the fly’ aan- of uitgezet worden.

Technische wijzigingen

[2642] Aanpassing in SDA_FILEHANDLER voor juiste directory/bestandsverwerking in de cloud-omgeving

Technische wijziging waardoor binnen een verwerkingsjob aan automatisch aangemaakte mappen de juiste rechten worden toegekend.

[2639] Niet duidelijk waaruit deze wijziging bestaat.

Aan Martijn gevraagd.

[2633] Aanpassingen gewenst in het scherm van bgt-debug-log 

Technische aanpassing ter verbetering van de debuglogging.

Opgeloste storingen

[2627] Bronhouders kunnen gebied van vooraankondiging niet zien

Bronhouders konden het gebied van een vooraankondiging niet meer zien, ook niet van hun eigen vooraankondiging. De knop 'Gebied tekenen/wijzigen' was niet (meer) beschikbaar. Oplossing: De knop is weer beschikbaar, maar biedt alleen de mogelijkheid om het gebied in de kaart te zien, niet om het achteraf te wijzigen.

[2607] Complete overlap wordt als rest-overlap gemeld

Wanneer een mutatielevering werd afgekeurd vanwege een overlap werd in het geval dat het een volledige overlap van 2 objecten betrof in het verwerkingsverslag toch gesproken van een ‘rest-overlap’. Oplossing: In het geval van een volledige overlap is de term 'rest-overlap' vervangen door 'overlap'.

[2600] "Numeric overflow" verstoort berichtenverkeer

Het automatisch berichtenverkeer was verstoord geraakt doordat de database te maken kreeg met een ‘numeric overflow’. Oplossing: Packages opnieuw gecompileerd en de signalen die waren blijven hangen weer op gang geholpen. Aanleiding wordt nader onderzocht.

[2594] Er blijken toch nog dubbele e-mailadressen opgevoerd te kunnen worden.

In het kader van de AVG-maatregelen moeten alle accounts unieke e-mailadressen hebben. Het bleek echter dat bij het aanmaken van nieuwe accounts er toch nog e-mailadressen konden worden opgevoerd die al bij andere accounts in gebruik waren.

[2587] Abonnementen hebben na bijna een etmaal nog geen nulstand

Diverse nulstand-abonnementen die voor een bronouder waren besteld stonden al circa 23 uur op actief en hadden nog steeds geen nulstand. Oplossing: Dit had er mee te maken dat er bij enkele medewerkers van die bronhouder ongeldige e-mailadressen geregistreerd stonden. Daardoor gaf de verzending van de notificatie-email een fout waarop de abonnementen-jobs vastliepen. Er zijn code-aanpassingen gedaan waardoor de jobs als gevolg van een dergelijke verzendfout niet meer kunnen vastlopen.

[2586] Foutieve mailtitels bij logging van te schonen abonnementen

De automatische job die controleert of er abonnementen in aanmerking komen om geschoond te worden verstuurt notificatiemails naar de SVB-BGT beheerder. Wanneer er heel veel abonnementen gevonden zijn worden de mails in kleinere delen opgesplitst die apart worden verzonden. Daarbij werd in de opeenvolgende deel-mails een onjuiste titel mee-gekopieerd. Oplossing: Code-aanpassing waardoor de deel-mails nu een correcte titel krijgen.

Known issues / niet opgeloste bevindingen

[2617] Einddatum kan nog gewijzigd worden nadat abonnement al is opgeheven

Nadat abonnement is opgeheven kan gebruiker de einddatum weer in de toekomst zetten en dat opslaan.

[2582] Datumfilter bij CSV-rapportage geeft soms verkeerd resultaat

Wanneer er geswitcht wordt tussen bijvoorbeeld tabblad Home en weer terug naar tabblad Leveringen komt het datumfilter er 2 keer in te staan. Het ene datumfilter heeft de standaard waarde van 2 maanden voor de huidige datum, de andere de door de gebruiker aangepaste datum. Vermoedelijk blijft het standaard datumfilter onderhuids actief waardoor de csv niet alle gegevens bevat.

[2578] Kan organisatie van account niet meer aanpassen

Beheerder kan de ‘organisatie’ in een BRAVO-account niet meer kan aanpassen. Dit zat altijd onder het detailscherm "onderhouden gebruiker", maar daar staat dit veld niet meer tussen.

[2574] Wachtwoord dat begint met cijfer wordt niet geaccepteerd

Wachtwoorden die beginnen met een cijfer worden bij aanpassen van het wachtwoord geaccepteerd.

[2564] Handleiding in BRAVO is verouderd

De te downloaden versie is nog niet is bijgewerkt voor BRAVO 19.1 en 19.2

[2562] Aanpassen van abonnementsgebied werkt niet goed

Tijdens het wijzigen van een bestaand abonnementsgebied komt de kaart soms plotseling in ‘versleep-modus’ terecht en beweegt daardoor met de muis mee. Bovendien treedt er dan een error op wanneer men vanuit die situatie probeert op te slaan.

[2529] Kruinlijn controle doet het niet

In een specifieke situatie werd een levering met een ontbrekende kruinlijn niet door BRAVO afgekeurd, maar wel achteraf door de LV-BGT. [2455] Locking voor ORL’s gaat niet goed
Locking van ORL’s ging tijdens het opvulproces niet goed bij ORL’s die zelf geen geometrie hebben maar alleen labelpositie(s).

Vraag en antwoord

De volgende BGT RSS-feeds zijn beschikbaar voor uw RSS-reader:

Hebt u een vraag waarop u het antwoord niet kon vinden? Neem dan contact op met de klantenservice BGT op telefoonnummer 088 - 183 46 00. Onze medewerkers zijn u op werkdagen van 9.00 tot 17.00 uur graag van dienst. Of stel uw vraag direct via het contactformulier.