Releasenotes VERA-standaard

VERA Standaard > Standaarden > Releasenotes

Snel naar:

Patches 4.0 Technische en functionele Bugfixes	Referentiedata Wijzigingen in de referentiedata	VERA 3.x Releasenotes van de VERA 3.x versies

Wat is er nieuw in VERA 4.0?

Best veel! We maken gebruik van nieuwe REST technologieën (OpenApi, YAML) en veel nieuwe functionele uitwerkingen van ketenprocessen en het informatiedomein Projectontwikkeling.

Functionele uitbreiding met nieuwe ketenprocesmodellen

Naar aanleiding van de werkgroep voor CRM en klantportalen zijn de meest voorkomende benodigde API's uitgewerkt. Klantportalen hebben een rol in verschillende ketenprocessen.

Casemanagement Het afhandelen van zaken/processen en het opbouwen van bijbehorende dossiers. Bij de realisatie van alle zaken en processen kunnen dossiers worden opgebouwd. Deze dossiers bestaan voornamelijk uit co... lees verder	Beheer Financiële gegevens Het beheer van de financiële gegevens heeft betrekking op het borgen van de datakwaliteit van deze gegevens en het beschikbaar stellen aan andere ketenprocessen. Zo verzorgt dit proces de vastlegging en... lees verder	Beheer Relatiegegevens Het beheren van relatiegegevens is een belangrijk onderdeel van de administratie binnen een woningcorporatie. Datakwaliteit is een essentieel onderdeel in de bedrijfsvoering van een woningcorporatie w... lees verder
Beheer Vastgoedgegevens Het beheren van de gegevens uit het Vastgoed domein. Vaak het gevolg van nieuwbouw, renovatie, aankoop, verkoop, sloop of administratieve wijzigingen. Dit beheer is een belangrijk onderdeel van de adm... lees verder	Incasso Het afhandelen van incassoprocessen. Het incasseren van vorderingen bij de contractant binnen de betalingstermijn of zo snel mogelijk daarbij tegen zo gering mogelijke kosten voor de contractant en de... lees verder	Verhuren Eenheden Verhuren Eenheden is het proces waarmee aangaan en beëindigen van de huurovereenkomst met huurders wordt gerealiseerd inclusief het in rekening brengen van de netto huur. Verhuren Eenheden is het proce... lees verder

Bestaande ketenprocesuitwerkingen hebben een nieuw versienummer gekregen

• Kwaliteitsmanagement - Versie 2 definitieve REST versie.
• Onderhouden Eenheden - Versie 2 uitgebreid met bericht voor klantportalen.
• Woonruimteverdeling - Versie 3 bevat ondersteuning voor de nieuwe woonruimteverdeling op basis van het puntensysteem.

Definitieve versie van informatiedomein Projectontwikkeling

Op bassis van de resultaten van de werkgroep Projectontwikkeling is het informatiedomein uitgewerkt naar een nieuw gegevensmodel. Het is mogelijk om de gegevens van een project met al haar fasen en besluiten te beheren. De focus van de uitwerking ligt op het ontwikkelen van nieuwe eenheden maar andersoortige projecten zoals renovatie passen ook in het model.

REST met OpenAPI en YAML

Eerdere versies van VERA waren op basis van SOAP en StUF en maakte gebruik van WS-* standaarden voor beveiliging, adressering en betrouwbare communicatie. We nemen afscheid van StUF met VERA 4.0. Met REST duiken we in een nieuwe wereld waarbij er verschillende keuzen mogelijk zijn voor de technische realisatie. Met een REST werkgroep met vertegenwoordigers van de meest gebruikte leveranciers zijn een aantal keuzen gemaakt die zijn uitgewerkt in VERA 4.0. Uitgangspunten bij de keuzen:

• We willen niet het wiel opnieuw uitvinden dus sluiten aan bij Common Ground zoals deze door VNG (Vereniging Nederlandse Gemeenten) wordt toegepast.
• We zijn een standaard dus leveren contractgebaseerde berichten.
• Kiezen voor een OpenAPI specificatie met YAML contracten en JSON berichten zoals VNG ook heeft gekozen.

Relevante links

• https://commonground.nl
• https://www.vngrealisatie.nl/roadmap/common-ground
• https://github.com/VNG-Realisatie
• https://github.com/VNG-Realisatie/API-Kennisbank/tree/master/Design%20rules
• https://swagger.io/specification/
• https://docs.geostandaarden.nl/api/API-Strategie/

