Robert,
U just create the xml payload.
HTTPAPI provides the APIs to transmit an xml payload as an HTTP POST request: doesn't care what's in it or whether it is in fact an xml payload that you wrapped in a soap envelope.
HTTPAPI returns back to u the response: doesn't really care what's in it, maybe it's an HTML document saying the server is down, maybe it's the expected xml soap envelope containing the response payload.
Removing the soap envelope before parsing makes little sense since the xml response payload can be parsed out directly from within the soap body (after all, it is just xml)
Plus, Scott has already provided for optional parameters on the request API that will parse the xml for u using the Expat parser he has cleverly built-in.
All u do is specify procedure names for StartOfElement and EndOfElement, which u define in your program that calls the HTTPAPI API, and the API will automatically call back to run these procedures as it automatically parses the entire xml response for u.
It's all pretty easy really.
Peter
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Robert J. Mullis
Sent: Friday, 21 December 2012 6:53 a.m.
To: RPG programming on the IBM i / System i
Subject: Re: HTTPAPI and Webservices
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
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
#####################################################################################
This correspondence is for the named person's use only. It may contain confidential
or legally privileged information, or both. No confidentiality or privilege is waived
or lost by any mistransmission. If you receive this correspondence in error, please
immediately delete it from your system and notify the sender. You must not disclose,
copy or rely on any part of this correspondence if you are not the intended recipient.
Any views expressed in this message are those of the individual sender, except where
the sender expressly, and with authority, states them to be the views of Veda.
If you need assistance, please contact Veda on either :-
Australia 1300-762-207 or New Zealand +64 9 367 6200
midrange.com
