I´m using wM 6.5.
I´trying to send pdf attachment converted to hex string inside a SOAP message using SOAP RPC protocol. I´m able to send hex stings not longer than 12.000 chars without problem (I receive SOAP status 0).
For longer strings, service pub.client:soapRPC fails with following error:
java.lang.reflect.InvocationTargetException: StackOverflowError
In wM Advantage knowledge base I found a tip that problem might be caused by using external JVM (not the JVM included in wM product) which might have limited strength JCE. I got confirmation from our admins that this is not our case.
I tried also to avoid hex string by using base64Binary, which was working fine in wM but our external service provider was not able to accept it.
What is the data type you are using to hold your PDF? Does the service provider only offer RPC / Encoded style web services? Can you prepare the XML message manually (pub.xml:documentToXMLString) and send using pub.client:http rather than pub.client:soapRPC?
I hold the pdf as bytes object, then convert to hexBinary or base64Binary string.
I tried to send manually created SOAP request using pub.client:http and I got the same StackOverflowError.
Now I think we may have a working solution, which is: convert the pdf (bytes) to base64Binary string and send it as string with max length 1.000.000. My pdf´s will not exceed this length (normally base64 encoded pdf´s have around 80.000). I tested strings with length almost 1.000.000 without a problem. If you see any danger in this solution, please let me know, otherwise I´ll use it.
Strange. Is the pub.client:http is returning the StackOverflowError or is that coming back from the service provider? I thought they could not accept base64Binary? Ask them whether they plan to support SOAP with Attachments (SwA) or MTOM in the future for this functionality.
It was wM pub.client:http service, which failed with the error. (I don´t have connection from dev. env. to the web service url, only from test env. On both I´m getting the same error)
Thay cannot accept xsd:base64Binary data type, but if I´ll send it as xsd:string, which contains base64 encoded data, they´ll implement a service to decode it.
Just out of curiorsity, do you know what development tools / technology the service provider is using that won’t allow them to handle xsd:base64Binary?
This is (yet another) example of the interoperability issues of RPC / Encoded style web services and why they are not permitted by the WS-I Basic Profile.
Your service provider would be well-advised to offer a document / literal version of their service and to incorporate MTOM support in the future. Of course, you’d have to wait for IS 7.1 to use MTOM, but we’re talking future direction here.
they are using Websphere as web services framework and just found out that there is newer version, where the “base64 bug” is already fixed. So it looks like we will use the original solution and send the attachment as xsd: base64Binary data.