Don, my take on this problem is this. You have two extremes, one is to rewrite the entire application (or the parts you need) using some "modern" language and make it a true web application of some sort and at the other end of the spectrum you can use something to interface to the existing RPG programs (or worse still, screen-scrape them) and re-present them in the browser. The problems with the first are obvious, massive investment, new skills required and a high chance of failure. The problems with the second are usually a poor user experience with web UIs that mimic screen screens without adding any value at all. We took what we think is a good compromise by using Stored Procedures as the way to expose applications as a web service, thus being able to give a proper rich web front end yet still being able to use the existing RPG etc. backend skills people have, at the expense of some rewriting and re-architecting.
We use our own simple middle-ware (it's open source and can be found here
https://bitbucket.org/fathert/webspi-java/src/master/) and then build Single Page Web apps using those. This means that you can write the back-end logic in almost any language, from pure SQL to RPG or whatever else SQL allows and, of course, you can also re-use logic you already have. Basically, you have to write and expose an API to your application using Stored Procedures, which are then used by the front end. There's quite a big caveat though when it comes to re-using existing logic because the stateless nature of web service calls means some significant changes in the way you think about your application. For example, simple subfile type programs have to be re-architected so that the web UI can request a page of data without having any previous knowledge of state. You also need to identify the user on each call using some kind of token system.
Our front-end is all written in Angular, but it of course be anything.
The advantage of this approach is that you can write all of the back end code using languages you are familiar with and reuse some of the code you already have while still being able to write a true web application (as opposed to some sort of 5250-scraped method). Also, having your application exposed as a web service like this means you can use the web service as the end-points for all sorts of other clients. The drawback is that there is no way to avoid rewriting and modifying parts of the application to work as web services in this way, the lack of state is one of the biggest problems I think when making the change to web services.
Tim.
________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Don Brown <DBrown@xxxxxxxxxx>
Sent: 03 October 2018 10:12
To: Web400@Midrange. Web400
Subject: [WEB400] Alternate UI to RPG
We have built a web portal to allow web integration for external clients
and this is using php with xmlservice and it is working very nicely.
Now we want to provide some of the internal functions currently only
available in 5250 green screen.
NOT looking for 3rd party solutions ... No vendors please.
The application is large and we are looking at the 80/20 rule. 20% of the
menu options are accessed 80% of the time.
My question/enquiry is to people that have been down this path - somewhat
regardless of whether they used PHP or nodeJS or Python or ???
Did you modify the existing RPG to enable input from either 5250
Interactive Green Screen AND Web or did you separate the screen logic to
new programs or how did you retain the investment in the existing program
logic.
Would be interested in any comments
Cheers
Don Brown
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7C17c4e23bc0da4fa89f3608d62908075c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636741511789802994&sdata=1Iu13sQrruZApAh2%2F11kC%2BbfkXAUM8EL1miTrwzJi60%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7C17c4e23bc0da4fa89f3608d62908075c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636741511789802994&sdata=usUe5jIGF0GAgQTFM%2B00XRX2%2BZqvnQkDrE88ABhAwHk%3D&reserved=0.
midrange.com
