|
|
| (7 tussenliggende versies door 2 gebruikers niet weergegeven) |
| Regel 1: |
Regel 1: |
| <!-- kruimelpad --><div class=" archimate-breadcrumbs">[[ VERA_Standaard|VERA Standaard]] > [[ Standaarden| Standaarden]] > Releasenotes</div> | | {{Lead|<h1>Releasenotes VERA-standaard</h1>|Integration banner1600x300.webp}}<!-- |
| | -->{{#Context: |
| | |span=|text=<div class=" title"> Gerelateerde links</div> |
| | * [[VERA_Release_en_versiebeleid|VERA Release en versiebeleid]] |
| | * [[Releasenotes|Architectuur: Releasenotes wiki]] |
| | |class=links |
| | }}<!-- |
| | --><div class="knoppengrid"><!-- |
| | -->[https://github.com/Aedes-datastandaarden/vera-openapi/releases <div class="titel">Releasenotes Patches ↗</div>Technische en functionele Bugfixes.]<!-- |
| | -->[https://github.com/Aedes-datastandaarden/vera-referentiedata/releases <div class="titel">Referentiedata ↗</div>Wijzigingen in de referentiedata.]<!-- |
| | -->[[VERA_releasenotes_4.0|<div class="titel">VERA 4.0</div>Releasenotes van VERA 4.0.]] |
| | </div> |
|
| |
|
| Snel naar:
| | [[Bestand:Vera 4.1 logo.png|miniatuur|rechts|link=]] |
| {| class="table" style="width:800px;" | | = Wat is er nieuw in VERA 4.1? = |
| | Naast de verwerking van een flink aantal RFC's hebben we ook de techniek uitgebreid. Het is nu mogelijk om OAuth2 te gebruiken voor de beveiliging. Daarbij kan met behulp van scopes lees- en/of schrijftoegang worden gegeven tot op het niveau van de REST resources. |
| | |
| | === Bestaande ketenprocesuitwerkingen hebben een nieuw versienummer gekregen=== |
| | {| class="wikitable" style="width:300px;" |
| | |+ Ketenprocessen |
| | |- |
| | ! Naam !! Code !! Versie |
| | |- |
| | | Beheer financiële gegevens || BFG || 1.1 |
| | |- |
| | | Beheer Overeenkomstgegevens || BOG || 1.1 |
| | |- |
| | | Beheer Relatiegegevens || BRG || 1.1 |
| | |- |
| | | Beheer Vastgoedgegevens || BVG || 1.1 |
| | |- |
| | | Casemanagement|| BDO || 1.1 |
| | |- |
| | | Incasso || INC || 1.1 |
| | |- |
| | | Kwaliteitsmanagement || KMT|| 2.1 |
| |- | | |- |
| ! width="33%" | [[VERA_Releasenotes_Patches|Patches 4.0]]<br />Technische en functionele Bugfixes !! width="33%" | [[VERA_Releasenotes_referentiedata|Referentiedata]]<br />Wijzigingen in de referentiedata !! width="33%" | [[VERA_releasenotes_3|VERA 3.x]]<br />Releasenotes van de VERA 3.x versies
| | | Onderhouden Eenheden || OHD || 2.1 |
| |}
| |
| | |
| [[Bestand:Vera 4.0.png|miniatuur|rechts]]
| |
| = 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.
| |
| | |
| {| class="table" style="width:800px;"
| |
| |- | | |- |
| | '''Casemanagement''' | | | Verhuren Eenheden || VHE || 1.1 |
| 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... [[Ketenprocessen|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... [[Ketenprocessen|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... [[Ketenprocessen|lees verder]]
| |
| |- | | |- |
| | '''Beheer Vastgoedgegevens''' | | | Woonruimteverdeling || WRV || 3.1 |
| 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... [[Ketenprocessen|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... [[Ketenprocessen|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... [[Ketenprocessen|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 [https://socialehuurwoningzoeken.nl/ puntensysteem].
| |
|
| |
|
| |
| [[Bestand:Projectontwikkeling.png|200px|miniatuur|links|link=Id-52c10659-b9da-c240-ffa7-ad029a6b33f9]]
| |
|
| |
| === 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.
| |
|
| |
|
| |
|
| |
|
| |
| [[Bestand:OpenAPI3.jpg|miniatuur|rechts|200px]]
| |
|
| |
|
| == REST met OpenAPI en YAML == | | == 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.
| | Sinds VERA 4.0 zijn de VERA-koppelingen volgens de REST OpenAPI standaard gespecificeerd. |
| Uitgangspunten bij de keuzen:
| | Met VERA 4.1 introduceren we de mogelijkheid om OAuth2 te gebruiken voor de beveiliging van de VERA-koppelingen. Hierbij ondersteunen we ook het werken met scopes voor het toekennen van lees- en schrijfrechten binnen de koppelingen. |
| * We willen niet het wiel opnieuw uitvinden dus sluiten aan bij [https://commonground.nl 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'''<br />
| |
| 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'''<br />
| |
| Een resource kun je met filters bevragen. In principe is ieder attribuut van een resource te gebruiken om het resultaat te filteren.<br />
| |
| 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'''<br />
| |
| 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:
| |
| # Identificerende en beschrijvende attributen. Bijv. id, code, soort, naam, omschrijving etc.
| |
| # Levenscyclusattributen. Bijv. status, begindatum, opleverdatum etc.
| |
| # Overige attributen volgen op alfabetische volgorde.
| |
| # 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".<br />
| |
| | |
| | |
| → [[Toepassen_Relaties_VERA|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_ID_in_VERA|Gebruik van ID's in VERA]]
| |
|
| |
|
| == Overige wijzigingen/RFC in VERA 4.0 ==
| | Als je voor het eerst met de VERA 4 koppelingen aan de slag gaat staat in de [[VERA_releasenotes_4.0|Releasenotes van VERA 4.0]] een uitgebreide toelichting op de toepassing van de koppelingen. |
| 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.
| |
|
| |
|
| | == Overige wijzigingen/RFC in VERA 4.1 == |
| | Wij leveren regelmatig patches op met daarin uitwerkingen van RFC's, bugfixes en verbeteringen. |
| | In VERA 4.1 zitten alle patches die zijn uitgebracht sinds VERA 4.0. |
| | [https://github.com/Aedes-datastandaarden/vera-openapi/releases Releasenotes op onze Github site] |
|
| |
|
| == Met dank aan == | | == 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: | | Vera 4.1 is tot stand gekomen door de RFC's en vragen van een aantal leveranciers en corporaties: |
|
| |
|
| {| class="table" style="width:800px;" | | {| class="table" style="width:800px;" |
| |- | | |- |
| ! width="25%" | Projectontwikkeling | | ! Corporaties !! Leveranciers |
| * Batavia Groep | | |- |
| * CORA | | | |
| * De Alliantie | | * Waterweg wonen |
| * De Key | | * Woonstad Rotterdam |
| | * ProWonen |
| | * Woonstede |
| | * Mooiland |
| | * Stichting DUWO |
| | * Habion |
| | * Cascade |
| | * Wooninvest |
| | * Woonbedrijf |
| | * Woonwenz |
| | || |
| | * Cegeka |
| | * NCCW |
| | * ZIG Websoftware |
| | * WoningNet |
| * Itris | | * Itris |
| * Novius
| |
| * Portaal
| |
| * Skarp
| |
| * IJKX Interim & Advies
| |
| * Vestia
| |
|
| |
| !! width="25%" | Klantportalen
| |
| * Aareon
| |
| * Cegeka-DSA
| |
| * Databalk.nu
| |
| * Datarotonde
| |
| * Embrace Cloud | | * Embrace Cloud |
| * Skarp
| |
| * SWEMP
| |
| * WoningNet
| |
| * ZIG Websoftware
| |
|
| |
| !! width="25%" | REST
| |
| * Aareon | | * Aareon |
| * Cegeka-DSA
| |
| * Databalk.nu
| |
| * Datarotonde
| |
| * Itris
| |
| * Hercules Software
| |
| * Ketenstandaard
| |
| * NCCW
| |
| * Skarp
| |
| * VNG-Realisatie
| |
| * WoningNet
| |
| * ZIG Websoftware
| |
|
| |
| !! width="25%" | 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
| |
|
| |
| |} | | |} |
|
| |
|
| {{Page end CORA+VERA}}
| | [[Categorie:VERA-standaard]] |
| [[Categorie:Publiceren]] | | [[Categorie:Publiceren]] |
