× 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.



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.

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.

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

Brad
www.bvstools.com


On Mon, Jan 20, 2014 at 8:03 AM, Koester, Michael <mkoester@xxxxxxxxxxxxx>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 to 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, other?

Third question: In addition to sending the xml structure of a couple
dozen data elements, would sending 6 pdf files (maybe 500 k each) from 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, the
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
Programmer/Analyst
DataEast

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.