I'm thinking more about the Java service part.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
-----Original Message-----
From: Richard Schoen
Sent: Monday, February 26, 2018 8:49 AM
To: web400@xxxxxxxxxxxx
Subject: Re: Express, React, Node.JS
Nice.
Don't suppose you have any samples of this in action I could use to work into a technical presentation.
I will change the names to protect the innocent.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
------------------------------
message: 3
date: Mon, 26 Feb 2018 09:48:05 +0000
from: Tim Fathers <X700-IX2J@xxxxxxxxxxx>
subject: Re: [WEB400] [EXTERNAL] Re: Express, React, Node.JS
...our solution is to have a thin Java layer running under Tomcat on the IBM i which exposes SQL stored procedures in a sort of RESTful way, so that you can execute them by POSTing to a URL like this:
http://myibmi-d:8080/webspi/sp/default/SP_QryMthInvSts<
http://ger400-d:8080/webspi/sp/default/W222_SP_QryMthInvSts> where (SP_QryMthInvSts is the stored procedure) with a JSON payload as the parameters: {"inputParms":{"YYYYMM_":201802,"STATUSFILTERS_":"!,W,U,N,D","PAGE_NUM_":1,"PAGE_SIZE_":20}}. The results sets are returned as a JSON object which always has the same structure regardless of which procedure was called. All of the business logic is written using SQL or RPG exposed as stored procedures which means people don't have to learn a new language or rewrite swathes of existing code in something new.
For the front-end we use Angular to create single-page web applications, which simply execute the stored procedures on the back-end and process the returned result sets to do their work.
Tim.
midrange.com
