The Largest Repository of ColdFusion Knowledge in The World for More Than 12 Years

ColdFusion on Ulitzer

Subscribe to ColdFusion on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get ColdFusion on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


CFDJ Authors: AppDynamics Blog, Michael Kopp, Tad Anderson, Bob Gourley, Jayaram Krishnaswamy

Related Topics: ColdFusion on Ulitzer, XML Magazine

CFDJ: Article

Teamstudio Screensurfer

Teamstudio Screensurfer

Every developer will at some point have to integrate his or her work with a legacy system running on a mainframe platform. These projects tend to be both painful and challenging due in no small part to the limited information- sharing capabilities of outdated, albeit stable, systems. XML and Web services didn't exist when some of these applications were written. The concept of browser-based applications was years away. Green-screen applications were the norm and dinosaurs ruled the earth (just kidding about that last part).

Teamstudio has a product called Screensurfer that brings screen-based applications to the browser in HTML format quickly and painlessly. They do this through a 3270/5250 Web gateway controlled by easily modified ASCII text files. Using a series of wizards, a developer can quickly generate the necessary files and have a terminal session open and operational in the browser within minutes. Teamstudio calls this their "Screen to HTML" feature.

"Screen scraping" applications (such as Screensurfer) are not new. By extracting the data from the existing user interface, they enable a company to utilize these systems in new ways and repurpose the data for other applications. Screensurfer's ability to move screen-based applications to the browser also removes the requirement that system users have terminal emulation software installed on their desktop. This allows the application to be accessed by many more people than traditionally possible.

We are also given the option of running Screensurfer in a "co-server" environment. This is where Screensurfer sits between your application server of choice and the mainframe. ColdFusion is supported through a provided CFX tag. A COM object is available as well for those who are running ASP/VB code. Additional application servers (PHP, JSP, .NET) are supported through XML-over-HTTP calls. In a co-server environment, the screen-scraped data is returned in a useful format (usually a recordset) to the calling application server for processing and HTML markup.

Teamstudio packages an IDE tool with Screensurfer called Teamstudio Express. This IDE can be used to modify the ASCII files mentioned above, which contain HTML and specialized markup called Surferscript (we will discuss this momentarily) that are used to control the output of the scraped screen data. Teamstudio Express features syntax highlighting (for HTML and Surferscript), tag completion, a terminal emulator, and some debugging capabilities. We found the integrated "trace" functionality to be extremely helpful.

Incremental Migration
With Screensurfer in place, the transition from "terminal in a browser" to a co-server-supported Web application can be made one screen at a time. This feature is particularly attractive to developers who have to deliver a solution fast and then refine the look and feel of the user interface afterwards. It's an easier transition for the users as well; that same text interface that they've always used remains exactly the same when delivered via the screen-to-HTML engine.

Our Experience
We decided to install Screensurfer on a developer's workstation and try it out with a green-screen application running on an AS400. Installation of the Teamstudio package was quick and painless. The Teamstudio server, development environment (Express), and associated help files were installed. We selected all the default options for installation of Screensurfer. The only configuration we had to do on the AS400 side was to ensure that we had TCP/IP installed and running (in our case we did). If you do not have this available, you will need an SNA server like Microsoft SNA Server to handle all the SNA5250 to TN5250 bridging.

Our first test was to see our application using the "screen to HTML" functionality. We cracked open the tutorial and followed along, starting with opening up Teamstudio Express and creating a new project. We were quite pleased to find that the Teamstudio Express IDE interface is similar to the ColdFusion Studio interface my colleague and I were both quite comfortable with.

Teamstudio Express provides a wizard for configuring your application. All of the necessary Surferscript files were automatically generated by this wizard; we just had to hit the Compile button and were ready to go! Officially, that's all that we needed to do to get Screensurfer to drop our green screens into a browser. There are two ways to see the fruits of our (admittedly meager) labor. The first is by hitting the Launch button in Express (it looks like an exclamation point) and the second is to go to the default URL (http://localhost:82/surfer/home/) in your browser. The host access page is shown in Figure 1.

Select the protocol, enter the host name, and press "Connect." If you entered all the correct information, you'll get your mainframe's logon screen. The mainframe logon screen is shown in Figure 2.

It doesn't get much easier than that. We just eliminated the necessity of each mainframe user having terminal emulation software installed on their workstation and opened up all of those applications to anyone with a Web browser. The total development cost was about 10 minutes of developer time. All of your green screen users will feel right at home, as the application interface is the same as in the terminal emulator.

In a production environment, Screensurfer should be installed on your Web application server or another Web-accessible server. Important to note is that Screensurfer operates as its own Web server. If you install it on a machine with an operating Web server, you will need to give Screensurfer a port number other than the one currently being used by your Web server software. We did not see any documentation that suggested we could use Screensurfer in conjunction with an external Web server.

To enhance the user experience, Screensurfer ships with functionality to handle keymapping. For example, a developer could map the F11 key on the user's keyboard to send the F11 command to Screensurfer (and therefore to your mainframe application). This is accomplished through the use of an ActiveX control (distributed via .cab file) for Internet Explorer users and a Netscape plug-in for Netscape users. If you opt not to use this functionality, the end user will have to click on an image map that appears next to the mainframe display screen to actuate function key commands. It's a nice touch that will be much appreciated by terminal emulator power users.

