Inhoud van release BRAVO

Transcriptie

1 Inhoud van release BRAVO Release notes BRAVO Dit document bevat een opsomming van de issues die zijn opgelost in de onderstaande BRAVO release: Functionele wijzigingen en opgeloste storingen 3 juli 2017 Functionele wijzigingen... 3 [1926] Het aan- of uitzeten van het automatisch berichtenverkeer wordt gelogd... 3 [1884] Maximum grootte XML-bestand van mutatieberichten instelbaar door SVB-BGT... 3 [1833]Gebied van opvullevering kan als GML-bestand worden geupload [1778] Controle op lengte van bestandsnaam... 3 [1602] GBKNTel implementatie in BRAVO... 3 Opgeloste storingen... 3 [1982] NARs verdwenen na bronhouderscodewijziging... 3 [1962] Fout bij bepalen WORDT van een mutatielevering... 4 [1955] Performance bepalen overlappen WORDT met Initiële levering... 4 [1947] Bronhouder kan afgekeurd abonnement na einddatum niet terugzetten naar status Opgevoerd... 4 [1938] Storing bij het oplossen van foutieve kruinlijnen door opvulprocedure... 4 [1933] Ongeldige XML bij herindelingslevering... 4 [1923] Geen filter toegepast voor opvullevering vanuit Home overzicht... 4 [1916] Abonnementsgebied heeft na upload verkeerde vorm gekregen... 4 [1912] Automatische filtering op bronhouder in leveringenscherm werkt niet... 4 [1911] Rollen onderhouden werkt niet goed... 4 [1908] Opvullevering: Rapportage LV kan niet handmatig ge-upload worden in het portaal... 4 [1855-2] Controle op bestandsgrootte gaat ten onrechte ook af bij statusupdates van het bestand 4 [1779-1] Na herstart van het ABV wordt toch weer het onjuiste endpoint gebruikt... 5 Known issues (storingen) [1987] BRAVO en LV niet synchroon... 6 [1979] Afhandelen Abonnementsbestanden in Portaal... 6 [1947] Bronhouder kan afgekeurd abonnement na einddatum niet terugzetten naar Opgevoerd.. 6 [1905] Nog steeds ORA en ORA [1894] Interactieve rapporten in abonnementenscherm blijven niet bewaard na opslaan... 6 [1867] Geometrie ten onrechte goed gevalideerd

2 [1858] Vavdi01naar bronhouder mag geen Anonymous response in ReplyTo adressing hebben... 6 [1809] Indien in één pand meerdere NARs een WAS/WAS fout veroorzaken wordt alleen de eerste gemeld... 7 [1787] Performance bepalen bij from hold halen van initiele leveringen is laag... 7 [1773] Sluis is in het abonnement terug gekomen als een Multi-vlak... 7 [1761] Vlakobject is als (invalide) lijn in het abonnement terechtgekomen... 7 [1701] Stuurgegevens: Tijdstip bericht wordt vermeld in zomertijd ipv GMT+1 (CET)... 7 [1698] Stuurgegevens: het format van het referentienummer voldoet niet aan de standaard... 7 [895]Nadat een vooraankondiging is aangepast via automatisch berichtenverkeer wordt toch nog de oude versie getoond