OData? Voor VERA 4.0 ligt de focus op gestandaardiseerde ketenprocesberichten. Vanuit de werkgroep is gesproken over OData en hoewel veel leveranciers hun data kunnen ontsluiten via OData is het voor de meeste leveranciers lastig om complexe mutaties via hun OData koppelvlakken te verwerken. De werkgroep heeft geconstateerd dat er sowieso een VERA integratielaag nodig is naar de eigen API's voor de meeste leveranciers. Die eigen API's kunnen natuurlijk in ieder gewenst formaat zijn, OData, SOAP, XML, JSON etc.

Berichten, Entiteiten en Attributen

Via de API's worden berichten verstuurd. Deze berichten bestaan uit entiteiten. Entiteiten bestaan weer uit attributen waar de data in wordt uitgewisseld.

API's

Met VERA 4.0 leveren we per informatiedomein en per ketenprocesmodel een zelfomvattende API. Er zijn geen afhankelijkheden tussen de verschillende API's.

• Informatiedomein API's bevatten voor iedere Entiteit uit dat domein een resource waarmee de entiteit kan worden opgehaald op basis van het ID of door filters op basis van attribuutwaarden.
• Ketenprocesmodel API's bevatten voor ieder ketenprocesbericht een resource waarmee een of meer berichten:
  • worden opgehaald op basis van het ID of door filters op basis van attribuutwaarden.
  • doorgestuurd voor het aanmaken, wijzigen of vervangen van de Entiteiten uit het bericht.

Flexibel bruikbare berichten

Iedere resource is via twee paden te benaderen:

• Path /resourcenaam voor het ophalen van een of meer berichten.
• Path /resourcenaam/{id} voor het ophalen van een bericht op basis van het ID.

Headers
Bij een bericht kun je bepaalde headers meegeven:

• Page: Huidige pagina met resultaten. In combinatie met limit te gebruiken.
• Limit: Aantal resultaten per pagina.
• TijdstipBericht: Tijdstip waarop het bericht verzonden is.
• Referentienummer: Een unieke code voor correlatie. Vaak het nummer van het bericht op een servicebus of queue.
• Zender: Identificatie van de verzendende organisatie. Vaak gebruikt voor routing van berichten naar de juiste systemen of acounts. Bijv. Alliantie Gooi en Vechtstreek, Mitros, Qlinker etc.
• Peildatum: Geeft aan dat de waarden van de gegevens worden verwacht op een specifieke datum in het verleden.

Filters
Een resource kun je met filters bevragen. In principe is ieder attribuut van een resource te gebruiken om het resultaat te filteren.
Bijv. /Relaties/filter[soort]=Natuurlijkpersoon&filter[adres.woonplaats.naam]=Zaandam geeft alle natuurlijke personen uit de woonplaats Zaandam terug. De beschikbaarheid van deze functionaliteit is afhankelijk in hoeverre een leverancier deze implementeerd. Ketenprocesberichten hebben vaak een speciaal doel en is filtering op enkele attibuten vaak voldoende.

Uitbreidingen
Ieder bericht is uit te breiden met:

• informatieobjecten; informatie in de breedste zin van het woord. Dit kunnen notities, documenten, e-mails etc. zijn.
• extraAttributen; een of meer naam en waarde combinaties om entiteiten mee uit te breiden. Een standaard beweeg niet altijd even snel als de martk maar op deze manier is het toch mogelijk om nieuwe velden uit te wisselen zonder eigen versies van entiteiten te maken. Idealiter worden deze aangemeld bij VERA om in een volgende versie op te namen als eigen attribuut.
• Sturingslabel; Label die sturend is in een proces of definitie. Vaak wordt dit gebruikt als de definitie achter een label niet is af te leiden uit de attributen van een bericht.

Attributen makkelijk vindbaar

• Iedere entiteit heeft nu een vaste attribuutvolgorde:

1. Identificerende en beschrijvende attributen. Bijv. id, code, soort, naam, omschrijving etc.
2. Levenscyclusattributen. Bijv. status, begindatum, opleverdatum etc.
3. Overige attributen volgen op alfabetische volgorde.
4. Uitbreidingsattributen.

• Obsolete attributen zijn weg.

Uniforme specialisatie-entiteiten

• Postadres, Eenheidadres, BuitenlandsAdres zijn specialisaties geworden van Adres.
• Specialisatie entiteiten zijn uniform gemaakt, er wordt nu altijd direct verwezen naar Adres, Contactgegeven, Relatie, Overeenkomst, en Geometrie i.p.v. naar de subentiteiten. Er wordt gebruik gemaakt van een oneOf constructie waarbij je bij het opvragen van de specialisatie entiteit de attributen terugkrijgt van de subentiteit. In deze gevallen is er altijd een soort attribuut die aangeeft welke soort de subentiteit is.

