The year 2020. will be a year of modernization features that will be added to the Green Screens Proxy service. We have big plans for modernization including modernization for SCS spool files.
First feature to be available in the 1st quarter of 2020. is screen automatic modernization which will convert terminal screens into web responsive UI working out of the box with web browsers and our mobile application client.
This is short introduction into incoming automatic modernization engine and why it is so different from other solutions. In this part we will write specifically about terminal screen UI modernization and incoming features.
Introduction
There are several products that brings terminal modernization, and they can be categorized in following groups describing their technical issues.
Desktop based terminal
Bottom line is it is still just a telnet client with GUI layer on top of the screen no matter how fancy it might look. This opens classic questions. To name a few... Security - if no SSL is used, terminal flow is plain text. Installation and maintenance issues with large scale. Multiple OS support. Problems integrating with other web services. Lack of mobile support. No real Cloud support and enterprise grade security.
Web based terminal
Existing web based terminal products with modernization has two major problems. They are "heavy" - even 20 KB of data for terminal screen does not seem much, but take into account companies with hundreds or thousands of workstations.
Remote branches with slow Internet access (not all part of the world has optical Internet). This leads to slow responses and bad user experience.
Many solutions do not use modern web technologies as responsive design. Integration possibilities require technical knowledge for specific technologies. Bad support or performance for mobile or require a lot of mapping and use of custom UI editors. Closed code UI libraries tightly connected to in-house made editors.
Server-side generated UI
Server side might be used for web based and desktop-based clients, however server-side detection and rendering in both cases has performance issues, data sizes, uses internal closed technologies or old approaches. Update requires server restarts affecting user sessions. In some cases, requires DDS source or even rebuilding display files which complicates the process even more.
Client-side generated UI
For current state of existing products, the only client generated product that exist is desktop solution. For some time now, we are witnessing that Cloud orientation is slowly becoming a standard approach. Even IBM i is now available in major cloud providers as Amazon Cloud, Google Cloud and Microsoft Azure. Moving your products to cloud opens some new requirements and technical issues. Client based terminals are not the best solution for that, especially the ones with modernization.
Pricing
Many products pricing is based on a simple model - affordable pricing for standard terminal and additional pricing if you want modernization.
Next Generation Modernization
Green Screens Modernization engine use different approach with accent on flexibility and technology-agnostic approach.
Server part of the Green Screens Modernization engine is responsible for display file and screen structure detection while layout detection and rendering are on the front-end part (web technologies as CSS and JavaScript).
The process
The main process is simple. When the terminal screen is submitted, Green Screens Server will intercept response from IBM i server to detect display library, display name and display records used by the current user terminal session.
This information (very small amount of data <100 bytes) will be sent to the web or mobile terminal along terminal screen data. Web or mobile terminal client will check inside internal dynamic cache if screen definitions already exists. If not, a request will be made to the Green Screens Server for currently used display file records.
Data received is in standard web JSON format. Once data is forwarded to the UI library, the library internal engine will collect and group terminal screen data based on received JSON structure and then dynamically generate HTML template and inject into web based modernized UI.
The rendering process is done inside the browser and only a small amount of JSON data is occasionally transferred over the network keeping terminal sessions at average 700byte requests size. This is several times smaller amount of data than in other products. Classic terminal requires 2-4KB of data while classic web-based terminals require 30-70KB, modernization 50-100KB per single user request.
Technology agnostic
The Idea behind being technology-agnostic as its term indicate is being independent to any technology. Even we have our own web-based UI lib for terminal modernization, it can be easily replaced with any other technology not affecting web or mobile terminal or server-side code.
Modernization related data that comes from server is just a simple JSON describing fields on the screen, window and subfile positions if exists.
By removing UI rendering from server side, we are also removing UI technology dependency along removing additional performance requirements for detection and rendering keeping server-side light and fast and response latency low.
Flexibility
The Idea behind flexibility lays in JSON format. When you have screen data in JSON format (exported locally from terminal screen) and JSON data describing display structure, anything is possible.
Even we developed our own UI library with custom components and our own screen data collector and renderer, it is basically a simple JavaScript library using Bootstrap CSS and some JavaScript logic.
Creating your own or custom one gives you the possibility to use any web technology to generate and render beautiful UI interfaces completely independent of our Green Screens Server.
Dynamic screens
IBM i programs can use DSM (Dynamic Screen Manager API) to create a terminal image without DDS. Such screens can't be modernized automatically. However, only small amount of system screens uses this approach.
To handle such cases we use simple JSON definition mapping for detecting such screens.
Other features
Most of the terminal screens can be modernized automatically. However, there are very complex or non-standard designed terminal screens which are very hard to automate requiring manual adjustment. Mapping screen to static template is now easier than ever.
Received data for detected screen is unique to that screen. It contains system name, partition, display library, display name and record names used. Having that in mind, we can easily create a link in JSON mapping definition pointing to a web template. There is no need for manual screen data mapping anymore.
Compared to other solutions, our product does not have and probably won't have UI point and click editor simply as it is not required. Our technology is simple to understand. Automatically rendered template modified and saved to the server as custom template.
If Modernization 2.0 library is used, creating a custom template is very easy and simple, as this library contains custom self-rendering web tags: <gs-*> tags. With just a few HTML elements on the screen one can get great UI without need for more advanced web technology knowledge. Manual template editing allows you creativity, and very high level of customization.
Cost of modernization
Virtually, none. The Engine is included with the product as a standard feature without additional pricing. Our main goal is to provide a framework to work on with default replaceable functional elements. One can decide to choose default features or to replace default UI lib and its rendering engine with custom developed libraries.