Let's Customize!
As we mentioned earlier, Screensurfer uses a collection of ASCII files that contain HTML and specialized Screensurfer markup called Surferscript. Surferscript is a tag-based language, just like CFML. These Surferscript tags allow the developer to control Screensurfer's path through your application interface screens. You do not have to use Teamstudio Express to modify Surferscript code, but we found it much easier than working in Notepad.

Surferscript tags are prefixed with "TE" similarly to how ColdFusion tags are prefixed with "CF". ColdFusion code is stored in ".cfm" pages, while Surferscript code is stored in ".stml" files. These ".stml" files are what get compiled by Teamstudio Express to form your Screensurfer application. A complete tag reference document is installed with Teamstudio Express and does a good job of explaining the functionality behind each tag.

For our second experiment, we decided to retrieve multiple screens of data. In our green-screen application, the user has to hit "page down" repeatedly to navigate through all the information. We were curious as to how Screensurfer accomplished this task.

Fortunately for us, the tutorial coupled with the wizard in Teamstudio Express made the task of retrieving multiple screens of data fairly easy. We launched the wizard, marked up our terminal screens, and aside from a minor mix-up between page up and page down, we were good to go. Looking at the trace of the screens that Teamstudio processed made the task of debugging our code simple and also gave us a good look into what was happening behind the scenes.

Screensurfer was selecting the data from the marked regions on the AS400 display screens, sending a "Page Down" keystroke to the AS400, and repeating this process until the string "more..." no longer appeared on the screen. We noted that retrieving the data and generating the page output for display took slightly longer than an equivalent database call. Later on, we determined that compiling the Screensurfer application without the trace functionality enabled decreased runtime dramatically.

The Co-Server Environment
Teamstudio knows that developers need to integrate this data into their existing applications, not just access the same data the same way through pretty screens in a browser. Using the provided CFX tag and Surferscript, a developer is able to send to and retrieve data from the mainframe. We took our previous example (retrieving multiple screens of data) and modified it according to the tutorial instructions to return only the scraped data to ColdFusion.

This proved slightly more difficult to do and the instructions really only made sense after we completed the task. Most of our work was in adding custom Surferscript around the HTML output blocks in the STML files so Screensurfer would not be interjecting HTML into the return data stream. Once that part of the application was completed, we created a simple ColdFusion page containing the <CFX_Surfer...> tag call and a <CFDUMP>.

We compiled the Screensurfer application without trace functionality enabled. When we ran the ColdFusion template, performance was definitely acceptable. We compared the runtime of our <CFX_Surfer...> call with a stored procedure grabbing the same data from the same database and found that they were practically the same.

Observations
Developing a well-customized Screensurfer application will require a developer with a decent amount of familiarity with and comfort in both the green-screen and Web-based environments - that's why it took more than one person to write this article! We agreed that the tutorials would be somewhat more helpful if they provided a narrative logical overview of what we were going to do; using them as reference materials was difficult especially considering our lack of familiarity with Surferscript.

Some may ask what the point of the co-server environment is. As part of a larger migration scheme, the co-server environment is a key phase to migrating away from the green screen entirely. By implementing the "screen to HTML" functionality of Screensurfer alone, the potential user base of the application is increased and the desktop software requirement (terminal-emulation software) is removed.

The users continue to work on screens in the browser that look the same as the ones they saw in their terminal emulation software. Meanwhile, the development staff can work on creating dynamic, data-driven applications that are fed by the Screensurfer co-server application in ColdFusion, ASP, JSP, or whatever supported language they choose. Once that is complete, system users can be smoothly migrated to a "Webified" user interface without leaving the browser. Ultimately, though, this ColdFusion/ASP/JSP application should move to the final phase of hitting the database directly, especially since database drivers are available for most mainframe databases. Screensurfer gives the developer the ability to smoothly transition the user base to a Web interface.

Conclusion
We were very happy with the screen-to-HTML features of Screensurfer. Sometimes referred to as "lipstick on a bulldog," the practice of screen scraping has been done for quite some time and usually at high cost. In relatively little time, we had opened up our normally closed AS400 application to the Web for far less than other solutions under consideration. In companies working hard to quickly Web-enable their business processes, Screensurfer can play a very useful transition role.

SIDEBAR

Vitals
Teamstudio Inc.
900 Cummings Center * Suite 326T
Beverly, MA 01915
Phone: 800-632-9787
[email protected]
www.teamstudio.com

Test Platform:
Compaq Deskpro, 396MB RAM, 500MHz Celeron
Windows 2000 SP3
ColdFusion MX Updater 3

Supported Terminal Types:
3270, 5250, and VT100

Pros: Easy setup and quick terminal emulation in the browser; application server integration
Cons: Restricted to screen scraping only; cannot directly access database or RPG programs
Target Audience:
Companies looking to move their existing screen-based applications to the Web for use in e-business and e-commerce
Pricing:
Per server depending on number of users

More Stories By Greg Lang

Greg Lang is a Senior Application Developer and Project Manager with Amkor Technology in the Philadelphia suburbs. Greg has over 20 years of experience working with legacy
systems and emerging technologies.

More Stories By Stephen Rittler

Stephen Rittler is the president of Countermarch Systems LLC, a company dedicated to improving alumni relations in higher education through the proper application of CRM tools, social networking and process improvement through technology. His company has developed effective solutions for clients in education, government, publishing and manufacturing. He is a Certified Advanced ColdFusion MX developer and has contributed to the CF community through his writing, leadership of the Philadelphia ColdFusion User Group and presentations on a variety of topics. Steve is a musician at heart but has yet to figure out how to play his saxophone and code at the same time. You can read his blog at http://www.countermarch.com/blog.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.