3 Functionele wijzigingen De nummers tussen [] zijn de nummers van de corresponderende issues uit de Transfer Solutions Servicedesk. [1926] Het aan- of uitzeten van het automatisch berichtenverkeer wordt gelogd Wanneer het automatisch berichtenverkeer tussen BRAVO en de LV BGT wordt aan- of uitgezet zal worden gelogd wanneer en door wie dit is gebeurd. Bijvoorbeeld door een beheerder of door BRAVO zelf. [1884] Maximum grootte XML-bestand van mutatieberichten instelbaar door SVB-BGT De parameter die bepaalt wat de maximale grootte is van opgevoerde mutatiebestanden kan nu door een beheerder bij SVB-BGT worden ingesteld. [1833]Gebied van opvullevering kan als GML-bestand worden geupload. Net als bij abonnementen kan een GML-bestand worden geüpload met het gebied waarbinnen een opvullevering moet worden uitgevoerd. Bovendien kan het gebied van een opvullevering als een GML-bestand worden gedownload. Dit is bijvoorbeeld handig wanneer men een opvulling binnen hetzelfde gebied opnieuw wil uitvoeren.. [1778] Controle op lengte van bestandsnaam Bij het opvoeren van een levering (initieel of mutatie) wordt gecontroleerd dat de bestandsnaam (inclusief de extensie. Zip ) niet langer is dan 80 karakters. Wanneer dat wel zo is, gebeurt het volgende: * Bij handmatige opvoer van een mutatielevering --> Melding: De lengte van de bestandsnaam van het aangeleverde bestand is te groot. Een bestandsnaam mag maximaal 80 tekens groot zijn. * Bij opvoeren van een mutatielevering via automatisch berichtenverkeer --> er wordt een Fo03 teruggegeven, met fout_code = 'StUF204', fout_omschrijving := 'Ongeldige bestandsnaam ', fout_details := 'Bestandsnaam is [lengte] karakters lang. Maximum lengte = 80 [1602] GBKNTel implementatie in BRAVO De tellingen zoals die vroeger op CAD-bestanden werden uitgevoerd m.b.v. GBKNTel worden nu door BRAVO uitgevoerd op basis van de geometrie van BGT-objecten. Deze tellingen worden uitgevoerd voor elke mutatielevering en de resultaten daarvan worden vermeld in het verwerkingsverslag. Opgeloste storingen [1982] NARs verdwenen na bronhouderscodewijziging Bij het registreren van de resultaten van een Bronhouderscodewijziging in de productiedatabase van BRAVO werden de NARs en ORLs van de betreffende objecten niet meegenomen terwijl deze wel in de LV BGT geregistreerd waren. Daardoor waren BRAVO en de LV uit sync. Oplossing: Code voor het overzetten van gegevens naar de PRD laag (voor PND en ORL objecten) is aangepast, zodat NAR en Labels nu wel meegaan. Ontbrekende NAR en Labels zijn hersteld. 3

4 [1962] Fout bij bepalen WORDT van een mutatielevering Een toegevoegd PND object kwam niet in de omhullende van de WORDT van de levering terecht. Hierdoor werd ten onrechte een overlap met een lopende initiële levering (48420) over het hoofd gezien. [1955] Performance bepalen overlappen WORDT met Initiële levering Deze stap wordt bij elke mutatielevering uitgevoerd, en duurde nogal lang, zekere wanneer de WORDT complex is. De SQL in de procedure is verbeterd. [1947] Bronhouder kan afgekeurd abonnement na einddatum niet terugzetten naar status Opgevoerd Als een abonnement een ingevulde einddatum in het verleden heeft, dan kon de status niet teruggezet worden van Afgekeurd naar Opgevoerd. Dat gaf de melding: 'De einddatum van een abonnement mag niet in het verleden liggen'. Hierdoor konden bronhouders afgekeurde abonnementen niet zelf verwijderen terwijl ze ook niet door de automatische schoningsprocedure werden verwijderd. Oplossing: Afgekeurd abonnement kan nu teruggezet worden naar Opgevoerd. Krijgt dan de systeemdatum. Kan daarna ook verwijderd worden. [1938] Storing bij het oplossen van foutieve kruinlijnen door opvulprocedure Bij de verwerking van opvullevering 3068 treedt een ORA-fout bij het oplossen van kruinlijnen: ORA-06533: Subscript beyond count. De levering is op status Opvullen mislukt gegaan. [1933] Ongeldige XML bij herindelingslevering Levering Een bestand werd afgekeurd door de LV, wegens ongeldige xml. Bestand bevat niet valide xml. cvc-type.3.1.2: Element 'stuf-geo:hoek' is a simple type, so it must have no element information item [children]. Er ging iets mis bij het overhalen van de labelposities, en werden er teveel vastgelegd in de LRG laag van BRAVO. Hierdoor ontstond de foute xml. [1923] Geen filter toegepast voor opvullevering vanuit Home overzicht Wanneer men in het Home-scherm in de Opvullevering kolom klikte op Afgerond, werd er geen filter toegepast, waardoor men alle afgeronde leveringen te zien kreeg. Een soortgelijk probleem deed zich voor in de Abonnementen kolom. Ook dit is opgelost. [1916] Abonnementsgebied heeft na upload verkeerde vorm gekregen Na de upload van het abonnementsgebied in BRAVO ( Abonnement_Provincie_Overijssel_Gebied_1) ziet dit er anders uit dan wat in de GML zit. Het bleek dat het abonnementsgebied wel correct in de database was opgenomen, maar dat er een probleem was met de visualisatie in de portaal. [1912] Automatische filtering op bronhouder in leveringenscherm werkt niet Het filter is wel aanwezig maar bleek te zijn uitgeschakeld. Het filter is weer ingeschakeld voor bronhouders/gemachtigden. Voor beheerders / medewerkers SVB-BGT is er geen filtering. Zij moeten alle leveringen kunnen zien. [1911] Rollen onderhouden werkt niet goed Onder bepaalde omstandigheden was het voor een beheerder niet mogelijk om functies bij bronhouders toe te voegen. [1908] Opvullevering: Rapportage LV kan niet handmatig ge-upload worden in het portaal Het lukte niet om het verwerkingsverslag van de LV te uploaden bij een Opvullevering met status Aangeboden aan LV. [1855-2] Controle op bestandsgrootte gaat ten onrechte ook af bij statusupdates van het bestand Dit is een naderhand opgeloste bevinding uit de acceptatietest van BRAVO De controle op de ongezipte bestandsgrootte van het aangeleverde gegevensbestand bij een mutatielevering moet alleen plaats vinden bij 4

