What is the Screen Scraping SE?
Communication and integration with existing legacy systems is key to implementing SOA strategies for enterprise information systems that contain legacy systems.
The Screen Scraping Service Engine provides a complete solution for updating legacy systems with current technologies and exposing them as web services. The orchestrated web services make it possible to share data and services between legacy systems and other information providers and consumers.
The current implementation includes support for the IBM Telnet 3270 protocol to access mainframe-based applications. A NetBeans plug-in module provides tooling for developers to design legacy system web service's data and operations. The resulting design artifacts are used by the Screen Scraping Service Engine to enable real-time integration with these applications.
Using the Screen Scraping SE
The NetBeans plug-in module and the JBI service engine are two parts of this component.
Developers use the NetBeans wizard to create a Screen Scraping Module project and to design web service artifacts for targetted TN3270 applications. The service engine running within GlassFish ESB's JBI container executes generated Ruby scripts to interact with the server. The screen scraping API is developed in Java, and is used in both the design-time and runtime components. The API interprets IBM Telnet 3270 protocol from datastream established over TCP/IP connection to the server.
The following diagram shows the complete development cycle from implementing web service to integrate with legacy systems.
(click to expand)
System requirements and dependencies
No special requirements
Please post questions on the OpenESB mailing list
. File bugs in the OpenESB issue tracker
; use the Screen Scraping SE category.
Evolution of the Screen Scraping SE
- Performance enhancements
- Runtime monitoring / debugging
- Other terminal support
- This component is contributed by AllGateways Software.
- Developers working on the Screen Scraping SE:
Developing the Screen Scraping SE
We specify the class of component manager in jbi.xml, the class implements Component and ComponentLifeCycle. Component Manager will create RuntimeMBean, Exchange Handler, End Point Manager and Serivice Unit Manager. Your component manager will extends the component tool kit's
AbstractComponentManager.Screen Scraping Se Component Manager Class Diagram
The Exchange Handler is created when Component Manager gets initialized. The AbstractExchangeHandler will start the NMR poller threads. In Screen Scraping SE, we only need to handle IN_OUT_PROVIDER. Screen Scraping Se Exchange Handler Class Diagram
. Screen Scraping Se Exchange Handler creation sequence diagram
EndPointManager creates End Point, End Point Manager is created in the component manager init() process. The definition of End Point Manage and End Point is Definition
. In Screen Scraping Se, we implemented several sub classes. See End Point Manager Class Diagram
End Point Class Diagram
We currently do not have any parameter to set with Application Configuration. Application Configuration is a tabular data that you can set as name
value pair.Class Diagram of Generic Runtime MBean in Qos and Screen Scraping Se MBean
. The runtiem Mbean is created when the component manager is created. Sequence diagram creating runtime MBean
. Due to the special case of Screen Scraping SE, we do not find it necessary to have application configuration, so our Mbean doesn't have such data. If you are developing a BC, you can take advantage of RuntimeConfiguration abstract MBean and create such Mbean when you do initRuntimeMBean.
After the screen scraping NetBeans module (NBM) is installed to NetBeans, a TN3270 terminal node appears in the Services window. The user can use the TN3270 terminal node to connect to any TN3270 type server. In addition, the user can reload an existing Screen Scraping Module project to modify the execution scripts.
- Wizard: The user starts the design process by creating a new Screen Scraping Module project in the NetBeans IDE.
Once the server connection properties are provided, the wizard appears. The wizard includes an emulator. Web services for legacy applications are described along with the user's interaction with the emulator. When the emulator starts, the recorder can be turned on to store the user's actions. Each user's data input can be parameterized into a part of web service input structure. On a given screen, the user can enable the output data construct tool to describe the expected data output XML structure.
After the recording process ends, Ruby scripts and input and output XML schemas are produced. The generated files are loaded by the service engine to provision the web service.
- Input Parameter: It's very easy to define input parameters. For each user inputs, it can be parameterized into a variable with desired name. All other user inputs are treated as constants.
- Output Data Construct: Applications running on legacy systems normally have data outputs that are not formatted. To bring legacy data into XML, an output data describing tool is provided. The user uses the tool to design the output format graphically. A set of predefined data pattern can be applied to any portion of the data output. This process facilitates the conversion of free-form data to XML structure.