× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.