5 opvoer, dus bij status 'Nieuw' van het bestand. Het gebeurde echter ook bij updates van het bestand, en dat zijn alleen statusupdates door validatie en registratie, en daarbij is de bestandsgrootte niet meer van belang. [1779-1] Na herstart van het ABV wordt toch weer het onjuiste endpoint gebruikt Dit is een naderhand opgeloste bevinding uit de acceptatietest van BRAVO Bij een signaal (2146, KTO) bleef het ABV het bericht sturen naar het verkeerde endpoint, ook na wijzigen Gekeken is naar signaal 2180 (KTO) en wat hier aan de hand kan zijn geweest. Het blijkt dat bij het [Opnieuw verzenden] van een signaal de status van het signaal wordt omgezet, en dat er verder niet wordt gekeken of er misschien iets in de stuurgegevens is gewijzigd, zodat die ook in het signaal gewijzigd worden. Dat moet dus wel gebeuren. [1607] Dubbele statussen in portaal Sommige statussen, zoals Aangeboden aan LV werden binnen dezelfde kolom van het Home-scherm (dashboard) dubbel getoond. 5

6 Known issues (storingen) [Callnummers zijn uit de Transfer Solutions Service desk]. [1987] BRAVO en LV niet synchroon Gemeente Renswoude. Mutatie en Beide mutaties worden afgekeurd door de LV vanwege verschil was-situatie en stand in de LV bij object L0001.3faea898af1e4e95b13f19430c70860c. Uit onderzoek blijkt dat er bij dit object een verschil zit in de TijdstipRegistratie tussen BRAVO en de LV. Is in behandeling [1979] Afhandelen Abonnementsbestanden in Portaal Bij het vastleggen van de abonnementsbestanden (na registratie van een levering) wordt regelmatig een piekbelasting op de database (portaal) geconstateerd. De afhandeling geschiedt nu per bestand in een apart job (sessie). met name het weer afronden van de sessie (plus de commit) zorgt voor veel overhead. [1947] Bronhouder kan afgekeurd abonnement na einddatum niet terugzetten naar Opgevoerd Wanneer als een abonnement met de status Afgekeurd een ingevulde einddatum in het verleden heeft, dan kan de status niet teruggezet worden naar Opgevoerd. Dan verschijnt de melding: 'De einddatum van een abonnement mag niet in het verleden liggen'. Bronhouder heeft hierdoor geen mogelijkheid om zo n abonnement zelf te verwijderen. [1905] Nog steeds ORA en ORA Deze fout treedt nog steeeds af en toe op. Verder onderzoek naar oorzaak is gewenst. [1894] Interactieve rapporten in abonnementenscherm blijven niet bewaard na opslaan Rapporten in BRAVO zijn zogenaamde 'interactieve rapporten'. Gebruikers kunnen zelf een rapport definiëren en dit opslaan. Dit is in BRAVO opgenomen als standaard functionaliteit. De volgende keer dat iemand met dezelfde account inlogt zou het rapport weer beschikbaar moeten zijn. Het is echter niet voor andere gebruikers beschikbaar. Bij 'Leveringen' gaat dit goed, maar bij Abonnementen niet. Na opslaan is het opgeslagen rapport verdwenen, zelf al nadat men een bijvoorbeeld een zijstapje naar het leveringen scherm heeft gemaakt. [1867] Geometrie ten onrechte goed gevalideerd Deze geometrie heeft een gat, waarvan 1 van de punten ( ) op minder dan 0.5 mm van de buitenpolygoon afligt. Deze situatie zou door de Oracle validate functie moeten worden afgekeurd, maar dat gebeurt niet. Hierdoor is dit object ten onreche doorgelaten en in de LV terecht gekomen. Commentaar: Oracle Spatial Development ziet dit niet als een bug, omdat e.e.a. binnen de tolerantie van Oracle goed valideert. Dit probleem speelt dus niet alleen in BRAVO, maar ook bij de LV. Het is mogelijk om deze situaties (met de huidige Oracle technologie) te detecteren, echter dat vereist extra controles en mogelijk ad-hoc detectiescripts op de reeds geregistreerde objecten. [1858] Vavdi01naar bronhouder mag geen Anonymous response in ReplyTo adressing hebben Bij een leverancierstest met ABV tbv de aansluiting van RWS trad de volgende melding <Soap Fault> op bij het verwerken van de vavdi01 die BRAVO terugstuurt: Found anonymous address but non-anonymous required. In de wsdl staat het volgende commentaar: addressing dient ondersteund te worden met nonanonymous response. Het lijkt er op dat BRAVO niet conform hiermee is. 6

