• August 17, 2022

Top five myths of screen scraping: keeping host and GUI in sync is hard

In an earlier post we discussed the challenges facing companies that rely on older green-screen applications to manage their critical infrastructure, and some of the myths that surround “screen-scraping” applications. We also discussed the first myth–that screen scraping is only a green screen in a browser. Today, we tackle the second myth.

Myth #2: Keeping Host and GUI in Sync is Hard

As any developer knows, maintaining APIs can be a labor-intensive process. If an API changes, anything that uses that API must typically also be adapted. So if a green screen changes, how do you take that change into account in your GUI?

Managing host application change is a key differentiator between current modernization technologies and a typical screen-scraping approach. An effective modernization solution uses your actual application screen maps1 during application development and maintenance. With a repository of screen maps as a basis for development, developers can create and maintain customized GUIs for applications that include thousands of screens. When screens change, an automated change management feature enables you to easily synchronize your GUI application with your underlying screen “APIs.”

Host-to-GUI synchronization is actually a two-part challenge:

  • The GUI must know what screen(s) to use to access information
  • The GUI must know what host fields to use on each screen

Traditional screen-scraping approaches expect you to manually maintain the links between your live green screens and your GUI. If a screen changes, there is no automated way to catch and apply the change. By registering your application screen map files in an XML-based repository, today’s modernization tool overcomes the synchronization challenge and provides a complete foundation for application development and maintenance.

What screen am I on?

Custom GUIs for green-screen applications require a link between the GUI and the host screens that provide information. In other words, the GUI solution must “know” what screens are being sent by the host in order to show the right GUIs.

Screen scraping repositoryA stereotypical screen-scraping product provides manual screen identification. In manual identification, the developer must navigate to each desired screen in the live application and manually select the characteristics about that screen that make it unique from all other screens in the application. If the developer accidentally selects a conditional field or uses the same characteristics to identify two different screens, identification can fail. If a screen changes, the developer must manually navigate to the screen again and re-identify it.

With a more advanced modernization tool, maintaining screen identifications is an automated process. Screen maps are incorporated into a repository and are automatically assigned unique identifiers. Since this process is based on the screen maps rather than the live datastream, it’s more accurate. The links between GUIs and the green-screens in the repository are automatically checked and updated whenever the change management process is initiated.

Automated screen identification insures an accurate link between your GUI and your host applications – without requiring a developer to spend any time maintaining these critical links.

What fields do I need?

Host field mappingAs users work with your GUI, information they enter or change is pushed back to editable fields on the green screen. Therefore, GUIs built over green-screen applications require a link between the host fields on each screen that provide the information and GUI fields that enable users to interact with that information.

A typical screen-scraping approach to this challenge is to rely on the developer to create manual mappings based on the row/column position of each host field on each screen. Developers navigate live to each screen that contains the fields they want, then point and click on each individual field to register it for use in the GUI. Solution developers may not know that certain fields change color, size, or position based on program events and therefore cannottake these changes into account. They may be unaware of conditional fields that only display in certain circumstances. Without access to the screen maps, these solutions place the burden on the developer to discover changes in field states and attributes.

A more precise method is necessary. An effective modernization tool offers automatic host field mapping based on the application field names and attributes from the screen maps. Information about every host field in the application becomes available via the screen repository. By providing access to this information, the solution enables developers to create solutions that encompass all of the host application possibilities — including features like detecting and acting upon color and state changes and variable field positions and sizes.

Using the true application field names also reduces change management requirements, as the modernization solution interacts with fields based upon their true host names rather than their row and column positions on the screen. If you move a field on the screen, a modern solution can still interact with it without changing the underlying field definition.


In our next post, we’ll address the myth that screen scraping is a maintenance nightmare. Until then, you can learn about the remaining three myths–and how to move past them–by downloading the complete whitepaper at the link below. You can also visit our website to learn more about our LegaSuite portfolio of Application Modernization tools.

Whitepaper Download

Rocket Software 160 Posts

Rocket Software empowers organizations to create legendary impact in the world through innovation in legacy technologies. With deep expertise in IBM Z, IBM Power, and database and connectivity solutions, Rocket solutions power tens of thousands of global businesses, solving real problems and making real-world impact. With more than 70% of the world’s IT workload running on legacy platforms, Rocket helps companies and public-sector organizations innovate using the technology and data they already have, so they can always be ready for what comes next. Rocket customers include 44 of the Fortune 50, representing industries including Banking and Finance, Healthcare, Manufacturing, Transportation and Logistics, Retail and Insurance. A Bain Capital portfolio company, Rocket is headquartered in the Boston area with centers of excellence strategically located throughout North America, Europe, Asia, and Australia.


Leave a Comment

Your email address will not be published.