XML not accepted in webservice

[skunny]

I've created a simple progress webservice that has a LONGCHAR input parameter and sends it's response with the RETURN value.

I want to put XML in the LONGCHAR, but when I send XML into my webservice procedure it doesn't fill the LONGCHAR. I expected that I could send everything (plain character/XML etc.) through the LONGCHAR input parameter.

I've tested the webservice with the soapui tool by cutting/pasting a xml file in between the soap body.
This gives an empty input parameter on the webservice.
When I send in plain text, i'll receive that plain text as input.

Any thoughts why the XML isn't accepted and how to solve the issue ?

 

[Xavi_qsoft]

Good Morning.

But get any error or simply input LongCHAR is empty?
Have you tried using a smaller input xml? Tell this but with longchar input does not allow a big inputs, in this case big xml.
Variables longchar have a limit size.

 

[skunny]

It just accepts the request without any error.
The used XML is a small document with a few elements.

I noticed with testing that it accepts plain text, so I think the problem had something to do
with the fact that I want to receive an unknown XML file in the longchar variable and progress only
accepts plain text.

Strange thing is that it all works from within Progress. I can call the webservice from within progress and send a longchar filled with XML to the procedure. This arrives without any problem. If I export the same XML document to a 3rd party tool called SoapUI and call the webservice it doesn't receive any data in the longchar input variable.

Maybe progress add some extra info to it's longchar variable or converts it to some kind of format ?!?

 

[rstanciu]

SoapUI is a java application using a String I think, the String is also limited as a Progress CHAR.

 

[AndrewSmith]

Hi there,

I don't think this is caused by a string or char limit.

I hit this problem a few weeks ago when prototyping an XML-consuming webservice from SoapUI. Because SOAP is XML, sending a node value which is itself XML can cause all sorts of structural problems for the target parser. So the usual way of handling it is to wrap the XML node value up in a CDATA section. In this way, the contained XML will be ignored by the XML parser and treated as raw text.

In my case, I had the following in the test step in SoapUI:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:messageHandler:messageHandler">
<soapenv:Header/>
<soapenv:Body>
<urn:messageHandler>
<urn:ipMessageParams><![CDATA[<?xml version="1.0"?>
<ttParam><ttParamRow><paramName>dataId</paramName><paramValue></paramValue></ttParamRow></ttParam>
]]></urn:ipMessageParams>
</urn:messageHandler>
</soapenv:Body>
</soapenv:Envelope>

And I changed it to this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:messageHandler:messageHandler">
<soapenv:Header/>
<soapenv:Body>
<urn:messageHandler>
<urn:ipMessageParams>
<ttParam><ttParamRow><paramName>dataId</paramName><paramValue></paramValue></ttParamRow></ttParam>
</urn:ipMessageParams>
</urn:messageHandler>
</soapenv:Body>
</soapenv:Envelope>

CDATA sections are a bit strange in their format, but that's to make them distinct from "regular" XML structures. They start with...

<![CDATA[

...and end with...

]]>

Give that a go in SoapUI and see if it helps! Googling CDATA will give you a lot of extra info as well.

Side note- this kind of thing is usually handled for you by the technology being used. Before using SoapUI, we were just calling our Progress-based Webservice (via WSA) from .NET clients, and it was all being done for us. When you get down to a "raw" tool like SoapUI, these things come out of the woodwork.

Regards,

Andy.