Re: Re: Receving data past back from a webservice

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Sender: Scott Klement <klemscot@xxxxxxxxxxxx>


Hello,

> I am still unable to get the post to work.  This is what the user who
> wrote the webservice gave me as a guide to follow.  If I were to read
> from the IFS, how would I go about doing that?
[SNIP]
> GET /billingtest/service1.asmx/BillingTest?orderNumber=string HTTP/1.1
> Host: rtidev
[SNIP]

The following code downloads the result of this GET request to a file
in the IFS called /tmp/results.xml.  (Then leaves you to figure out what
to do with it)

    result = http_url_get('http://rtidev/billingtest/service1.asmx'
                         +'/BillingTest?orderNumber=string'
                         : '/tmp/results.xml');

    if (result <> 1);
        msg = http_error;
        // show msg to user somehow.
    endif;


To do the same thing with POST instead:

    mydata = 'orderNumber=string';

    result = http_url_POST('http://rtidev/billingtest/service1.asmx'
                         +'/billingTest'
                         : %addr(mydata)
                         : %len(%trimr(mydata))
                         : '/tmp/results.xml'
                         : HTTP_TIMEOUT
                         : HTTP_USERAGENT
                         : 'application/x-www-form-urlencoded');
    if (result <> 1);
        msg = http_error;
        // show msg to user somehow.
    endif;

I'd suggest trying the above examples first just to see that they work and
that you get your data, etc, as expected.

All those routines (http_url_get and http_url_post) do is make a request
to the web server, send your parameters, and then receive a response.
Whatever response they receive gets written to a file in the IFS as the
data comes off the wire.  Stream files in the IFS are ideal for this,
because data isn't received across a TCP/IP network in fixed-lengh
"records" it comes in random-sized chunks of data.  So, whatever data is
received gets written to the stream file in the IFS as it comes off the
wire.

If you would prefer that the data go to your program instead of a file in
the IFS, then HTTPAPI needs to have some way of getting it to your
program -- remember, the data will come in random sizes, and won't all
arrive at once, it comes in chunks.

So, what you do is tell HTTPAPI to call a routine in your program.  Each
time any data comes off the wite, HTTPAPI will call this routine. This is
done with the "raw" routines.  For example:

     D Received        s          32767A   varying
     D result          s             10I 0
     D msg             s             80A

        Received = '';

        result = http_url_get_raw('http://rtidev/billingtest/service1.asmx'
                             +'/BillingTest?orderNumber=string'
                             : 1
                             : %paddr(MyCallback));

        if (result <> 1);
            msg = http_error;
            // error occurred.  Show 'msg' to user so they know
            // it failed.
        endif;

This does exactly the same thing as http_url_get, except for the fact that
MyCallback is called each time data is received.  HTTPAPI will pass 3
parameters to this routine.

     descriptor = this is just a number, the same number that you
                  passed to http_url_get_raw() as the 2nd parm.
                  It doesn't matter what it is, it's just for your
                  convienience.

     data       = this is the data that was received off the wire.

     datalen    = length of the data received off the wire.

Only the first 'datalen' bytes of the 'data' parameter are valid.  The
rest should be ignored by your program.

HTTPAPI expects you to return the length of data that you processed from
this string, or a -1 if there's an error and you want to abort the
process.

So, if you write your subprocedure as follows, it'll simply add whatever
data you received to the end of the 'received' variable that I declared
above:

      P MyCallback      B
      D MyCallback      PI            10I 0
      D   descriptor                  10I 0 value
      D   data                      8192A   options(*varsize)
      D   datalen                     10I 0 value
       /free
          received = received + %subst(data:1:dataLen);
          return datalen;
       /end-free
      P                 E

The reason that http_url_get_raw() works this way is that it gives you a
lot of flexibility.  If you want to print the data on the screen as it's
received instead of storing it in a variable, you could do that.  If you
wanted to format it into fixed-length records and save it to a PF, you
could do that.  If you wanted to write it to a user space, you could do
that instead...  it's very flexible.

Now, when http_url_get_raw() is complete, and there were no errors, the
'received' variable will contain all of the data you got from the web
server.  Though, it will be in ASCII. I typically use either the iconv()
or QDCXLATE API to translate the data from ASCII to EBCDIC.

Again, look at the example programs... particularly EXAMPLE5 for a sample
of this.

Finally, there's the HTTP_url_get_xml() (and corresponding post_xml)
routines.  They're different from the HTTP_url_get_raw() (and post_raw)
routines because they attempt to interpret the XML data as it's received.

I already detailed those routines in my last message to you, so I won't
repeat it here.

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------