Green Screens, Web Enablement, and LANSA
June 7, 2017 Dan Burger
Although there are important lessons to be learned from history, from an IT perspective, building a better future makes more sense than admiring past achievements. Not that there’s anything wrong with hard-won success. But past success does not assure future success. An easy example is a green-screen app that doesn’t translate all that well to a Web environment. Some require more modification than others to be effective in a Web environment.
The transition from green screens to browser-based applications has caused more chins to be rubbed than a dull razor attack on five o’clock shadow. It’s also caused IBM i software vendors like LANSA to develop tools to make the job quicker and easier.
Tools designed to convert green screen apps to Web and mobile apps have been continually enhanced for many years so that more features and functionality can be included with less time and effort.
LANSA’s basic tool for taking on this task is called aXes. It released aXes version 4 at the COMMON Annual Meeting and Exposition last month. It’s a re-facing tool, which are sometimes referred to as screen scrapers. A lot of IBM i-oriented companies begin their modernization efforts with screen scraping. It simplifies the green screen to Web conversion process. It adds new functionality to existing applications and it improves business processes.
Web-enabling 5250 datastreams using aXes is accomplished using a set of customizable rules to define 5250 screen elements. For example, a rule could specify that function keys should be converted to push buttons and page keys converted to subfile scrollers. Programmers can enable, disable, edit, create, and remove rules based on user requirements. Rules can apply to all screens or restricted to rules to specific screens.
We’ve all heard the “lipstick on a pig” reference to screen scraping, also referred to as Web facing. The pig is that 5250 constrained application. It’s not a perfect fit for Web enablement. It works at a satisfactory level, but there are varying degrees of satisfaction.
David Brault, product manager at LANSA, points out RPG and COBOL programs that are 10 to 20 years old are architected completely different than Web or mobile apps. “The 5250 screen can be made to look modern, but it doesn’t behave modern,” he says. “It still is working with a multi-step process and made to look nice. It doesn’t feel nice in its operation though.”
The benefits of aXes are revealed in the enhancements provided to the end user and how easily the expanded capabilities can be delivered by the development staff regardless of their skill level in unfamiliar technologies built into the tool. That’s where an emphasis on process optimization adds productivity improvements and potential cost reductions. Now we’re talking more than painting pig lips.
One of the important enhancements to aXes v4 is a feature called WebQueue, which allows real time, two-way communication between an IBM i server and a browser.
WebQueue is based on Web Sockets technology and enables the server to send data and notifications to the browser without waiting for a request from the browser. Consider the workflow process of a lengthy job that collates information and ultimately prints a report. The typical scenario involves the person who initiated the job frequently interrupting his or her work to check the job status. WebQueue prompts the IBM i application to send a job completed notification. That notification can include a PDF copy of the report and/or a file that can be downloaded into Excel.
Coaxing existing applications–when recognized as valuable assets–to perform tasks that were not part of the original application is another “beyond lipstick” benefit. Sending emails, calling IBM i programs from a browser and printing from the browser are new capabilities added to aXes v4.
When existing applications can generate and send emails, employees can compose emails or merge data into predefined email templates, then send the emails without leaving the application. This feature allows the application to log and track emails related to a business activity. The capability to initiate print jobs from an aXes screen does not require coding it into the application.
Here’s a use example: An IBM i manufacturing system includes an application to build quotations. Sales people fill out the details of the quote, print and scan the quote to create a PDF, open their mail application, create an email, attach the PDF and then send the email. Compare that process with using an email quote template, merging the quote details into the template, adding the recipient’s name and comments, then sending the email without the sales person leaving the IBM i application.
Calling programs on the IBM i is another aXes v4 enhancement. Typically, Web applications running in a browser send requests for resources to the server and the server sends the resources back to the browser. The tool allows any Web application to directly call IBM i programs. Settings of ‘configuration objects’ that control secured access to IBM i programs can be controlled by the IBM i admin or an admin on the development staff. Web applications invoke a configuration object that calls the IBM i program, hiding the name of the called program and maintaining security.
LANSA provided an example of how this might work. Let’s say there’s an IBM i application that processes orders entered by data entry staff. Customers are using a Web app to place orders. Inserting orders from the Web application into the existing order processing is accomplished by calling a program on the server and sending it the order data from the Web application.
Printing documents from a browser is convenient because data can be accepted from spooled files, from CJS Query results, from an aXes screen, or from JavaScript. To do this, designers build document templates containing data placeholders and static items, such as lines, rectangles, and text, with control over the position of each item on a page. Documents can include a mix of portrait and landscape page orientations and developers can merge the data with a template to assemble a single- or multi-page document. Items can be grouped in a template and saved. Groups can be loaded dynamically as reusable components.
Although tooling that can simplify the process of creating Web and mobile apps without touching the underlying application is a benefit and often the first step in an application modernization project, there is a limit to working with a 5250 datastream.
“It usually doesn’t take too long after screen scraping to get a new business requirement that is not part of the 5250 datastream,” says LANSA’s President Steve Gapp. “That will require new logic, accessing data somewhere else on the system, or on a different server. That’s when you’ve gone beyond the constraints of the 5250 screen.”
Gapp says adding functionality beyond the 5250 capabilities is more common than it was just two years ago.
To go beyond screen scraping, LANSA has its RAMP products that combine aXes and VLS (Visual LANSA). That allows 5250 augmentation to become a composite application. Over time RPG components can be replaced using Visual LANSA to create an app that would run on IBM i as well as other platforms and in a cloud environment. Customers end up with a cross-platform capable app that runs on Web and can be run on mobile.
More details about aXes Version 4 and instructions on how to download a free trial of aXes can be found at www.axeslive.com.
RELATED STORIES
The App Dev World According To Gapp
Modernization Prioritization Based On Observation
LANSA Shows Off Responsive Design Capabilities
LANSA Delivers LongRange Support for Windows 10
LANSA Guides Mobile, Portal, Integration Project To Success
