Use Case: Web-Enabling Legacy Text-Based Software
MAE has built-in virtual terminals so legacy software that cannot be updated can display into a virtual terminal and then displayed to a web browser.
You have modernized your infrastructure, but you're being held back by dependence on legacy software or equpment that is not going away anytime soon:
All of these examples are problems because programs are hard - or impossible - to modify, so you must work with what you have. But you want them accessible via a web interface. Perhaps with a very different look.
How do you acess these legacy programs in real-time?
MAE has a number of capabilities for running legacy software and displaying it in real-time.
If your software was originally designed for the DEC VT100, ANSI-based or Heath-19 video terminal, MAE contains all the components you'll need to run your software and display it interactively in a web browser.
If your software was designed for a different text-based video terminal, then you can engage HanoverSoft Professional Services to add support for your terminal to TermGW, which is responsible for faithfully rendering your virtual terminal.
If your software was designed for a graphics-based terminal, then you can engage HanoverSoft Professional Services to modify TermGW for your graphics terminal. HanoverSoft had a similar project for an X Windows-based portability layer that displayed graphics and responded to mouse and keyboard inputs.
If your software was not originally designed for a terminal (so it has no escape sequences to control cursor location, text color, etc), MAE contains components for you to run your software, receive program output, and send program input. To complete the solution, you will need to develop a MAE component that processes the received program output and determines what program input to send. To output to a web browser, you can choose to keep a text-based interface (and perhaps use TermGW to handle web page details) or you can use MAE's single page app (SPA) support libraries. Aside from a few HTML assets (one for your SPA layout and others for filling in detail in the page plus images), you can draw on MAE's UserDevice class for screen updates and UI interaction; to render generated images, use MAE's Image class.
Does this solution look like a fit for your organization? Reach out to HanoverSoft at +1 (919) 270-6712 or info@hanoversoft.net to discuss.
When you need to run software to capture its output and/or send it it input, you need to configure IoGW to manage it as a resource. If the program requires a terminal, the configure it as a ptty, otherwise configure it as a pipe. If your command is /usr/bin/reportgen with parameters "-r 500" and you want to configure the resource name to Report500, then use tioreg like this:
tioreg -add Report500 pipe:/?exec=/usr/bin/reportgen+-r+500
for a pipe or
tioreg -add Report500 ptty:/?exec=/usr/bin/reportgen+-r+500
for a ptty. If your ptty program outputs terminal escape sequences based upon the TERM environment variable, you can set that for vt100 using
tioreg -add Report500 ptty:/?exec=/usr/bin/reportgen+-r+500&TERM=vt100
If you're also using TermGW, you'll need to tell it to expect vt100 escape codes, either via MaeTerm configuration or TermAPI::setTerminalType().
Regardless of the details of running your program, your program is now available to run. By simply opening the Report500 resource, the program will start running and its output will be captured to the input stream.
Once your program is running as an IoGW resource, you can configure MaeTerm to display it to a virtual terminal, which can be readily rendered to a user's browser. If you are managing multiple software programs, you may want to group them in MaeTerm on different channels; then channel name appears in the URL, which can be handy for referring web pages. Presuming a simple configuration here for one program, configure MaeTerm parameters using these commands for VT100:
tpset maeterm termtype=vt100
tpset maeterm userstart.resname=Report500
tpset maeterm userstart.region=terminal
That last command specifies that the terminal will be rendered in the /usr/mae/html/maeterm.html single page app at the terminal tag. If you have more than one command available for the user to run, you can setup an Action menu, such as:
tpset maeterm actions=Run Report 500
tpset maeterm "action.Run Report 500=Report500"
which will create a menu called "Action" with one sub-menu called "Run Report 500". When selected by the user, the Report500 resource will be opened and directed to TermGW, which will display and update the terminal inside <div id='terminal' > </div > in maeterm.html. When the user types text to that terminal, the text will be relayed to resource Report500, which becomes input to your running program. As the program reacts with more output, that output will be relayed to the terminal in the user's browser.
Alternative to using the tpset command as above, you can update the /usr/mae/conf/commhub.ini file (which is only read when MAE initially starts) with this equivalent:
termtype=vt100
userstart.resname=Report500
userstart.region=terminal
actions=Run Report 500
action.Run Report 500=Report500
After configuring MaeTerm, you'll need to restart it to accept the new parameters:
trestart maeterm
To view the virtual terminal, point the browser to the URL:
http://mae.appsite.com/maeterm
Access to MAE through the web interface requires a login. The default login screen is served by UserGW from /usr/mae/html/pub/login.html, which should be customized per your site. The user must successfully authenticate before advancing to maeterm.
Authorized users are maintained in the MAE User database table. Manipulate that using tuser. To add user Jan Smith with e-mail jan@abc.com and password changeme, use
tuser add -n "Jan Smith" -e jan@abc.com -p changeme
(Note that the password is encrypted in the database table.)
If your users will only be accessing maeterm, you can make it the default app that displays when the user logs in using
tpset usergw firstapp=maeterm