Project

Profile

Help

Maintenance: Planio will be observing a scheduled maintenance window this Sunday, November 10, 2024 from 20:00 UTC until 21:00 UTC to perform important network maintenance in our primary data center. Your Planio account will be unavailable for a few minutes during this maintenance window.

ERR #488357

closed

Support #488350: Compliancy testsets ZDS 1.2

Toewijzing aan endpoint type niet consequent voor asynchrone vrije berichten

Added by Frank Samwel almost 8 years ago. Updated over 7 years ago.

Status:
Gesloten
Priority:
Normal
Assignee:
Frank Samwel
Category:
opgenomen in patch
Sprint/Milestone:
Start date:
12/19/2016
Due date:
% Done:

0%

Estimated time:
Behandeld in overleg:

Description

voegbesluitToe_Di01 valt onder SOAPVrijeBerichten, terwijl overdragenZaak_Di01 valt onder SOAPOntvangAsynchroon.

Naar mijn idee zou een asynchroon vrij bericht altijd onder hetzelfde endpoint type moeten vallen.


Files

#488357_zds0120.zip (24.9 KB) #488357_zds0120.zip Michiel Verhoef, 01/02/2017 12:36 PM
correcte-structuur-zds0120.zip (66.3 KB) correcte-structuur-zds0120.zip Robert Melskens, 01/05/2017 11:20 AM
wsdls.zip (7.34 KB) wsdls.zip Michiel Verhoef, 01/15/2017 05:09 PM
Actions #1

Updated by Michiel Verhoef almost 8 years ago

  • Status changed from Nieuw to In behandeling

Dit zijn twee verschillende WSDL's omdat het twee verschillende endpoints betreft:

De provider van de overdragenZaak_Di01 berichten is de ZSC, de zaak wordt nl. van het zaaksysteem overgedragen naar de TSA. Daarom staat dit bericht in de zds0120_ontvangAsynchroon_overdragen_zs-dms.wsdl .

De provider van voegBesluitToe_Di01 is het zaaksysteem, daarom staan die berichten in zds0120_vrijeBerichten_zs-dms.wsdl .

Waar nog wel een ei over gelegd zou kunnen worden is of de asynchrone vrije berichten (Di01) niet in dezelfde WSDL horen als de asynchrone kennisgevingen (afgeleid van ZakLk01) die nu in zds0120_ontvangAsynchroon_mutatie_zs-dms.wsdl staan.

Actions #2

Updated by Michiel Verhoef almost 8 years ago

  • Sprint/Milestone set to ZS-DMS 2.0

Het blijkt dat in een aantal koppelvlakken endpoints gedefinieerd zijn die niet correct zijn volgens de StUF protocol bindingen.
Dit kan niet in een patch opgelost worden maar zal meegenomen moeten worden in een 2.0 versie waarin ook StUF 4, RSGB 3.0, RGBZ 2.0 etc meegenomen worden.

Actions #3

Updated by Michiel Verhoef almost 8 years ago

  • Sprint/Milestone changed from ZS-DMS 2.0 to ZDS 1.2 Patch (2017 Q1)
Actions #4

Updated by Michiel Verhoef almost 8 years ago

Robert,
Zie discussie boven. In dit issue spelen meerdere zaken.
  1. Endpoint van de zds0120_vrijeBerichten_zs-dms.wsdl is niet correct genoemd. Was genoemd "VrijeBerichten", is hernoemd naar "VerwerkSynchroonVrijBericht"
  2. voegbesluitToe_Di01 (asynchroon bericht) is verplaatst naar zds0120_ontvangAsynchroon_mutatie_zs-dms.wsdl omdat zds0120_vrijeBerichten_zs-dms.wsdl immers de synchrone berichten bevat
  3. PortType van zds0120_ontvangAsynchroon_overdragen_zs-dms.wsdl is hernoemd naar "OntvangAsynchroon"

