Thanks Scott.
My XML will stay the same. It is "wrapped" in a SOAP message for the web
service. If I understand everything correctly, I should still be able to
use my same HTTP process that I am using now. The only difference is that I
will need to "wrap" the XML in a SOAP message, before sending it. When the
XML is returned, I will need to remove the SOAP message "wrapper", before I
can parse the XML. Is my assumption correct?
-----Original Message-----
From: Scott Klement
Sent: Tuesday, December 18, 2012 6:15 PM
To: RPG programming on the IBM i / System i
Subject: Re: HTTPAPI and Webservices
Hi Robert,
The big difference between the philosophy of HTTPAPI vs the IWS Client,
is that HTTPAPI is a general-purpose HTTP tool. Whereas IWS Client is
purely a SOAP client. It can only do SOAP, nothing else. (Though, IBM
is adding REST support, as I understand it -- but, same idea, then it'll
only do REST and SOAP, nothing else.)
There are pros and cons to this:
1) IWS makes it much easier to call web services because it knows all
about web services, and can do all of the work for you. You just pass
it parameters, and it figures out what to call, how to call it, what
data to pass it, how the data should be encoded, what to expect back,
and how to decode it, etc. It can do all of this because it's designed
for the specific task of SOAP (and eventually REST) web services.
2) HTTPAPI just transfers data over the HTTP protocol. This means that
it can do things that IWS cannot. It can download stuff from web sites.
It can post form data to web sites. It can call any sort of web service
(not just SOAP) and can support any feature those web services dream up,
etc.
But, as implied in #1, HTTPAPI does not do as much of the work for you.
You have to code your own XML, you have to parse your own XML, you have
to determine what data the web service is/isn't expecting, etc. You
code this stuff in your RPG program (or whatever language you use to
call HTTPAPI).
To put it more succinctly: in IWS, the limitations are what IBM decided
to support. With HTTPAPI, the limitations are what you are able to code
support for.
I understand that your application is changing from using a CGI
interface to some sort of web service tooling. I don't know exactly
what, if any, impact that has. I think you're perhaps thinking of CGI
as being synonymous with REST, and web services as being synonymous with
SOAP? But, that's not necessarily true. These days, when someone says
web service, they could mean REST just as likely as SOAP. In fact, I
think REST has probably become more popular than SOAP for new
applications -- or, at least, I've seen far fewer SOAP web services in
the past year or two than REST ones. And CGI has nothing to do with how
the service is called or how the data is sent. CGI is just how the HTTP
server invokes the program. CGI can do both REST and SOAP. Likewise,
other means (such as Java application servers, or Apache modules, or
FastCGI) can do both REST and SOAP.
The reason I'm telling you all that technical stuff about "CGI vs web
service" is because it's not at all clear to me how this affects the
caller. Will the format of the data change? What is the format of
your data now? You say you're sending an XML file -- is it formatted as
a SOAP message? Or are you just sending your own XML format (i.e. a POX
web service). How will the new web service differ from that?
But anyway, I'll stop rambling... :-)
Yes, HTTPAPI can POST a stream file using https. If you want to, for
example, send a STMF and then get back the result as a STMF and save it
to the IFS, you can do:
rc = http_post_stmf( '
https://example.com'
: '/mydir/file-to-send.xml'
: '/mydir/result-file.xml'
: HTTP_TIMEOUT
: *OMIT
: 'text/xml' );
This will send the IFS file named /mydir/file-to-send.xml to a URL using
the POST method, and get back it's response and save it to the IFS path
/mydir/result-file.xml
If you'd rather have HTTPAPI parse the respose XML instead of saving it
to a file, that can be done with a different API call. Or if you'd
rather store it in a variable, or dynamic memory with a pointer, that
can be done too. HTTPAPI is also able to send data from a variable or
pointer, instead of a file -- so there's many options available.
If you'd prefer to use IWS instead, it's probably worth noting that as
of IBM i 6.1 (if you're not on this release or newer, you REALLY should
be working on it...) RPG does support variables as long as 16mb. So the
field length shouldn't be a problem, shouldn't it?
Sorry for being so long-winded. I hope all of this helps you!
-SK
On 12/18/2012 4:08 PM, Robert J. Mullis wrote:
I currently have an application that transmits a large XML file from
the IFS to a CGI on a secured URL (HTTPS). The CGI then transmits
back another XML file that gets stored in the IFS and parsed. It
uses procedure HTTP_URL_Post_StmF in HTTPAPI developed by Scott
Klement. Well, this process is being changed from CGI to a web
service. I was looking into using the IWS tools on the system to
consume this web service, but I may have a problem with this
approach. The limitation on field size in an RPG program may present
a problem, because my XML files can exceed the limit and I would not
be able to load the complete XML into a character string to send to
the web service.
My question is two fold. First, is it possible to send the XML from
a file in the IFS to the web service using the HTTPAPI and the
secured URL (HTTPS)? Second, if so, does anyone have a sample
program demonstrating this? I have been searching, but haven’t found
one yet.
Thanks,
Robert J. Mullis
Wellington-Royce Corporation
midrange.com
