Thanks Brad.

If your i is acting as a server and receiving requests, the IBM HTTP
server would be your best bet. Then use whatever you want on the back
end (RPG/COBOL, etC) to generate the response and send it. No
different than CGI programs.

Our i has IBM HTTP Server, but SysAdmin tells me that we don't have any applications where an external request initiates processing, other than our existing web site, which from what I understand initiates a sign-on through DataGate.
Looks like I'll need to investigate how that would be set up.

This would also allow the transport to be HTTPS and takes complexity
out of writing your own listeners.

As for th PDFs, it would be probably be better if you sent back in your
XML URLs for the PDF files that you are creating (on the fly I'm
guessing) so the client can simply make another request to the server
and have them served up. No need for you to "send" them in your
response unless you want to put them inside of your XML data.

The PDFs are created as part of the monthly bill generation. They're in the IFS ready to pass to the client. Are you suggesting that the customer's browser would then access the pdf on the IFS through a URL? If so, are there risks that the browser could then access other files?

Your idea is nothing new. It's done all the time on every type of

I suspected as much. Just hasn't been done here (or by me).
- Michael

On Mon, Jan 20, 2014 at 8:03 AM, Koester, Michael <mkoester@data->wrote:

Okay, I said we can do that; now I need to figure out how.
We are having a third party redesign our web site, which will be
hosted on a different server. The Bill Presentation and Payment
functions will interface with the database on the i, but I'd like to
keep the transactions minimal. I am anticipating the web site will
send a request to the i, and the i will dutifully respond by
constructing and sending an XML string with the data elements needed
for that customer's transaction. From the web site, the customer may
or may not commit a payment, or make a change to settings (such as
"yeah, don's send the paper bills" or "Here's my new bank account and
routing #", etc.). The web site would then send a transaction back
the i, which would get accepted and acknowledged (and for payments
send back a confirmation number). On the i , the payment transaction
would be batched for ACH transmission and everybody would be happy.
The web developers would code the script for the site navigation, and
would store no customer data beyond acc ount# and login
authentication. Everything else would be stored on our database, and
the communications between platforms would be restricted to those
transactions mentioned. Obviously, data security must be considered.

First question: What is an appropriate mechanism for an external
request for the xml string to be "heard" by the i, to initiate the
response? I still have no experience with data queues - is this the
time for me to explore that?

Second question: What is the preferred data transport between the
platforms to ensure necessary security? ODBC, Web services, FTP-API,

Third question: In addition to sending the xml structure of a couple
dozen data elements, would sending 6 pdf files (maybe 500 k each)
i to web server present any challenges or perceptible delays?

Other questions: (TBD - stand by.)

Our current web site was developed 7 years ago, using ASNA's Visual
RPG and DataGate products. Works nicely, but the business is looking
to have the web site managed by a real web designer, who would be
using WordPress and other website tools, and has no knowledge of, or
access to, our
in-house development tooling and database. In the existing system,
DataGate product handled all the cross-platform communications, but
may not be used in the new design.

All experience and ideas are appreciated.

Michael Koester

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page