This is regarding a problem I am facing in calling service through SOAP-RPC protocol via HTTP transport.
The whole scenarion is as followes:
→ Our client team gave us two xsd files :
→ I created two Documents/Schema with the help of these xsd files.
→ Taking these documents as input & outputs I created a flow service processFlow
→ & then created a wsdl file from this flow service with
Protocol : SOAP-RPC ;
Transport : HTTP ;
→ Using this wsdl file client application is calling processFlow service hosted on the host given in wsdl file
→ & sending a SOAP
→ but here it is throwing exception like this :
Exception in thread “main” javax.xml.rpc.soap.SOAPFaultException: [ISS.0088.9134] Exception occurred while processing the body of the message at com.systinet.wasp.rpc.FaultDeserializationHelper.deserializeFault(FaultDeserializationHelper.java:106) at
com.systinet.wasp.rpc.WaspCallImpl.deserializeFault(WaspCallImpl.java:2208) at
com.systinet.wasp.rpc.WaspCallImpl.deserializeResponse(WaspCallImpl.java:1101) at
com.systinet.wasp.rpc.WaspCallImpl.invoke(WaspCallImpl.java:508) at com.systinet.wasp.rpc.WaspCallImpl.invoke(WaspCallImpl.java:450) at
com.systinet.wasp.client.ClientProxy._invoke(ClientProxy.java:456) at com.systinet.wasp.client.ClientProxy.invoke(ClientProxy.java:109) at
$Proxy61.processFlow(Unknown Source) at
com.gehc.WorkOutWSDL.EPDMPOC_ItemInfo_Pub_serviceServiceClient.main(EPDMPOC_ItemInfo_Pub_serviceServiceClient.java:79)
We are not able to resolve :
* Whether their client application is hitting my service or not?
Which application is throwing this exception webMethods service or client application?
Looks to me like the fault is occurring on the client side, failing in trying to deserialize one of the returned parameters.
There are several posts on this forum recommending that SOAP-RPC is to be avoided, primarily because of this type of interoperability issue.
You can review the session logs to see if the client is hitting IS. Look for the username that the client is using (hopefully they’re not using one of the built-in accounts like Administrator or something).
Would strongly recommend changing to use SOAP-MSG. There are threads on the forum that describe how to do so.
It may be that Systinet WASP is having trouble deserializing a Soap Fault. If so, capturing the soap response on the wire may show you the soap fault in XML form and lead to the root cause of the problem (a bug in IS). You can also review the IS error logs for exceptions.
I’ll second Rob’s recommendation to ditch SOAP-RPC.
HTH,
Mark
Hi
Actually I m facing problem in handling soap msg.
can u tell me what is the correct process to handle a soap Msg.
what I have done till now is…
–>I got XSD files from.
–>Using these XSD files I’ve generated two documents
–>Using these documents as input & output i created a flow service.
–>created a wsdl file from this flow service.
–>after this …I created a client application with the help of this wsdl file using SOAP-RPC protocol & HTTP transport.
→ now that client application is sending a soap msg using rpc processor. but here it is throwing the exception.
You might take a look at the wM documentation. It describes how to structure things to implement a SOAP-MSG service. You cannot, as you’ve discovered, process a SOAP-MSG with the RPC processor.
Thanks reamon,
but I m not trying to handle SOAP-MSG , I m trying to receive SOAP message from my client application. and now I have got the root cause of the problem.
actually it was throwing the exception because I was validating the message.
Now the problem is when I am generating a wsdl, it is adding some unwanted string to all of my fields(namwespace qualified)
For example:
if a field is appearing s " ns:OMAItem" in wM
in wsdl file & in SOAP message it is appearing as " ns_x003A_OMAItem ".
thats why target service is not able to validate the soap message.
can u think why it is happening so?
thanks
Ah, I see. I mistook your phrase of “SOAP msg” to mean you were trying to use SOAP-MSG. So you’re proceeding with using RPC despite the advice to use MSG instead?
That is indeed strange. It looks like the ‘:’ was encoded into hex for some reason–0x3A is the hex ASCII code for ‘:’. I don’t know what would cause the WSDL generator to do that.
Nothing that the existing WSDL generator does incorrectly would surprise me. It’s pretty much useless at this point after four years of no functional improvements.
Mark
thanks for the clue.
will it work if I rename all ns:fieldname to fieldname in the physical document which I had generated from XSDs?
what effect will it make in my whole application?
Hi,
I made the change as I was thinking to do:
1> I did rename all ns:fieldname to fieldname in the physical document (using as input) which I had generated from XSD.
& the WSDL I generates after it, puts this fieldname as _fieldname in wsdl file.
Though at last It works, can I remove this _ from _fieldname somehow?
2> Second, when I did the same with document which I am using as output for the service, it doesn’t work. It throws the exception:
Error while encoding RPC output.
Can I do something for these problems?
What version of IS are you using? That the wizard is adding underscores to the field names seems unusual.
Have you tried using SOAP-MSG? (SOAP-RPC should work–but as mentioned earlier, you really shouldn’t use it).
Hi Reamon…
I m using wM 6.5…& I tried to use SOAP-MSG protocol also but it is not working…
can u explain in a detail what is the difference b/w SOAP-RPC & SOAP-MSG?
I think because I m using xml namespace other then host server so it is not working with SOAP-MSG.
There are many messages and examples on that topic in this forum. In addition you should read the webMethods SOAP Developers Guide and webMethods Web Service Developers Guide to understand how Integration Server supports web services.
Mark