Re: Buffer size?

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

hi David,

You have an XML document that's inside a SOAP message.  They are not the 
same document, and SHOULD NOT parse together.

Background:

The idea behind SOAP is to hide the underlying complexity. 
Unfortunately, HTTPAPI doesn't do that for you...  but if you were to 
use SOAP tooling (such as WSDL2RPG, or the stuff available in PHP, Java, 
.NET, etc) then you would never see the SOAP message, you'd simply call 
a routine, like this (this is pseudo-code):

CALL getReportVersion ( 'input parm', 'output parm' );

The parameters, obviously, will vary with every web service you call. 
And they can be anything... numbers, strings, dates, times, whatever 
type of data you can think of can be passed as a parameter.

Under the covers (or, in plain sight if you're using HTTPAPI), the call 
has to be converted into an XML document.  So it'd send something like 
this (this is hypothetical, intended to give you the idea.)

<soap:Envelope>
   <soap:Body>
     <ns1:getReportVersionRequest>
        <getReportVersion>input parm</getReportVersion>
     </ns1:getReportVersionRequest>
   </soap:Body>
</soap:Envelope>

So that gets sent to the web service, which parses out the input 
parameter, and then creates a response and sends it back:

<soap:Envelope>
   <soap:Body>
     <ns1:getReportVersionResponse>
        <getReportVersionReturn>output parm</getReportVersionReturn>
     </ns1:getReportVersionResponse>
   </soap:Body>
</soap:Envelope>

Once again... and I hope this is clear... 'input parm' and 'output parm' 
can be anything.  Absolutely anything.  The tool has no idea what the 
data is or what it means... it's just data in an XML document.

So let's say you decided to send a piece of source code as an input parm 
(again, completely hypothetical):

CALL getReportVersion ( 'if x < 10 then', 'output parm' );

The input parm is 'if x < 10 then', which isn't executed or anything, 
it's just a string... you can pass any string you want.  The XML message 
would look like this:

<soap:Envelope>
   <soap:Body>
     <ns1:getReportVersionRequest>
        <getReportVersion>if x &lt; 10 then</getReportVersion>
     </ns1:getReportVersionRequest>
   </soap:Body>
</soap:Envelope>

Why did the < symbol get converted to &lt;?  Because it had to in order 
to put it into a SOAP message.  If it didn't, the < would look like part 
of an XML tag.  It's no problem, because the receiving program will 
parse the XML, and the &lt; will get converted back to the < symbol.

THAT's what's happening in your example.  The server is doing this:

CALL getReportVersion ( 'whatever', 'An XML Document, in a string' );

The output parameter is an XML document, but the SOAP message doesn't 
know or care that it's an XML document.  It's just a big character 
string. All of the tags are "escaped" so that they don't interfere with 
the SOAP message itself.

When you parse it (with Expat, or anything else) they'll be converted 
back into XML tags.  They won't be parsed for you -- just converted back 
into tags, so the parameter looks the same as it originally did when the 
caller passed it.

You can then save that data to disk, or you can load it into memory 
somewhere, and then parse it again (with Expat or XML-INTO or XML-SAX or 
whatever you prefer.) to extract the contents.




On 2/6/2012 11:22 AM, David Baugh wrote:
> Scott,
>
> As requested, please see the attached. I edited it for security purposes to replace any references to proprietary info with 'x' , otherwise it's a clean copy of what came out of http_url_post.
>
> The data being returned on the<Residential report>  tag (in RPG) is a long unformatted string.
>
> If I perform a lookup in SoapUI this tag is preceded by<![CDATA[<CONTEXT>  and followed by</CONTEXT>]. On the AS/400, all I see in my output file is:
>
> ...<getReportVersionReturn>&lt;CONTEXT&gt;&lt;RESIDENTIAL_REPORT..etc...
>
> Thanks,
>
> -David
>
>
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------