7 [1809] Indien in één pand meerdere NARs een WAS/WAS fout veroorzaken wordt alleen de eerste gemeld Indien in één pand meerdere nummeraanduidingsreeksen een WAS/WAS fout veroorzaken wordt alleen de eerste gemeld. Na correctie wordt pas de tweede fout in hetzelfde object gemeld. [1787] Performance bepalen bij from hold halen van initiele leveringen is laag Dit is een complexe query, waarin veel voorwaarden worden gecontroleerd die afhankelijk zijn van de status en het type van de levering. Daar zijn nog geen indexen op, en deze query duurt lang. [1773] Sluis is in het abonnement terug gekomen als een Multi-vlak Het betreft de melding dat BRAVO sommige uitzonderingssituaties niet goed in het LV bericht opneemt. Die kunnen, zoals in dit specifieke geval, ontstaan tijdens assemblage, maar ook door de bronhouder zo worden aangeleverd. Er is een tweetal wijzigingen nodig om dit te verbeteren. [1761] Vlakobject is als (invalide) lijn in het abonnement terechtgekomen Kunstwerkdeel dat als vlakobject is aangeleverd, is via het abonnement als lijnobject terug geleverd. Het lijnobject is niet valide waardoor de nul-stand niet kan worden ingelezen. Het assemblage-proces zal aangepast moeten worden dat deze situatie niet meer voor kan komen. Als de assemblage van een vlakobject resulteert in een lijnobject zal een foutmelding moeten komen. [1701] Stuurgegevens: Tijdstip bericht wordt vermeld in zomertijd ipv GMT+1 (CET) Status: Is besproken in leveranciersoverleg. Reactie van keten release manager: dit zie ik als een wijzigingsverzoek van de leveranciers om de standaard aan te passen naar UTC. Transfer ziet echter een technische belemmering, namelijk het XSD staat het niet toe. Mijn voorstel is om op termijn over te gaan naar UTC, maar pas op het moment dat het XSD wordt herzien. Tot die tijd wordt zomer- en wintertijd gehanteerd. [1698] Stuurgegevens: het format van het referentienummer voldoet niet aan de standaard Status: Is besproken in het leveranciersoverleg. Reactie van keten release manager: hierin zie ik een wijzigingsverzoek van de leveranciers om de standaard aan te passen om het mogelijk te maken dat één bronhouder vanuit twee systemen unieke automatische berichten kan sturen. Dat wordt makkelijker als er een GUID wordt gebruikt in plaats van een numeriek volgnummer. [895]Nadat een vooraankondiging is aangepast via automatisch berichtenverkeer wordt toch nog de oude versie getoond Als er via ABV mutaties worden verstuurd op VAV s dan worden deze wel succesvol doorgestuurd naar de LV en deze komen ook weer op de juiste manier terug. Echter wordt in het webportaal niet de oude versie gearchiveerd waardoor beide zichtbaar blijven. 7