Screen Scraper. Fact or Fiction. :)

[Mark Spritzler]

OK, I have been thinking about this for a while. OK just this morning. But they say a Screen Scaper will take a Dumb Terminal's "Data" and translate it so that we can use it.
But how? Here's my scenario. We have COBOL programs written in ACUCOBOL, and run on HP UX 11 N Class 4000's, the user's use a terminal emulation program. The Data is stored in VSam files, which is a proprietary layout, there is no bridge to access the data except through the COBOL.
OK, I might have just answered my question. When you use a screen scraper, and want to access legacy systems, it is always on the "Back-end", meaning you are not creating the User Interface.
It is like a call and return Data.
I just don't see how this can be of any use? I couldn't see wrapping Java code around it. We have over 9000 Cobol "Objects"/programs. That is also to say there is still over 200 screens that would need to be accessed. The Facade pattern handles complexity on the COBOL System, but there is still way too many access points to the COBOL System.
I wish I could communicate this better, but that's the best I could do.
Mark

[Alberto Dell'Era]

As far as I have understood, a screen scraper is a (commercial) program that emulates a dumb terminal and connect to the legacy system pretending to be one of them. Then a Java program can connect to the SS and see an objectified view of the interface provided by the legacy system. It's an "object-to-terminal" adapter.
What's good for ? If you don't have access to the legacy code, this is the only way to integrate the two systems. Inelegant and weak (a single cosmetic change on the legacy interface breaks everything), but it works. And perhaps simple from the point of view of the legacy system engineer: it sees just another terminal, not e.g. a strange "java-to-cobol" mapping process that sits on his/her system and has to be maintained managed and so on ...

[Bagwan Mehrat]

Hello, Mark.
It's hard to tell whether you understand what a screen scraper is?
If you have a legacy program where the only known access is through a terminal interface, and you want to use its functionality despite that, then the only possible way is to rig up a screen scraper (write one yourself, or use a commercial one).
The screen scraper will actually use the terminal interface as though it (the screen scraper) were a user, probably using some rule based logic. If, for example, the only access I had to an inventory database was some clunky terminal program that lists the entire inventory when the user enters the command "list<ENTER>", and I wanted my program to be able to tell whether there was a "widget" in the inventory, then I would have no choice but to use a program that would actually send "list<ENTER>" to the terminal, and would subsequently look for the word "widget" in the output.
That whole action would eventually be wrapped in
boolean Inventory.WidgetExists() or something.

[Mark Spritzler]

Thanks Guys.
Bagwan. That is what I thought they were, and that leads me to what my question was. What if what is in the Terminal is not a List enter and a list of inventroty shows up. What if it is a full fledged User-Entry System with tons of Reports. and you want to Enter in Some of the Screens. Do you actually have to pass KeyStrokes through the Jave to get to the COBOL Application, and read what shows back, then line by line look for what you want?
Thanks