RE: Web-to-i Communications questions

What you're describing is a typical SOAP webservice. There are several tools available to run a WebService on IBMi. I happen to use Tomcat with CXF or AXIS to support a very complex webservice on IBMi. There are others. Using a webservice tool eliminates the need for using data queues; the servers handle http request queuing.

Wordpress and many of the other web application tools are built with PHP. PHP "natively" talks to MySQL. There are tools that make the IBMi DB2 database behave like MySQL, particularly with remote applications.

You CAN talk directly from your web server to IBMi using DRDA. There are great java tools for doing DRDA with the JDBC tools that are part of JT400, there are also ODBC tools within the client access package. PHP can work directly with ODBC. JDBC and ODBC can be set up to use an encrypted connection.

IBMi 6.1 and 7.1 work very, very well as webservers for both webservices and traditional web applications. Lots of optimization has been done to make them so. You do need to be careful how you set up your TCP/IP stack on the IBMi; make sure to disable IPv6 if you haven't configured it properly, for example. Also be careful how you set up the work management for the JVM or whatever application is "waiting" to respond to HTTP requests.

If you are working in an environment where security and assured delivery is imperative, consider using message queuing software such as MQ Series (or whatever they call it now; Websphere MQ?) as a transport protocol. The webservice tools I work with have support for such mechanisms built-in.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Koester, Michael
Sent: Monday, January 20, 2014 8:04 AM
To: MIDRANGE-L@xxxxxxxxxxxx
Subject: Web-to-i Communications questions

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.