Relaties, soorten en rollen

We hebben de implementatie van de entiteiten Relatie, NatuurlijkPersoon, Rechtspersoon, Relatiegroep en Relatierol consistent gemaakt.

Op hoofdlijnen:

• Er zijn geen directe verwijzingen in attributen meer naar NatuurlijkPersoon, Rechtpersoon en Relatiegroep. Deze zijn allemaal omgezet naar een attribuutverwijzing naar Relatie of Relaties.
• Attribuutnamen met specifieke rollen zijn samengevoegd naar een Relatie of Relaties attribuut. Bij de verwezen Relaties kan de rol die van toepassing is worden opgenomen.
• Het is mogelijk gemaakt om direct bij een relatiegroep een collectie van de relaties op te nemen. Dat hoeft niet meer via Relatierol.

Bijvoorbeeld:

• Attribuut Eenheid.eigenaar was een verwijzing naar een relatie in eerdere versies van VERA. Nu vind je de eigenaar in Eenheid.Relaties waar Relatie.relatierol.soort = "Eigenaar". Om deze functionaliteit te kunnen leveren in het logische VERA model is het nodig om in het technische datamodel van leveranciers een koppeltabel te hebben tussen Eenheden en RelatieRollen. Optioneel kan men daarbij ook de relatie vastleggen zodat je die niet via de rol hoeft op te zoeken.
• Attribuut CollectiefObject.eigenaar was een verwijzing naar een Rechtspersoon in eerdere versies. Nu vind je de de eigenaar in CollectiefObject.relaties waar Relatie.relatierol.soort = "Eigenaar".
  

→ Meer informatie over het toepassen van relaties

Gebruik ID's

VERA 4.0 kent voor iedere entiteit verschillende identificerende attributen. Gegevens worden steeds meer uitgewisseld tussen systemen. Daarnaas worden gegevens ook gebruikt door medewerkers. Hierdoor zijn er verschillende soort ID's nodig.

→ Gebruik van ID's in VERA

Overige wijzigingen/RFC in VERA 4.0

Naast het hele ombouwen van de standaard naar REST zijn er ook RFC's doorgevoerd:

• Attribuut huurHerzieningsdatum toegevoegd op Entiteit Huurovereenkomst.
• Attribuut uitersteStartdatum toegevoegd op Entiteit Onderhoudsorder.
• Attributen eenheid, cluster en collectiefObject op Onderhoudsorder.
• Attribuut deelClusters verwijderd van Entiteit Cluster.
• Attribuut nettohuur is verwijderd van de Entiteit Huurovereenkomst.
• Attribuut boekstuknummer is type string geworden op entiteit Grootboekmutatie.
• Attribuut subsidiabeleHuur op Entiteit Eenheid is hernoemd naar rekenhuur.
• Nieuwe entiteit Kadasterperceel in domein vastgoed.
• Attributen status en anderen die voor alle overeenkomsten kunnen gelden zijn naar Entiteit Overeenkomst verplaatst vanuit Entiteit Huurovereenkomst.
• Attribuut nettohuur is verwijderd van de Entiteit Huurovereenkomst.
• Attributen leegwaarde, verhuurderheffing toegevoegd op Entiteit Marktwaarde.
• Attribuut soort verwijderd van Entiteiten Buurt en Wijk.
• Attributen naam en subsidieSoort toegevoegd aan Entiteit Prijscomponent.
• Attribuut woonvertrekkenTotaalOppervlakte is type decimal geworden op Entiteit Eenheid.

Met dank aan

Vera 4.0 is tot stand gekomen door de noeste arbeid van een aantal werkgroepen. Aan deze werkgroepen deden medewerkers mee van:

Projectontwikkeling Batavia Groep CORA De Alliantie De Key Itris Novius Portaal Skarp IJKX Interim & Advies Vestia	Klantportalen Aareon Cegeka-DSA Databalk.nu Datarotonde Embrace Cloud Skarp SWEMP WoningNet ZIG Websoftware	REST Aareon Cegeka-DSA Databalk.nu Datarotonde Itris Hercules Software Ketenstandaard NCCW Skarp VNG-Realisatie WoningNet ZIG Websoftware	Klankbordgroep Blue Mountain BOEX Brightanswers Databalk.nu De Key Duwo Harmony Group Havensteder Hercules Software Idealis Itris Kleurrijk wonen NCCW Qii Spacewell SSHN Staedion Woonkracht 10 WSN