[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: putting returned data into variable instead of file
Thanks for your time, Mike. It is true - the response is either 'SUCCESS' or 'FAIL' from our customer's service. I have asked several times but get no answer.
Funny you mentioned that Example - I had actually tried 'copying' some parts from Example 2, which is similar. Something in my imperfect knowledge of ILE biting my ankle - I never had data in retdata. In the interest of a deadline I wrote a file, read a file, and used the variable as needed. I will try to use this example again next time I need - so thanks again for your help.
Julie Nichols| Summit Group
Programmer/Analyst
1100 Circle 75 Pkwy., Suite 1200 | Atlanta, GA 30339-3081
Direct line: 770-303-0432 | julie.nichols@xxxxxxxxxxxx
Fax: 770-303-0408
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs
Sent: Thursday, July 19, 2012 5:03 PM
To: HTTPAPI and FTPAPI Projects
Subject: RE: putting returned data into variable instead of file
I would be surprised that the response was only SUCCESS or FAIL. Most likely it is bracketed by HTML or XML. If XML, I'd definitely look at using the standard logic with EXPAT to do that. But sometimes, it would be nice to just get the data someplace you can put your hands on it without the IFS...
The "old" EXAMPLE5 shows that being done. In case it is not available on the website, I copied the example below. I think you can figure out what is being done here, but from your standpoint, just before the mainline return you would scan retdata for SUCCESS and return an appropriate flag. If I recall correctly, this example could be used with a data space as well as a variable. Just a matter of changing INCOMING to write to the data space. This would allow for vary big downloads to a non-IFS location. Do note that retData and nextPos are global variables so that they are available in the INCOMING procedure and not initialized by the procedure. So, depending on how you call this program or loop for responses, you will want to initialize those variables. Along those lines...note that the data declared for 1024A is NOT the data for 8192A in the procedure.
*
* This performs the same example as EXAMPLE4, except that it
* uses the "raw" versio of http_url_post(). The advantage is
* that data is received directly into a variable in the program
* instead of writing it to the IFS.
*
*
H DFTACTGRP(*NO) ACTGRP(*NEW) BNDDIR('HTTPAPI')
D/copy qrpglesrc,httpapi_h
D incoming PR 10I 0
D descriptor 10I 0 value
D data 8192A options(*varsize)
D datalen 10I 0 value
D rc s 10I 0
D msg s 52A
D CRLF C CONST(x'0d25')
D data S 1024A
D tracknum S 20A inz('1Z12345E0390515214')
D retdata S 32766A
D retlen S 10I 0
D nextpos S 10I 0 inz(1)
c eval *inlr = *on
C* OOh, let's track a package with UPS!
C*
C* FOR A BETTER EXAMPLE OF UPS PACKAGE TRACKING, SEE EXAMPLE16
c eval data =
c '<?xml version="1.0"?>' + CRLF +
c '<TrackRequest xml:lang="en-US">' + CRLF+
c '<Request>' + CRLF +
c '<TransactionReference>' + CRLF +
c '<CustomerContext>Example 1</Customer'+
c 'Context>' + CRLF +
c '<XpciVersion>1.0001</XpciVersion>'+CRLF+
c '</TransactionReference>' +
c '<RequestAction>Track</RequestAction>'+
c CRLF +
c '<RequestOption>activity</Request' +
c 'Option>' + CRLF +
c '</Request>' + CRLF +
c '<TrackingNumber>' +
c %trim(tracknum) + '</TrackingNumber>'+
c CRLF + '</TrackRequest>' + CRLF
C** The only diff between using HTTPS and using HTTP is
C** the URL that we pass. It starts with 'https://'
c eval rc=http_url_post_raw(
c 'https://wwwcie.ups.com/ups.app' +
c '/xml/Track':
c %addr(data): %len(%trimr(data)):
c 1: %paddr('INCOMING'))
c if rc <> 1
c eval msg = http_error
c dsply msg
c return
c endif
C* convert the data we just received to EBCDIC
c if retlen > 1
c callp http_xlate(retlen: retdata: TO_EBCDIC)
c endif
C* now the returned data is in the 'retdata' string.
C* run this program in debug and display retdata.... you'll see...
c return
P*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P* this procedure will receive the raw data received from UPS
P*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P incoming B
D incoming PI 10I 0
D descriptor 10I 0 value
D data 8192A options(*varsize)
D datalen 10I 0 value
C* Make sure we don't overflow the string:
c eval retlen = (nextpos + datalen) - 1
c if retlen > %size(retdata)
c eval datalen=datalen-(retlen-%size(retdata))
c endif
C* If there is nothing to write, return THAT...
c if datalen < 1
c return 0
c endif
C* Here we add any data sent to the end of our 'retdata' string:
c eval %subst(retdata: nextpos) =
c %subst(data:1:datalen)
c eval nextpos = nextpos + datalen
c* We always return the amount of data that we wrote. Note
C* that if http-api sees that we didn't write as much data as
C* it sent us, it'll abort the process with an error message.
c return datalen
P E
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Nichols, Julie
Sent: Wednesday, July 18, 2012 1:45 PM
To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
Subject: putting returned data into variable instead of file
I am using http_url_post to communicate with a service that only replies with 'SUCCESS' or 'FAIL'. My post statement is:
eval rc = http_url_post(
'http://services.summitmg.com/OrderSer'
'vice/ClientServices/Ally/Order' +
'Trackingblah.aspx'
: myPointer
: dataSize
: '/tmp/testpost.html'
: HTTP_TIMEOUT
: HTTP_USERAGENT
: 'application/x-www-form-urlencoded' )
Is there a way to substitute a variable for the testpost file?
Julie Nichols| Summit Group
Programmer/Analyst
1100 Circle 75 Pkwy., Suite 1200 | Atlanta, GA 30339-3081 Direct line: 770-303-0432 | julie.nichols@xxxxxxxxxxxx<mailto:julie.nichols@xxxxxxxxxxxx>
Fax: 770-303-0408
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------