I'm attempting to connect to a vendor's webservice (Soap 1.1), but I get this error:
line -1: Validation of SOAP-Encoded messages not supported
The vendor's support person with whom I'm communicating is using the same tool (SoapUI v4, I've tried both v4 and v5, and we've confirmed we're using identical XML), but he has no trouble, and a Google search of the error message hasn't uncovered anything helpful. Does anyone have any thoughts what the problem could be? Perhaps a program setting?
<soapenv:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:web="http://webservice.uesas._321forms">
<soapenv:Header/>
<soapenv:Body>
<web:GetKey soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<Username xsi:type="xsd:string">[Username]</Username>
<Password xsi:type="xsd:string">[Password]</Password>
</web:GetKey>
</soapenv:Body>
</soapenv:Envelope>
Your settings are more strict than you expect/need:
Just open "File > Preferences",
then "Editor Settings",
and uncheck the "Abort on invalid requests".
(as by my SoapUI v5.3)
So you will not get the message "Cancelled request due to invalid content." any more.
Also see this defect in SoapUI: Cancelled request due to invalid content from year 2011.
Related
I'm trying to create a serviceProvider including permissions using the webservice API of WSO2IS 5.1.0
The API I'm using is the one you can find on https://docs.wso2.com/display/IS510/Identity+Application+Management+API
Simply creating a serviceProvider with the request below works fine.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://org.apache.axis2/xsd" xmlns:xsd1="http://model.common.application.identity.carbon.wso2.org/xsd">
<soapenv:Header/>
<soapenv:Body>
<xsd:createApplication>
<xsd:serviceProvider>
<xsd1:applicationName>APP_NAME</xsd1:applicationName>
<xsd1:description>My application name</xsd1:description>
</xsd:serviceProvider>
</xsd:createApplication>
Trying to create a serviceProvider with permissions with the request below fails with the message
Error while storing permissions for application APP_NAME
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://org.apache.axis2/xsd" xmlns:xsd1="http://model.common.application.identity.carbon.wso2.org/xsd">
<soapenv:Header/>
<soapenv:Body>
<xsd:createApplication>
<xsd:serviceProvider>
<xsd1:applicationName>APP_NAME</xsd1:applicationName>
<xsd1:description>My application name</xsd1:description>
<xsd1:permissionAndRoleConfig>
<xsd1:permissions>
<xsd1:value>permission1</xsd1:value>
</xsd1:permissions>
</xsd1:permissionAndRoleConfig>
</xsd:serviceProvider>
</xsd:createApplication>
I cannot find any further information in the logs and also the example request messages on the WSO2 documentation site are lacking any information.
Any help or suggestion is welcome
I am using WSO2 4.7.01 version. I am receiving xml response from esb whenever there is a success response. But sometimes I will receive a base64 encoded format response from esb whenever there is a soap:server or soap:client or customized error response is returned from application server. Even though I am isung Accept property to while sending the request I am getting the above said kind of response. How to handle or avoid this kind of response from esb.
for exampleL
<axis2ns65:binary xmlns:axis2ns65="http://ws.apache.org/commons/ns/payload">
PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz48c29hcDpFbnZlbG9wZSB4bW
xuczpzb2FwPSJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2VudmVsb3BlLyI+PHNvYXA6Qm9k
eT48cmVzcG9uc2U+PHN0YXR1c0NvZGU+R0xYMDAxNTI5PC9zdGF0dXNDb2RlPjxzdGF0dXNNZXNzYWdlPkludm
FsaWQgVmVoaWNsZSBJZHMgYXJlOjg1MDA4PC9zdGF0dXNNZXNzYWdlPjxzdGF0dXM+ZmFpbHVyZTwvc3RhdHVz
PjwvcmVzcG9uc2U+PC9zb2FwOkJvZHk+PC9zb2FwOkVudmVsb3BlPg==
</axis2ns65:binary>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><axis2ns182:binary xmlns:axis2ns182="http://ws.apache.org/commons/ns/payload">
</axis2ns182:binary>
</soapenv:Body>
</soapenv:Envelope>
Please try the following steps
Open {ESB_HOME}/repository/conf/axis2/axis2.xml
un-comment the following
<messageFormatter contentType="text/xml" class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageBuilder contentType="text/plain" class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
I believe I found bug in WSO2 ESB.
I defined proxy service for our customer.
With security turned off I always get expected result, but when I enable security (scenario 1 - UsernameToken), then I get error "SOAP Envelope can not have children other than SOAP Header and Body".
I'm able to reproduce this bug with 'echo' service.
Here is request:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:echo="http://echo.services.core.carbon.wso2.org">
<soap:Body>
<echo:echoString>
<in>ABC</in>
</echo:echoString>
</soap:Body>
</soap:Envelope>
Turning security off or adding <soap:Header /> element before <soap:Body> element provides expected response again.
I'm using WSO2 ESB version 4.8.1, SoapUI 5.0.0 as client.
The SOAP headers contain application specific information related to the SOAP message. They typically contain routing information, authentication information, transaction semantics etc.
If you removed <soapenv:Header/> SoapUI will not send your user name and password to rampart.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:echo="http://echo.services.core.carbon.wso2.org">
<soapenv:Header/>
<soapenv:Body>
<echo:echoString>
<!--Optional:-->
<in>ABC</in>
</echo:echoString>
</soapenv:Body>
</soapenv:Envelope>
So your error was return by org.apache.axiom.soap.SOAPProcessingException due to AxisEngine System error.
When your sending request to secured one header is must..
I have a SOAP request of this form:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:myqname="http://example.com/hello"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<myqname:MyRequest xmlns:myqname="http://example.com/hello">
...
</myqname:MyRequest>
</soapenv:Body>
</soapenv:Envelope>
If I ask SOAPUI to "Format XML" this request,
it removes the second declaration of myqname, so I get this:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:myqname="http://example.com/hello"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<myqname:MyRequest>
...
</myqname:MyRequest>
</soapenv:Body>
</soapenv:Envelope>
The original request works fine,
but the Application Servers fails with the modified request with this error:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>Unmarshalling Error: UndeclaredPrefix: Cannot resolve 'myqname:MyRequest' as a QName: the prefix 'myqname' is not declared.</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
According to the web services specification,
is it mandatory for the qname to be re-declared inside the soapenv:Body node?
Is this a SOAPUI bug, or an Application Server bug? or a misunderstanding from my part?
SOAPUI 4.0.1, WebLogic Server Version: 10.3.2.0
Edit: ups, even if using WebLogic application server, I was using the CXF web services framework. I posted the issue there. issues.apache.org/jira/browse/CXF-4026
So: SOAPUI 4.0.1, CXF 2.5.0
I'd describe it as a bug in the code that strips the SOAP envelope; it should preserve the namespace context yet it isn't doing so, and that's breaking the XML. I guess that's because it is doing the stripping by taking a substring rather than operating at the DOM element level (whether or not it's using DOM processing to do the stripping is beside the point). I'm not sure which component is doing that stripping because of the way these things can be nested, but I suspect it's WebLogic…
[EDIT]: I've checked the SOAP specification and it does not say that the contents of the body has to directly declare the namespace used (see §5.3.1), though it does say that it SHOULD be namespaced. Because of that, normal XML namespacing rules apply — the whole SOAP message is simply an XML document — and that would make WebLogic's behavior a bug.
I have a problem with the Web Service I recently developed.
The problem is about the Web Service response. More precisely sometimes the Web Service sends back the following response:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:GetConstants2Response soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://usermanagerwstest">
<GetConstants2Return xsi:type="ns2:CFComponentSkeleton" xmlns:ns2="http://rpc.xml.coldfusion"/>
</ns1:GetConstants2Response>
</soapenv:Body>
</soapenv:Envelope>
Instead the correct response (that sometimes shows up in an intermittent way) is reported below:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ns1:GetConstants2Response soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://usermanagerwstest">
<GetConstants2Return xsi:type="ns1:Constants2">
<BooleanTypeFalse xsi:type="xsd:string">0</BooleanTypeFalse>
<BooleanTypeTrue xsi:type="xsd:string">1</BooleanTypeTrue>
<GenderFemale xsi:type="xsd:string">F</GenderFemale>
<GenderMale xsi:type="xsd:string">M</GenderMale>
<LanguageEnglish xsi:type="xsd:string">inglese</LanguageEnglish>
<LanguageItalian xsi:type="xsd:string">italiano</LanguageItalian>
</GetConstants2Return>
</ns1:GetConstants2Response>
</soapenv:Body>
</soapenv:Envelope>
Where does the CFCComponentSkeleton comes from?
I thank everybody in advance.
It sounds like perhaps the method was missing. When you hit a CFC and don't pass a method, you get the descriptor - a HTML view of the CFC methods. When you do that with ?wsdl in the URL, it should send the WSDL back. But maybe something is getting in the way. Maybe check your web server logs and see if something odd was passed in the URL. Also look into adding some logging within the CFC as well.