Hi Suren and the rest of great Midrangers!
We stood at this point when I entered our company almost 23 years ago. We were experimenting with a tool (webfacing) which didn't give us very satisfying results to put it mildly.
Since Apache was about the only open source software available on i5OS (?) back then and we had some experience with Net.Data, that was the route to go. Today we have an application with thousands of screens and about 100 customers with all kinds of optimizations on several versions of this application. It has in the basis a (not very strict) MVC architecture based on RPGLE, Net.Data and our home grown interface definition language. We do this with about 15 developers and a small R&D team providing the tools.
We do use persistent connections for most of our application screens. It increases performance and makes the exchange of data with our front-end much easier. We only have very basic data validation in the front-end, like checking numeric precision and scale.
We have been able to make 5 or 6 iterations of the look and feel of our views. When we started somewhere in 2004 or so we needed to develop for Internet Explorer 5 without any development tools at all 🙂
I can talk (or write) for hours about the issues we bumped into but want to highlight some of the choices that were key to our success.
*
Think about a generic way to pass data between your back-end and front-end. Json is fine, but also has it's limitations. Pick something that is flexible. We use small database files per program to pass data. The controller layer translates data from the HTTP request to the file and from the file to JSON data.
*
Think about the datatypes you may have never used in 5250, like links to documents, images, videos and so on. A conversion tool will not automatically add these possibilities to your toolbox.
*
Create an abstration layer for your views. Determine what type of elements you need and if and how they interact with each other. Generate view code (HTML or whatever) from that at (pre-)runtime. Angular maybe the way to go right now, but probably isn't in 10 years. We use wrapper functions for every single element on the view. This way we were able to modernize the look and feel without touching the view definitions. We also have added a lot of "view functionality" in the cause of the last two decades.
*
Make small modular programs (mostly one per screen)
*
Rethink your popups like search programs. In 5250 they were probably called from the RPG program, in a Web UI, you can't go that route.
*
Think bout the flexibility you need to organize the different views and programs. Do you determine the workflow for your customers or do you need to be able to change that easily?
*
Think about the way you want to have your different views interacting with each other. You don't want your users to enter an item number or customer number on every new screen, but you also don't want to hard code how parameters need to be passed. We use something we call a parameter pool for that.
*
Think about the way you want to grant or forbid your users access to certain parts of your application. Application access rules IMHO don't belong in the application it self and certainly not in the user interface.
*
Start with something small for your decision makers to see which way your company might go.
Good luck!
Kind regards,
Martijn van Breden
lead software architect
Hi All,
I’m looking for a tool to help modernize our IBMi application screens into
a GUI. Our plan is to use AngularJS for the front end, and we need to
convert all IBMi screen programs into APIs, which will be utilized for the
GUI screens. The majority of the subfiles in the IBMi applications
are single-page with data queue approach.
Additionally, the web services for these APIs can either be deployed on the
IBMi (via IWS, HTTP Server with CGI, etc.) or on a separate Windows server
(such as Java Web Services) — either approach will work for us.
If anyone has suggestions for the best tools available in the market to
help convert the IBMi screen programs into APIs, I would appreciate your
input.
Regards,
Suren
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
midrange.com
