¶ Releasenotes koppelingen suite versie 2019-2
Naar navigatie springenNaar zoeken springen
Deze release van de complete koppelvlakken suite bevat vrijwel geen nieuwe functionaliteit. Wel bevat deze release weer een belangrijke verbetering op het gebied van de beveiliging van alle koppelvlakken. Daarnaast zijn er een aantal problemen opgelost die zijn gemeld door onze klanten.
Om gebruik te maken van Koppelvlakken beheer en de koppelvlakken zelf in deze release dient u minimaal gebruik te maken van JOIN Zaak & Document versie 6.25. Lees voor de installatie of upgrade van koppelingen altijd de instructies in onze FAQ
¶ Delivered versions
In this March release (2019-2) the following new versions of the interfaces have been delivered. It is possible that a specific interface does not appear in the list of completed development actions. This is because a generic improvement has been made.
- JOIN Interface management (v2.6)
- StUF-BG (v2.11)
- StUF-ZKN (v2.17)
- StUF-LVO (v1.10)
- StUF-DCR (v1.6)
- MyGovernment Message Box (v1.8)
- CMIS (v1.2.8)
¶ Delivered development actions
Because more and more improvements are being made that are generic for all interfaces, from this release all developed development actions will be shown in 1 table.
| no. | part | Description |
|---|---|---|
| 93546 | Interfaces management | From now on you will be warned about a set Connect password that is not sufficiently complex |
| 96156 | Interfaces management | From now on it is possible to use a SQL server to replace the internally used SQLite database |
| 98745 | Interfaces management | Extra logging has been added to the ‘Cleanup tool’ |
| 97380 | Interfaces management | Fixed: Not all messages with an error response were marked red |
| 94751 | All links | Internally used web services are now more secure |
| 87392 | StUF-BG | Fixed: Search by house letter and house number addition from the postcode field now works correctly |
| 91125 | StUF-BG | Fixed: When using StUF-BG 2.04, the street name for a business reply number was displayed as ‘Post number’ instead of ‘Business number’ |
| 94376 | StUF-BG | From now on, marital status is no longer taken into account for the composition of a compound surname |
| 94377 | StUF-BG | From now on, the non-compound surname (the family name) can be stored separately |
| 97646 | StUF-BG | From now on, the key Receiving can also be used to process an incoming notification |
| 97963 | StUF-BG | Fixed: When failing to update tracking indication status, customer indication message was sent 5x |
| 97964 | StUF-BG | Fixed: The cleanup tool stopped sending tracking indication messages on an error response |
| 86730 | StUF-ZKN | In the JOIN chain, now only the file content is sent when it has been modified |
¶ Uitgelichte ontwikkelacties
Hieronder worden enkele ontwikkelacties verder uitgelicht.
93546 - U wordt vanaf nu gewaarschuwd voor een ingesteld Connect wachtwoord dat niet voldoende complex is
Bij het openen van een integratie kunt u vanaf nu de volgende melding tegenkomen:
.png)
De applicatie maakt u er hiermee graag op attent dat het geconfigureerde Connect wachtwoord niet voldoende complex is. Dit kan een veiligheidsrisico opleveren. Om dit probleem te verhelpen dient u in JOIN Beheer een nieuw, complex wachtwoord te kiezen. Ditzelfde wachtwoord configureert u vervolgens in de integratie. Indien u hulp nodig heeft bij deze aanpassing kunt u contact opnemen met onze support afdeling.
94376 - Vanaf nu wordt er geen rekening meer gehouden met de burgerlijke staat voor het samenstellen van een samengestelde achternaam
In deze versie wordt bij gebruik van BG 3.10 de achternaam bepaald op basis van de volgende logica:
- In eerste instantie wordt gekeken naar de waarde in het veld ‘geslachtsnaamAanschrijving’
- Indien dit veld niet beschikbaar is wordt de naam opgebouwd op basis van de velden ‘aanduidingNaamgebruik’, ‘geslachtsnaam’ en ‘geslachtsnaamPartner’ en de bijhorende voorvoegsels.
Er wordt niet meer gekeken naar de burgerlijke staat van de desbetreffende persoon
94377 - Vanaf nu kan de niet-samengestelde achternaam (de geslachtsnaam) separaat worden opgeslagen
Tot nu toe werd alleen de samengestelde achternaam van een persoon opgeslagen in JOIN. In deze versie kan daarnaast ook de originele geslachtsnaam en het bijhorende voorvoegsel worden opgeslagen in separate velden. In de toekomst kan deze informatie gebruikt worden voor aangesloten koppelvlakken zoals StUF-ZKN als hierin de originele geslachtsnaam in moet worden meegegeven. De volgende Connect properties worden hiervoor gebruikt:
| connect property | Description |
|---|---|
| FamilyName | Last name |
| FamilyNamePrefix | Prefix |
If you want to use this functionality, this can be set up by a technical consultant from Decos.
97646 - From now on also the key Receiving can be used to process an incoming notification
Until now, incoming notifications from the data warehouse could only be matched with a person registration in JOIN on the basis of the BSN or the key data management (keySend). However, most data warehouses also include the Receiving key that matches the JOIN database key. Because this is the most reliable information in this chain, an attempt will now be made to request the personal registration based on this key. If the keyReceiving is not present in the notification, the aforementioned 2 identifying data is used.
This change resolves the problem where JOIN places a tracking indication on a person from the national facility for whom no key data management is known at that time. Because the JOIN database key is sent when placing this tracking indication, a future mutation on this person can now be processed without any problems.