[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: Receving data past back from a webservice
Sender: Scott Klement <klemscot@xxxxxxxxxxxx>
> Hi again - This is all very new to me. Would you mind going through
> example16? I think this is the example I'm going to try to follow.
> Like I said, I don't need to use SSL, so do I just comment that out? I
> would like to have the data passed back to the program for me to use.
> I need to be able to display that data back to a screen. Any other
> suggestions would be greatly appreciated. :)
Hehe... EXAMPLE16 is the most complex of all of the example programs.
Naturelly you'd pick that one :) But, I'll try to explain it.
EXAMPLE16 uses HTTPAPI's built-in support for the Expat XML parser. When
you built HTTPAPI, make sure you included support for Expat, otherwise you
won't be able to use it.
Follow these steps:
a) Make your own copy of EXAMPLE16 called "TEST" or something.
b) Remove the InitSSL() subprocedure and the spot in the mainline where it
is called.
c) All that's basically left at this point is the UpsTrackReq()
subprocedure.
d) In that subprocedure, the first two things are some very long EVAL
statements (though the actual name "EVAL" can be left-off in /FREE rpg)
these EVAL statements do nothing but put data into variables. (which
happens to be XML data, though you can do whatever you like) The end
result will be data in a variable called 'postData'
e) the HTTP_url_post_xml() subprocedure is called to send the postData
to UPS (who does require SSL.) You'll want to change the URL in the
http_url_post_xml() to point to your webservice.
f) Pass the address of the data you want to send in the 2nd parm. In
EXAMPLE16, I told it "two bytes later in memory that the address
of the postdata variable" The only reason I added 2 bytes is to
skip the "length" field that's atuomatically part of a VARYING
field in RPG.
g) The 3rd parm is the length of the data to send.
h) The fourth and fifth parms are call-back subprocedures. This is
actually code that you write in your program, and HTTPAPI calls those
subprocedures when it needs to.
The idea between these subprocedures is that HTTPAPI will parse the XML
document that's received automatically as it comes in off of the wire.
When it receives the start of an XML element, it'll call the
"StartOfElement" subprocedure. (I called it StartOfElement in EXAMPLE16,
though you can call it whatever you like) When it receives the end tag of
an XML element, it'll call the EndOFElement subprocedure.
To make things a bit more flexible, I decided to make it possible for
HTTPAPI to pass some of your data to these call-back routines. So, the
last parm that I used in EXAMPLE16 is the address of user data that will
be passed to each call-back routine. In this case, the "resp" data
structure will be passed to each call-back.
For more info on the parms that http_url_post_xml() accepts, check out the
comments in the HTTPAPI_H member. Just search for http_url_post_xml() and
you should find the comments.
So, when you run the http_url_post_xml() subprocedure, HTTPAPI will make a
request to the web server (while you wait) and hopefully get back an XML
document. That document will be parsed by EXPAT, and for each XML tag you
receive, it'll call your subprocedures.
In the StartOfElement subprocedure, again this is being called as the data
arrives over the wire, I get the 'resp' data structure as the first parm
(I decided to call it 'r' for brevity) and a few other parameters:
depth - how many levels deep we are in the XML document.
name - name of the element we're being called back for.
path - path to that element.
attrs - an array of points to the XML attributes.
The EndOFElement call-back will be passed those same parameters, PLUS, the
value of the text that was in-beteween the start & end tag.
Consider the following XML document:
<mydocument>
<shipto>
<name>Bob</name>
<address>
<addr1>123 Sesame St</addr1)
<city>New York</city>
<state>NY</state>
<zip>12345</zip>
</address>
</shipto>
<shipto>
<name>Bob's Uncle</name>
<address>
<addr1>321 Sesame St</addr1)
<city>New Jersey</city>
<state>NJ</state>
<zip>54321</zip>
</address>
</shipto>
</mydocument>
HTTPAPI will call your call-backs in the following order:
StartOfElement. depth=1,name='mydocument', path='/'
then
StartOfElement. depth=2,name='shipto', path='/mydocument'
then
StartOfElement. depth=3,name='name', path='/mydocument/shipto'
then
EndOfElement. depth=3,name='name', path='/mydocument/shipto',
value='Bob'
then
StartOfElement. depth=3,name='address', path='/mydocument/shipto'
then
StartOfElement. depth=4,name='addr1', path='/mydocument/shipto/address'
then
EndOfElement. depth=4,name='addr1', path='/mydocument/shipto/address'
value='123 Sesame St'
etc, etc.
And so on, throughout the document until it's parsed every single XML
element. What you'll want to do in your call-back routines is check
the values of 'name' and 'path' to find out what you're working with,
and save those values somewhere.
In the case of EXAMPLE16, the various attributes are saved into the 'resp'
data structure. In the StartOfElement subprocedure it moves on to the next
array element, as needed.
In the EndOfElement subprocedure, it assigns the values to the various
parts of the 'resp' data structure so that they'll be available when the
parsing is completed.
When the XML document is complete and all of the callbacks have been
called, http_url_post_xml() ends, returning control back to the
UpsTrackReq() subprocedure, which checks to make sure no errors occurred.
At that point, the resp data structure contains the response from UPS...
there's no code in there to show the result, you have to view it in debug
or add some code to show the results...
Hope that makes sense...
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------