Ik heb bovenstaande issues opgelost in de bijgevoegde zipfile (waarbij ook de benodigde schema's van zds1.20 , StUF ZKN is gewoon de reguiliere zkn0310 folder).

Mijn vraag aan jou is: voldoen deze WSDL's nu aan de StUF standaard/StUF protocol bindingen? Als dat zo is kan ik ze laten testen door Frank op het STP.

Alvast bedankt!

Actions #5

Updated by Robert Melskens almost 8 years ago

Michiel,

Ik heb alle wsdl's nagekeken en ik heb daarin (op basis van de best practices) het volgende waargenomen:
  • In de naam van alle bestanden komt nog de term 'zs-dms' voor. Dit is nog een overerving van toen deze bestanden in de berichtcatalogus 'zs-dms' van zkn0310 stonden. Dit is dus niet correct. Hier zou eigenlijk de naam van de folder 'berichten' moeten komen te staan maar lees eerst maar de volgende opmerkingen;
  • Wat mij opvalt is dat je alle type messages in 1 schema hebt staan en dus niet onderverdeeld over meerdere schema's welke weer in diverse berichtcatalogi staan. Dit is wel de bedoeling;
  • Datzelfde geldt eigenlijk ook voor de complexTypes en simpleTypes in het schema 'zds0120_msg_stuf_zs-dms.xsd'. Verdeel deze over de te creĆ«ren berichtencatalogi;
  • De bestanden 'zds0120_ent_zs-dms.xsd' en 'zds0120_simpletypes_zs-dms.xsd' staan ook op de verkeerde plaats. De complexTypes en simpleTypes in deze bestanden zijn geen basis complexTypes en simpleTypes en horen dus ook niet in de folder 'entiteiten' thuis. Deze moeten over de diverse berichtencatalogi verspreid worden;
  • In de wsdl's onderken je een verschil in 'zds0120_ontvangAsynchroon_mutatie_zs-dms.wsdl' en 'zds0120_ontvangAsynchroon_overdragen_zs-dms.wsdl'. Even 'zs-dms' negerend zou dat moeten betekenen dat je ook beschikt over de berichtcatalogi 'mutatie' en 'overdragen' waarover de beide wsdl's verdeeld worden;
  • De best practices schrijven voor dat een wsdl met 'beantwoordVraag' in de naam in de berichtcatalogus 'vraagAntwoord' komen te staan. In de naam van dit bestand komt de naam van de berichtcatalogus NIET terug.
  • De wsdl 'zds0120_vrijeBerichten_zs-dms.wsdl' moet ook in een aparte berichtcatalogus komen te staan en 'zs-dms' moet dus vervangen worden door de naam van die catalogus.
  • Er dienen dus enkele berichtcatalogi aangemaakt te worden. Te weten 'vraagAntwoord', 'mutatie', 'overdragen' en een voor de vrijeberichten en de bestanden dienen daarover verspreid te worden. Ik heb dit even uitgewerkt in het bijgevoegde zip bestand. Het is echter alleen om je een beeld te geven van de folder structuur en welke bestanden je daarin aan zou kunnen treffen. Kijk dus niet naar de inhoud van die bestanden. Het verdelen van de verschillende complexTypes en simpleTypes over de verschillende bestanden laat ik aan jou over. Ook kan het zijn dat niet alle bestanden die ik nu heb aangemaakt ook daadwerkelijk moeten worden aangemaakt. Dat is natuurlijk afhankelijk van het feit of er complexTypes en/of simpleTypes voor de betreffende berichtcatalogus bestaan. Lees evt. ook even paragraaf 3.4 van de Best Practices over Services. Lees ook even paragraaf 5.3. Daarin staat dat de foldernaam 'zds0120' eigenlijk vervangen zou moeten worden door 'zkn0310_zds0120'. Het is echter een best practice dus je mag er van afwijken en persoonlijk zou ik dit op dit punt doen.
Inhoudelijk heb ik ook even naar de WSDL's gekeken en het volgende waargenomen. Sommige opmerkingen hebben mogelijk ook nog gevolgen voor de folderstructuur welk ik hierboven al heb doorlopen:
  • In allemaal is de appinfo incorrect. Deze geeft nl. aan dat deze onderdeel uitmaakt van de zkn0310 namespace terwijl ze juist onderdeel zijn van de zds0120 namespace. Ook de andere gegevens in de appinfo kloppen volgens mij niet. De patchversie is immers niet 25, de patchdatum moet aangepast worden aan de datum waarop je deze patch gaat publiceren en ik aangezien ik vermoed dat in sommige bestanden ook de xs:documentation zal worden aangepast moet ook de schemaversie worden aangepast.

Vanwege andere activiteiten heb ik de inhoudelijke check even stopgezet, deze wordt later vervolgd.

Actions #6

Updated by Robert Melskens almost 8 years ago

Ik vergat de zip file toe te voegen.

Actions #7

Updated by Frank Samwel almost 8 years ago

  • Status changed from Oplossing uitgewerkt to Toegewezen
  • Assignee changed from Robert Melskens to Michiel Verhoef

als ik het commentaar van Robert zo lees, ligt er actie nu bij Michiel. Status "Oplossing uitgewerkt" is niet meer terecht.

Actions #8

Updated by Robert Melskens almost 8 years ago

Michiel kan er idd mee aan de slag maar ik ben nog niet helemaal klaar met mijn review.

Overigens goed om te weten dat een aantal van de huidige best practice straks, als we de schema's gaan genereren, niet meer van toepassing zijn. Er wordt immers per koppelvlak maar 1 schema gegenereerd en ik neem aan dat we de inhoud van dat schema niet handmatig gaan spreiden over meerdere schema's.

Actions #9

Updated by Robert Melskens almost 8 years ago

  • Assignee changed from Michiel Verhoef to Robert Melskens

Ik heb er voor gekozen om de regels zoals deze in de protocolbindingen 03.02.03 m.b.t. de inhoud van WSDL's staan uit te drukken in een XSLT stylesheet. Het stylesheet is een aanvulling op een validatiecheck in XML-Spy.

Het achtereenvolgens:
  • valideren van de wsdl in XML-Spy;
  • corrigeren van de in XML-Spy gedetecteerde fouten;
  • het runnen van de stylesheet;
  • het corrigeren van de met het stylesheet gedetecteerde fouten.

moet meerdere malen doorlopen worden totdat alle fouten uit de wsdl zijn verwijderd.
Het kan zijn dat de wsdl nog uitgebreid en hier en daar gecorrigeerd moet worden.
Het stylesheet kun je vinden in de stufMaster in de folder 'tools\checkWSDLs'.

M.b.v. dit stylesheet heb ik iig in 2 WSDL's nog wat fouten waargenomen op het gebied van naamgeving.
Wellicht kunnen de WSDL's van andere koppelvlakken en sectormodellen ook een keer tegen dit stylesheet aangehouden worden.

Actions #10

Updated by Robert Melskens almost 8 years ago

  • Assignee changed from Robert Melskens to Michiel Verhoef
Actions #11

Updated by Michiel Verhoef almost 8 years ago

  • File wsdls.zip wsdls.zip added
  • Status changed from Toegewezen to Oplossing uitgewerkt
  • Assignee changed from Michiel Verhoef to Frank Samwel

Ik heb de WSDLs gecontroleerd met het XSL stylesheet en waar nodig aangepast. In ieder geval zitten er wat dat betreft nu geen fouten meer in de WSDL's.

De laatste wijzigingen in de WSD'L's en het msg XSD schema zitten in de bijgevoegde zipfile.

Van een eventuele herindeling ga ik een ander issue aanmaken. De vraag is of dat heel veel toevoegt, zeker omdat bij het genereren van koppelvlakken in de toekomst deze indeling ook niet gebruikt zal gaan worden.

Actions #12

Updated by Michiel Verhoef almost 8 years ago

  • Private changed from No to Yes
Actions #13

Updated by Michiel Verhoef almost 8 years ago

  • Private changed from Yes to No
Actions #14

Updated by Michiel Verhoef over 7 years ago

  • Category set to opgenomen in patch
Actions #15

Updated by Michiel Verhoef over 7 years ago

  • Tracker changed from Bug to ERR
Actions #16

Updated by Michiel Verhoef over 7 years ago

  • Status changed from Oplossing uitgewerkt to Gesloten

Also available in: Atom PDF