[gelöst] CC WebService: Fehler im XML-Dokument (1,62104)

Hallo Zusammen,

beim aufruf des WebService wird mir der Fehler "Fehler im XML-Dokument (1,62104)." zurückgegeben. Die zahlen sind die Koordinate der XML-Datei wo der Fehler steckt. Das ganze ist eine als WebService freigegebene Page. Gibt es eine Möglichkeit an die von Navision erzeugte XML-Datei zu kommen um den Fehler genauer zu analysieren? Ich vermute das hier an irgendeiner stelle ein unsichtbares Steuerzeichen sitzt welches die XML-Datei Invalide macht. Nach einem ersten blick über die Daten konnte ich leider nichts feststellen.

Zuletzt geändert von Agem am 7. Mai 2014 15:22, insgesamt 1-mal geändert.

Hallo,

Wie rufst du den Webservice auf?

Normalerweise, wenn du den Webservice über den Internet Explorer aufrufst, wird dort direkt auch das Problem angezeigt.

Kannst du zum Testen auch eine ganz einfache Page freigeben, ob es evtl. an den Berechtigungen liegt und nicht direkt an der Page.

Gruß
Aydin

Hi,

der eigentlich Aufruf kommt eigentlich von unserer Webseite. Zu testzwecken habe ich mir SoapUI installiert und konfiguriert. Das Funktioniert auch bei anderen Artikeln ohne Probleme und ich bekomme alle Daten geliefert. Nur ein Artikel will nicht so wie ich es gerne hätte.

Was meinst du mit Freigeben. Als Webservice?

Wie kann ich denn im Internet Explorer den Webservice aufrufen und die entsprechenden Parameter setzen?

Cheers, Agem!

Ich meine folgendes:
http://www.comporsys.de/dynamics-nav-bl ... al-teil-1/


Ich kenne den Webservice nur in Zusammenhang mit der 3-Tier Architektur.


Gruß
Aydin

Zu testzwecken habe ich mir SoapUI installiert und konfiguriert. Das Funktioniert auch bei anderen Artikeln ohne Probleme und ich bekomme alle Daten geliefert. Nur ein Artikel will nicht so wie ich es gerne hätte.

Aber dann ist es doch eigentlich klar. Da muß irgendwas in den Daten des Artikels sein, was nicht XML-konform ist (bspw. Sonderzeichen in der Beschreibung).

Hast du mal einen anderen Browser probiert? Ich hatte mal ein ähnliches Problem und da lag es an dem IE9. Wenn man das mit dem Mozilla aufgerufen hat, dann konnte er das XML trotzdem darstellen und so konnte ich dann identifizieren, woran es genau lag.

Verstehe ich das richtig, daß du auch im SoapUI kein verwertbares XML zurückbekommst? Sowas habe ich im SoapUI noch nie erlebt. Falls doch, dann solltest du das XML irgendwo gesondert speichern und mit einem entsprechenden Texteditor dir genau das 62104. Zeichen ansehen. Dort (oder in der näheren Umgebung) sollte dann das Problem zu finden sein.

Was füe eine Page ist das? Eine aus dem Standard und einfach nur als WS freigegeben oder speziell als Webservice entworfen?

Ich meine mich nämlich ganz dumpf zu erinnern, dass wir sowas auch mal hatten und da lage es einfach an der (Standard)Page in der irgendein nicht benötigtes Feld war. Seitdem nur noch Pages mit exakt den benötigten Felden.

Hallo Beisammen,

@Aydina81: Ein Direkter Aufruf im Browser ohne vorheriges übermitteln Liefert mir nur das Schemata, welches mir hierbei nicht weiter hilft. Oder gibt es eine Möglichkeit im Internet Explorer oder einem anderen Browser den Soap Request mit zu schicken?

@HattrickHorst: Recht hast du, es muss was an den Artikel-Daten sein, ich vermute ein nicht druckbares Zeichen welches man nicht auf anhieb sieht und das XML unkonform macht. SoapUI Klappt bei mir bestens. Wenn ich einen anderen Artikel abfrage ist das Ergebnis wie erwünscht. Frage ich jedoch den Fehlerhaften Artikel ab bekomme ich folgendes zurück:

Code:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Body>
      <ReadShopItemResponse xmlns="http://mac-its.com/Service4DiVA">
         <ReadShopItemResult>
            <Code>500</Code>
            <Type>ERROR</Type>
            <Text>Fehler im XML-Dokument (1,69828).</Text>
         </ReadShopItemResult>
      </ReadShopItemResponse>
   </soap:Body>
</soap:Envelope>

hier frage ich jedoch nicht direkt den Webservice auf Port 7047 an sondern über 80.

@vsnase: Leider handelt es sich hier um eine von unserem Partner erstellten Webservice, dieser ist auch schon einige Jahre im Einsatz.

vielen Dank für die Zahlreichen Comments.

Ich habe den Fehler gefunden!

Ich habe alle Informationen die mit ausgegeben werden: Artikeltext, Übersetzungen, Preiße etc. komplett Exportiert in Notepad++ und habe mir dort die nicht druckbaren Zeichen anzeigen lassen. Nach langer suche habe ich dann ein RS und FS gefunden (Record und File Seperator). Diese haben den Fehler verursacht.

Für alle die SoapUI auch nutzen wollen. Um das Problem mit der Authentisierung in den griff zu bekommen habe ich diese in SoapUI komplett deaktiviert. Über einen Browser auf den Webservice zugegriffen und Authorisiert. Anschließend den Entsprechenden Header (Authorization) aus dem Browser in SoapUI übertragen. Dann funktionierte auch der Soap Request.

Nochmals vielen Dank an alle die mir geholfen haben!

Ich habe alle Informationen die mit ausgegeben werden: Artikeltext, Übersetzungen, Preiße etc. komplett Exportiert in Notepad++ und habe mir dort die nicht druckbaren Zeichen anzeigen lassen. Nach langer suche habe ich dann ein RS und FS gefunden (Record und File Seperator). Diese haben den Fehler verursacht.

Das ist fies, weil es schwer zu finden ist. Schön, daß du es jetzt gefunden hast.

Für alle die SoapUI auch nutzen wollen. Um das Problem mit der Authentisierung in den griff zu bekommen habe ich diese in SoapUI komplett deaktiviert. Über einen Browser auf den Webservice zugegriffen und Authorisiert. Anschließend den Entsprechenden Header (Authorization) aus dem Browser in SoapUI übertragen. Dann funktionierte auch der Soap Request.

Es ist richtig, daß man eine offene Session braucht, wenn man das so macht. Allerdings kann man im SoapUI auch direkt die Zugangsdaten in den Eigenschaften angeben (so kann man bspw. auch andere Benutzer simulieren). Das wäre zumindest nach meinem Verständnis der Standardweg mit Windows Login und Middle Tier Web Service.