Vraag StUF BG

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

7 reacties / 0 nieuw
Raymond Bolder
Vraag StUF BG

Beste LS, Ik heb van een gemeente van ons een paar berichten gekregen om mee te testen. Als ik deze inlees in de webservice die ik heb opgebouwd krijg ik foutmeldingen dat het NPSLk01 niet voldoet. Ik heb vervolgens zelf een bericht gemaakt met stuf en kwam achter wat verschillen. Nu ben ik benieuwd of ik ergens een fout maak of dat het iets anders is. Wat ik heb moeten doen om het bericht van de gemeente wel in te kunnen lezen is het Type veranderen van npsLk01 naar NPS-LK01 Bij stuurgegevens de XMLNS op moeten nemen van StUFBG stuurgegevens xmlns="URL STUF BG" En ditzelfde bij het object dus ook de XMLNS van StufBG. object a:entiteittype="NPS" a:sleutelVerzendend="254753" xmlns:a="URL STUF" xmlns="URL STUF BG" Ik heb de sources opgebouwd aan de hand van Patch 19. Klopt dit of zit er ergens een fout in de sources die ik heb opgebouwd? Helaas kon ik de XML sources er niet bijzetten, het forum filtert deze eruit. Alvast bedankt voor de reacties.

Robert Melskens

Dag Raymond,

Ik heb voor het gemak de bewuste fragmenten, die ik eerder al van je had ontvangen, toch maar even in aparte bestandjes geplaatst in de bijgaande zip 'npsLk01_of_NPS-Lk01.zip'.

Daarvoor heb ik in de code van het bericht van de gemeente wel even wat elementen toe moeten voegen die jij waarschijnlijk eerder verwijderd hebt. Ik begrijp niet waarom je het eerste bericht niet kunt inlezen aangezien dat wel valide is. Het bericht dat je zelf hebt vervaardigd is helaas niet valide en ik vind het dan ook erg vreemd dat je dat juist wel in kunt lezen.

Ten eerste mag de naam van het root element nooit 'NPS-Lk01' zijn. In de schema's komt dat element helemaal niet voor.
Wel komt er in de schema's een complexType met die naam voor. Daar gaat dus ergens iets mis.
Ingaan op je andere wijzigingen heeft eigenlijk dan ook niet zo heel veel zin.

Ik ben zo vrij geweest om nog een alternatief bericht te maken waarin de namespace declaratie alleen op het root element plaatsvindt waardoor het bericht voor mensen wat prettiger leesbaar is (zie in het zip bestand 'alternatief-npsLk01.xml'). Daarin kun je door het gebruik van de prefixes ook net even wat beter zien tot welke namespace de verschillende elementen behoren.

Maak je overigens gebruik van een XML editor?

Groet,

Robert

Bijlage

npsLk01_of_NPS-Lk01.zip
Raymond Bolder

Beste Robert, Bedankt voor je reactie. Ik heb nog een keer de bestanden opnieuw gegenereerd die ik middels de XSD resolver krijg. Deze heb ik opnieuw ingeladen en het gaat weer fout. Ik zie in het gegenereerde bestand wel de NPS-LK01 staan. [System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.3038")] [System.SerializableAttribute()] [System.Diagnostics.DebuggerStepThroughAttribute()] [System.ComponentModel.DesignerCategoryAttribute("code")] [System.Xml.Serialization.XmlTypeAttribute(TypeName = "NPS-Lk01", Namespace = "http://www.egem.nl/StUF/sector/bg/0310")] public partial class NPSLk01 Ik heb voor het gemak de gegenereerde interface toegevoegd. Voor het maken van het eerder genoemde voorbeeld heb ik gebruik gemaakt van .NET code door een stufbericht aan te maken. Als aanvulling wat ik net had uitgezocht. Ik heb het type nu moeten veranderen van npsLk01 naar NPSLk01. En moest hierachter xmlns xmlns="StufBG url" het wordt dus NPSLk01 stuurgegevens Echter ik kreeg als voorbeeld npsLk01 xmlns="http://www.egem.nl/StUF/sector/bg/0310" stuurgegevens

Bijlage

OntvangAsynchroonInterfaces.zip
Robert Melskens

Ik kan je helaas niet helpen met de interface maar ik hoop dat iemand anders in de community je wel verder kan helpen.

Succes!

Raymond Bolder

Hoi Robert, Kun je mij misschien een idee geven voor het probleem van de naamsgeving. Als aanvulling wat ik net had uitgezocht. Na jouw laatste advies had ik een richting om te zoeken en kon ik t oplossen. Alvast bedankt. AANVULLING. Ik heb het type nu moeten veranderen van npsLk01 naar NPSLk01. En moest hierachter xmlns xmlns="StufBG url" het wordt dus NPSLk01 stuurgegevens Echter ik kreeg als voorbeeld npsLk01 xmlns="http://www.egem.nl/StUF/sector/bg/0310" stuurgegevens

Robert Melskens

Hoi Raymond,

Ik begrijp helaas niets van je toevoeging. Waar heb je precies het type gewijzigd naar NPSLk01 en wat bedoel je met

'En moest hierachter xmlns xmlns="StufBG url"'

Waar wordt het dus:

NPSLk01
stuurgegevens

en tenslotte wat voor voorbeeld bedoel je (is dit een gegenereerd stukje StUF bericht of iets anders)?

Graag wat verduidelijking.

Toch maar heel even vlug in de interface gekeken en daar zie ik in ieder geval:

       /// <remarks/>
        [System.Web.Services.WebMethodAttribute()]
        [System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://www.egem.nl/StUF/sector/bg/0310/npsLk01", Use=System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Bare)]
        [return: System.Xml.Serialization.XmlElementAttribute("Bv03Bericht", Namespace="http://www.egem.nl/StUF/StUF0301")]
        Bv03Bericht npsLk01([System.Xml.Serialization.XmlElementAttribute("npsLk01", Namespace="http://www.egem.nl/StUF/sector/bg/0310")] NPSLk01 npsLk011);

het zegt me allemaal niet veel maar in die laatste regel valt me op dat daar 'NPSLk01' bij staat. Waar de .Net code generator dat vandaan haalt weet ik niet. Wat is de functie van die laatste regel.

Raymond Bolder

Hallo Robert, Ik weet niet precies waar .NET dit vandaan haalt. Heb de bestanden gegenereerd met de tool die je eerder had aangegeven. Waar ik wel achter kwam is dat ik wijzigingen aan moest brengen als ik het voorbeeld bestand direct middels .NET aanbood. Bied het nu aan middels soapui aan mijn webservice en dan lijkt het goed te gaan. Denk dat hierin een verschil zit hoe je het aanbied. In ieder geval bedankt voor je hulp.