[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Buffer size?

Thanks for all your help Scott.

I took your earlier suggestion and double-dipped, i.e. I threw the soap message return out to a temp file (http_url_post_xml) and used the resulting file as input using http_parse_xml_stmf. 

There was a small glitch, in that the size of the value var to be written on the first step  exceeds 65535 bytes. I found an old posting of yours that answered the exact same problem using a pointer, and adjusting the parameters accordingly on the write operation , and it all works beautifully ! 

Now I have reams of tags to evaluate. Never thought I'd say I'm very happy about that....

Thanks a bunch !

-David 

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, February 06, 2012 10:42 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: Buffer size?

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
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------