Browse Prior Art Database

A PROXY-BASED TOOL TO ENABLE REMOTE TRACING ("SOFTWARE SNIFFING"), FLOW CAPTURE AND REPLAY, AND TESTING VIA HOST INTERACTION ...

IP.com Disclosure Number: IPCOM000013497D
Original Publication Date: 2000-Jan-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 4 page(s) / 79K

Publishing Venue

IBM

Abstract

A PROXY-BASED TOOL TO ENABLE REMOTE TRACING ("SOFTWARE SNIFFING"), FLOW CAPTURE AND REPLAY, AND TESTING VIA HOST INTERACTION ...

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 4

  A PROXY-BASED TOOL TO ENABLE REMOTE TRACING ("SOFTWARE SNIFFING"), FLOW CAPTURE AND REPLAY, AND TESTING VIA HOST INTERACTION


...

  In host publishing servers, Web page requests are transferred to backend engines that drive terminal oriented (3270, 5250, VT) host application-specific "screen scraping" logic. The goal is to access legacy data by scraping the information from application-specific host screens, and present it to the browser with HTML tags, using various HTML generation approaches such as proprietary tags, Java Server Pages tags, custom servlets, etc.

The screen scraping logic driven by the backend engine, in response to a Web page request, involves

1. Connecting to a host,

2. Sending commands to the host and traversing screens to - long on, performing a "data transaction", extract data from rectangular areas of some screens, and log off, and

3. Disconnect from the host.

Connection pooling may eliminate some of the above steps, but that is irrelevant for this invention.

This invention addressed four problems that are encountered in host publishing solution frameworks.

1. The screen scraping logic is typically run on the server without a "green screen", for performance reasons. Errors in screen scraping logic often require a terminal display to detect timing problems (command to host sent before screen updates complete), and in host publishing servers on S/390 and the AS/400, it is not clear where such (AWT-based) displays will appear. Solutions such as R(emote)AWT are RMI-based and expensive. Ideally, the administrator of such a server, managing it via a Web browser, should be able to "redirect" the display that running trace slows down the server sufficiently to change timings such that the original problem does not occur any more.

2. When a customer purchases a host publishing solution, and is unable to get his screen scraper to work with his favorite host application, using some design-time wizards that are part of the product, his only recourse to service is to send bit maps of screen shots or request a site visit, since the folks in service typically won't have access to the customer host to experiment with. It would alleviate service problems if the customer could record the host interactions (both the expected one recorded by

1

Page 2 of 4

physical interaction, as well as the faulty one driven by the screen scraping app) as a trace, ship the trace to service, and have them play back the screens to see exactly what is occurring in the customer environment. A tool that can replay (visually) both the upstream and downstream flows is what is required.

3. When a host publication solution is shipped, it is hard to ship sample of screen scraping apps and descriptions of how to develop those apps (without programming) using design wizards, if the customer does not have access to those hosts/apps to test with. It would be desirable to ship traces of flows created by such applications, and a tool that will play back the hos...