it-swarm.com.de

WSDL/SOAP-Test mit Soapui

Ich habe meine Webservices (wsdl/soap) mit soapui getestet. und ich habe die Fehler: http/log: Fehler 400 BAD REQUEST.

Was kann der fehler bitte mit meinem wsdl sein?

fehlerprotokoll :

un Jun 05 14:10:37 CEST 2011:ERROR:javax.wsdl.WSDLException: WSDLException (at /html): faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions'.
   javax.wsdl.WSDLException: WSDLException (at /html): faultCode=INVALID_WSDL: Expected element '{http://schemas.xmlsoap.org/wsdl/}definitions'.
    at com.ibm.wsdl.xml.WSDLReaderImpl.checkElementName(Unknown Source)
    at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
    at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
    at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
    at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
    at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
    at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
    at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlInterfaceDefinition.load(WsdlInterfaceDefinition.Java:48)
    at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlContext.loadDefinition(WsdlContext.Java:66)
    at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlContext.loadDefinition(WsdlContext.Java:30)
    at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext.cacheDefinition(AbstractDefinitionContext.Java:264)
    at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext.access$400(AbstractDefinitionContext.Java:44)
    at com.eviware.soapui.impl.support.definition.support.AbstractDefinitionContext$Loader.construct(AbstractDefinitionContext.Java:230)
    at com.eviware.soapui.support.swing.SwingWorkerDelegator.construct(SwingWorkerDelegator.Java:46)
    at com.eviware.soapui.support.swing.SwingWorker$2.run(SwingWorker.Java:140)
    at Java.lang.Thread.run(Thread.Java:637)
20
samir

definitions ist ein Wurzelelement von WSDL, es sieht also so aus, als würden Sie WSDL nicht laden.

Bearbeiten:

Ich habe es getestet und es sieht so aus, als ob das ganze Problem bei Ihrem Webserver liegt. Ihr Webserver gibt WSDL an den Browser zurück, jedoch nicht an ein Tool, da diese Tools sehr minimalistische HTTP-Anforderungen ohne viele HTTP-Header verwenden. Einer der fehlenden Header ist Accept. Sobald dieser Header nicht in der Anforderung enthalten ist, gibt der Server die Anforderung "HTTP 400 Bad" aus.

Der einfachste Weg, um fortzufahren, besteht darin, WSDL im Browser zu öffnen, die WSDL in einer Datei zu speichern und diese Datei von der URL in die soapUI anstelle der WSDL zu importieren.

35
Ladislav Mrnka

Sie können versuchen, das wsdl im Webbrowser zu öffnen und mit der Erweiterung .wsdl zu speichern. Und legen Sie die WSDL in SOAP UI-Projekt auf diese .wsdl-Datei fest. Dies funktioniert wirklich.

5
Juno123

Eine andere Möglichkeit ist, dass Sie am Ende Ihrer Service-URL? Wsdl für SoapUI ..__ hinzufügen müssen. Das hat mich gepackt, da ich an WCFClient gewöhnt bin, der es nicht brauchte.

4
Mike
  • Ja, stellen Sie zunächst sicher, dass Sie "? wsdl" zu Ihrem Link "http ......" hinzugefügt haben.
    • Das hat mein Problem jedoch nicht behoben. Ich musste ein neues WCF-Projekt von Anfang an erstellen und den Code manuell kopieren. Das hat es behoben. Viel Glück.

Und am wichtigsten !!!

Wenn Sie einen Namespace in Ihrem Code ändern, stellen Sie sicher, dass Sie ihn in der web.config ändern!

3

Beim Versuch, meine auf WSO2 ESB bereitgestellten Web-Services zu testen, war ich mit der gleichen Ausnahme konfrontiert. 

WSO2 generiert sowohl WSDL als auch WSDL2. Ich habe versucht, eine wsdl2-URL zu übergeben, und bekam die obige Ausnahme. Schnelles googeln zeigte mir, dass einer der Unterschiede zwischen wsdl1.1 und wsdl2.0 das 'definitions'-Element durch' description 'ersetzt. Ich fand auch heraus, dass SoapUI wsdl2 nicht unterstützt.

Daher bestand für die -Lösung die Verwendung von wsdl1 url anstelle von wsdl2. 

1
arghtype

Es ist möglich, dass Ihr Browser Ihren Webdienst über einen Proxy erreicht, und SoapUI ist nicht für die Verwendung dieses Proxy konfiguriert. Ich arbeite zum Beispiel in einer Unternehmensumgebung und während meine IE und FireFox auf externe Websites zugreifen können, kann meine SoapUI nur auf interne Webdienste zugreifen. 

Die einfache Lösung besteht darin, die WSDL einfach in einem Browser zu öffnen, in einer XML-Datei zu speichern und darauf Ihr SoapUI-Projekt zu stützen. Dies funktioniert nicht, wenn Ihre WSDL auf externe XSDs angewiesen ist, auf die sie jedoch nicht zugreifen kann.

0
Chris Thornton