EP1410179A2 - Procede et systeme permettant d'acceder a des donnees dans des applications patrimoniales - Google Patents

Procede et systeme permettant d'acceder a des donnees dans des applications patrimoniales

Info

Publication number
EP1410179A2
EP1410179A2 EP00957918A EP00957918A EP1410179A2 EP 1410179 A2 EP1410179 A2 EP 1410179A2 EP 00957918 A EP00957918 A EP 00957918A EP 00957918 A EP00957918 A EP 00957918A EP 1410179 A2 EP1410179 A2 EP 1410179A2
Authority
EP
European Patent Office
Prior art keywords
screen
snapshots
legacy application
screens
fields
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00957918A
Other languages
German (de)
English (en)
Inventor
Scott Opitz
Alex Elkin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
McData Services Corp
Original Assignee
Computer Network Technology Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Computer Network Technology Corp filed Critical Computer Network Technology Corp
Publication of EP1410179A2 publication Critical patent/EP1410179A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99932—Access augmentation or optimizing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99933—Query processing, i.e. searching
    • Y10S707/99934—Query formulation, input preparation, or translation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99943—Generating database or data structure, e.g. via user interface
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99948—Application of database or data structure, e.g. distributed, multimedia, or image

Definitions

  • the present invention relates in general to the utilization of data found on legacy application screens, and particularly to a method and device for accessing data through the creation of maps of legacy applications.
  • Legacy applications computer programs running on mainframe or host computers
  • One way to update these interfaces is to create an application that allows the legacy application to run in an unchanged state, but allows the user to access the legacy application through a separate program operating on a personal computer or workstation. For these interfaces to work correctly, it is necessary to spoof the mainframe computer into providing the appropriate screens from which data can be extracted for the new interface.
  • the mainframe application has no knowledge that the user is using a different front end.
  • data entry must be allowed into the legacy application through the new interface.
  • a "map" must be created of the Legacy interface that sets forth how to access the data and input locations in the legacy application.
  • prior art systems exist that are capable of developing these maps, the process by which these maps are created are clumsy.
  • a map is created only with the help of a great deal of expert knowledge concerning the organization of the legacy application and with a great deal of time and effort on the part of the programmer. What is needed is an improved system that allows the creation of maps of legacy systems with a minimum of knowledge and expertise by the end-user.
  • the present invention meets this need by providing a simplified method and system for mapping legacy application data.
  • the mapping process consists of two phases: trail recording and mapping.
  • the trail recording phase the user interacts with the legacy application using a terminal emulator built into the present invention.
  • trail recording can be turned on, which allows the present invention to record all of the user interaction with the legacy application.
  • the trail recording phase can be accomplished in a single session with the legacy application. In most cases, however, multiple sessions are used to access all areas of the legacy application in which data extraction or input is desired. Each of these sessions is saved in the system as a separate trail. Where multiple sessions are used, each trail is stored separately and later combined in the map of the legacy application.
  • the mapping phase begins after the trails have been collected. During this phase, the present invention analyzes the trails according to specific rules that are controlled by the end user.
  • the primary goal of the mapping phase is to be able to identify each of the terminal screens used by the legacy application and all of the relevant data found on those screens. The map must also incorporate information on how the application moves from one screen to another.
  • the invention is able to recognize common screens and distinguish between separate screens by applying screen identification rules. Usually, no user intervention is required to create these rules, and the mapping phase can be accomplished automatically after the trails are generated. In some cases, however, the user will find it useful to rename the screens and fields with meaningful names. In addition, for those cases where the host application exhibits complex behavior or complex data layouts, it is possible for users modify the automatically created rules and to specify additional mapping rules.
  • Figure 1 is a block diagram of the environment in which the present invention is utilized.
  • Figure 2 is a flow chart of the basic method for creating maps of legacy applications and services that embody those maps.
  • Figure 3 is a screen display of the user interface of the preferred embodiment of the present invention including the tree view and presentation space view.
  • Figure 4 is a diagram of the tree view containing the trails panel.
  • Figure 5 is a diagram of the tree view containing the map panel.
  • Figure 6 is a screen display of the actions input properties screen.
  • Figure 7 is a screen display of the actions destination properties screen.
  • Figure 8 is a diagram of the tree view containing the data panel.
  • Figure 9 is a screen display of the present invention showing the data panel tree view and a legacy application having table data in the presentation space view.
  • Figure 10 is a screen display of the table template properties screen.
  • Figure 11 is a diagram of the tree view containing the methods panel.
  • Figure 12 is a diagram of the tree view containing the services panel.
  • the present invention assists users in creating maps of legacy application data. Once created, the maps can be used in the creation of new interfaces for old legacy applications. The maps themselves can be converted into a reusable software component such as one or more
  • Java Beans or Enterprise Java Beans The component can then be used by the new front-end or back-end applications to input and extract data from the legacy application.
  • the map that is created consists of the screens used by the legacy application, the navigational information required to traverse through the sequence of screens, and the tags and fields used to identify each legacy screen. Together, these contain all of the logic required to navigate and interact with legacy applications.
  • FIG. 1 The environment in which the present application is used is shown in Figure 1.
  • the legacy application 10 is operating on a host computer 20.
  • the present invention is run on a personal computer or workstation 30 connected to the host computer 20 though a network or terminal connection 40.
  • the personal computer or workstation 30 utilizes an operating system providing a graphical user interface, such as
  • the preferred embodiment of the present invention utilizes a user interface 100 having two primary panes, or views: the tree view 110 and the presentation space view 120.
  • the tree view 110 is a graphical representation of hierarchical information, consisting of a "root" component 112 that can be expanded to expose underlying sub-components 114 (also called “nodes,” or “branches”). These sub-components 114 often can be expanded as well, to reveal their own sub-components, creating a hierarchical tree format.
  • a "+/-" expansion symbol 116 before each component in the tree identifies if the node can be expanded to reveal additional, lower-level nodes.
  • the tree view 110 is further delineated by "tabs” 130 that run across the top of the tree view 110.
  • Each tab 130 represents a “tabbed panel,” with each tabbed panel containing a tree view 110 of its own.
  • the trail panel 140 is shown in Figure 2.
  • the right pane of the interface shown in Figure 2 is the presentation space view 120.
  • the presentation space view 120 acts as a terminal emulator allowing interaction with the legacy application.
  • the saved screens can be displayed in the presentation space view 120. You can view the saved screen by clicking on the screen component 114 in one of the tree views 110.
  • the presentation space view 120 is also used to create data templates and table templates, as described below.
  • the terminal emulator In order for the terminal emulator to be able to access the host legacy application 10 (as shown in Figure 2, step 300), it is necessary to provide basic information about the host computer 20 to form a host profile. For example, the appropriate communication protocol must be selected.
  • the preferred embodiment of the present invention supports the following protocols: TN3270/TN3270E Models 2-5; TN5250 Standard (80 column) and Large (132 column) screens; and Telnet: VT100, VT220, and VT320 (text only). Although these protocols are supported in the preferred embodiment, it would not exceed the scope of the present invention to support more or different protocols than those set forth herein.
  • the host profile will include information on the host name; the correct port for the terminal server; and the IP address or DNS name of the legacy host. It is also possible to select the specific logical unit (LU) name, as explained in RFC 1647.
  • LU logical unit
  • a trail is a linear path of all screens encountered by the user during a session with the legacy application
  • Each trail contain the following information: iii) a snapshot image of each screen encountered by the user, including underlying screen data; and iv) all keystrokes typed by the user at each screen, including function keys such as PF1 or ENTER
  • the main goal of the trail recording phase is to expose the present invention to all the host screens that display useful data (or contain data input fields) and the path needed to reach those host screens. Trails are recorded by connecting to the host 20 and using a terminal emulator built into the presentation space 120 of the present invention to interact with the legacy application 10.
  • Trails are listed in the trails panel 140 of the tree view 110, as shown in Figure 3 and in more detail with a different set of trails in Figure 4.
  • the trail panel 140 lists the host name or IP address 142, followed by each of the trails 144 that have been recorded.
  • Each trail 144 can be expanded by clicking on the appropriate expansion icon 116 to view all of the screen snapshots 150 taken during the recordation of that trail 144.
  • the trails 144 are named according to the order in which they are created, but they can be renamed by the user.
  • Trail recording can begin at any location in the legacy application 10. Since it is usually important to access the login screen and other initial navigational information in the trail 144, the first trail recordation is usually started even before the login procedure. Subsequent trails 144 may not require the login screen. For example, trails 144 may be needed that traverse from various screens back to the main menu. In this case, the user could connect to the host first, navigate to the correct screen, and then start trail recording, perform the navigational steps, and stop trail recording when the have returned to the main menu.
  • Each screen snapshot 150 contains the complete screen information received from the legacy application 10, including all of the formatted fields 152 found on that screen snapshot 150.
  • the individual fields 152 associated with a snapshot 150 can be seen simply by expanding the snapshot 150 on the trails panel 140, as shown in connection with snapshot "SpShot_4_3" in Figure 4.
  • Most screen protocols, such as the TN3270 protocol, directly identify the fields to the terminals, so it is a trivial matter to maintain information about all of the formatted fields 152.
  • each screen snapshot 150 created during trail recordation is considered a primary document. That is, each screen encountered contains useful information that cannot be incorrect or wrong. Rather, each screen is like a fact, useful in that it contains true information about the operation of the legacy application 10. As a result, the user is not allowed to delete individual screen snapshots 150 from a trail 144.
  • the next step 360 is to create a map from the trails 144.
  • the snapshots 150 found in the trails 144 are analyzed to identify the individual screens 170 found in the legacy application 10.
  • the map panel 160 shown in Figure 5 shows a map that has been created from the trails 144 of Figure 4. Once created, the map panel 160 displays the screens 170, global variables
  • each screen 170 includes the fields 152, tags or beacons 172, actions 174, and snapshots 150 associated with that screen 170.
  • the most important element in the mapping process to identify the separate screens 170 encountered in the trails 144 is accomplished by analyzing the screen snapshots 150 included in the trails 144 according to screen identification rules.
  • the default identification rules used by the present invention are simply the layout of the formatted fields 152 that are included in each screen snapshot 150. In other words, the present invention initially identifies screens 170 by noting the number, size, and location of all formatted fields 152 in a snapshot 150.
  • Another problem situation is where two different screens 170 have the same layout of formatted fields 152.
  • the user is allowed to identify additional screen identification rules (step 340 in Figure 2).
  • Additional screen identification rules are created by using tags or beacons 172 that identify a selected area on the screen 170 that contains unique information. Unlike the field comparison of the default identification rules, which use only field number, position, and size to determine a screen match, tags 172 use alphanumeric characters contained in the selected area to determine the screen identity.
  • tags 172 will be added where two snapshots 150 have been inappropriately been identified by their fields 152 as the same screen 170.
  • a user can assign as many tags 172 to a screen 170 as are necessary to uniquely identify that screen 170.
  • a tag 172 can be added to distinguish between the two screens
  • the presentation space view 120 displays the first snapshot 150 associated with a screen 170 when the screen 170 is selected in the map panel 160.
  • a mouse or other input device can then be used to select a unique area on the presentation space view 120.
  • the selected area will be surrounded by a visual selection box, which the user can use to create the tag 172.
  • Each tag 172 can be allowed to float. For instance, if the tag 172 is allowed to float freely, a match is found if the selected text is found anywhere on the screen snapshot 150.
  • the tag 172 also can be restricted to an exact row and column location, or can be allowed to float anywhere on a specified row or column.
  • Another method for customizing screen identification is to disable some of fields 152 used for matching. By default, all fields 152 are used for screen matching. In some cases, however, this default will cause screen snapshots 150 that share the same purpose (and hence should be considered the same screen 170) to be considered different simply because one field 152 of the snapshots 150 does not appear on every screen.
  • the user can reduce the matchset, so that snapshots 150 with subtle differences will be recognized as the same screen 170. If a tag 172 is created for a screen 170, it is sometimes appropriate to let the tag 172 be the only test for that screen 170 — if the tagged text is present, the snapshot 150 is always identified as an example of the screen 170. If this behavior is desired, all of the fields 152 associated with the screen 170 should be disabled. After the new screen identification rules have been set up, as described above, it is necessary to regenerate the map under the new rules.
  • Actions In addition to identifying screens 170 in a legacy application 10, the present invention must also determine how to move between screens 170 in order to complete the map. The movement between the screens 170 is also determined by analyzing the trails 144, and is recorded as an action 174 in the map. Each action 174 embodies the knowledge that when certain keystrokes are submitted to the legacy application 10 at one screen 170, the legacy application 10 will respond by supplying a known new screen 170.
  • the present invention stores with a particular screen snapshot 150 all the keystrokes entered by the user during that snapshot 150, including any AID key pressed to complete the operation.
  • the keystrokes stored with a snapshot 150 are grouped into an action 174 that is associated with the identified screen 170.
  • the actions 174 also record which new screen 170 was presented by the legacy application 10 after these keystrokes were entered. If during the mapping, the same keystrokes were used to move between the same two screens multiple times, these multiple occurrences of keystrokes would be grouped into a single action 174.
  • each unique set of keystrokes is stored as a separate action 174, with each action possibly being associated with a different succeeding screen 170.
  • the invention supplies a descriptive default name to an action 174 such as toFirstScreen or toSecondScreen. To make these names make more sense to the user, these and other names created by the invention can be altered as desired.
  • the keystrokes recorded with an action 174 determine the information that is contained in the next screen 170. For example, a customer look-up screen will allow the entry of the customer's name. The next screen would then supply data about the customer whose name or customer number was entered. In these circumstances, the actual keystrokes recorded in an action 174 should be replaced with a variable. By doing so, the invention could be used to create software components (i.e., JavaBeans) that can interact with other code to look up any customer rather than merely the customer whose name was entered during trail recording.
  • software components i.e., JavaBeans
  • a global variable 162 In order to use a variable in an action 174, a global variable 162 must be defined for the map. This global variable 162 can then be used by an action 174. When a new global variable 162 is created by the user, it is added to the map panel 160. The new variable 162 can be renamed by the user. Each global variable 162 has three properties: name (the name of the global variable), default value (the text string that will be used as the default input value for the variable) and used by (a list of actions and /or method variables that use this variable which is automatically generated when the data fields are defined).
  • Each action 174 has a variety of properties. These properties can be divided into input properties 180 (shown in the input properties screen 178 on Figure 6) and destination properties 190 (shown in Figure 7).
  • the input properties 180 define the information needed to correctly identify and perform the action 174.
  • the destination properties 190 are used to identify information about the screen that is accessed after the action 174 is performed.
  • the action 174 has associated with it keystrokes 181 (shown on the properties screen 178 in Figure 6 as "Data/Prefix") and an AID key 182, which are two of the input properties 180.
  • the AID key property 182 identifies the AID key used to complete the action 174.
  • the "Use for Match" option can be deselected if the particular AID key 182 is not used to identify the action, meaning that another AID key 182 could be used instead in the same action.
  • a global variable 183 can also be used in place of the keystrokes 181. If both a global variable 183 and the keystrokes properties 181 are set, then the keystrokes property value 181 will be prepended to the value of the global variable 183.
  • other combinations of the keystrokes 181 and the global variable 183 are possible and within the scope of the present invention.
  • An additional input property 180 for an action 174 is the position property 184. This represents the position on the legacy screen
  • the cursor position property 185 stores the position of the cursor when the AID key was pressed. This is an important property 180 because applications will often behave differently depending on the cursor position at the moment when AID
  • the user can be presented with the list of available transactions. To select from the list, the user is to place the cursor on the desired transaction hit Enter. With applications such as this, the position of the cursor 185 is needed as an input property and the "Use as Match" option should be selected so that cursor position is used in action matching.
  • the destination properties 190 are the destination list 192, and the destination determination 194.
  • the destination list 192 is an expandable list of all destination screens 193 that are received as a result of this action 174, since it is possible that multiple screens 170 will be navigated to after the action 174 is complete. Typically one of the destinations 193 is selectable as the primary destination for the action 174.
  • the destination determination property 194 is used to select how the action will determine it has reached the destination (or primary destination) 193.
  • the three choices are the data stream update count 196, the final cursor position 197, and the change direction/keyboard lock 198.
  • the data stream update count selection 196 simple counts the number of data stream updates required from the host 20, with a default of one screen.
  • the final cursor position choice 197 has the invention wait until the cursor is in the selected position until the action is considered complete.
  • the change direction /keyboard lock choice 198 waits for a change direction or a keyboard lock from the legacy application 10 before considering the action to be complete.
  • an application 10 may have the PF3 key assigned to always return the user to the main menu. If this is the case, the user can assign a global action 164 that can be a default mechanism that will always return the application 10 from an unknown state to a known state.
  • Global actions 164 When a new global action 164 is created, it is added to the tree display, sub-ordinate to the global action label, as seen in Figure 5.
  • Global actions 164 have the same properties as do regular actions.
  • Standard or data templates 210 and table templates 220 are used to extract data from the screens 170 received from the legacy application 10.
  • the establishment of these templates 210, 220, is step 380 in Figure 2.
  • These templates 210, 220 are viewed and modified using the data panel 200 in the tree view 110, as shown in Figure 8. This panel 200 displays all of the screens 170 associated with the map.
  • Subordinate to each screen 170 on the data panel 200 are data or standard templates 210 and table templates 220.
  • Sub-ordinate to data templates 210 are the static data fields 212 defined by the data template 210.
  • Subordinate to the table templates 220 are the repeating data fields 222 (fields in a table on the legacy screen 170) defined by the table template 220.
  • Data templates 210 provide access to the static data fields 212 found in the legacy application 10.
  • Static data fields 212 are those data elements that have a single occurrence per screen 170 and are generally related on a one-to-one basis with a data record. They typically will appear at the exact same row and column position on a screen 170, although they can float. Floating data elements are handled in the present invention by anchoring them to a floating tag 172 instead of a fixed screen location.
  • Each data template 210 represents an entire host application screen 170 and serves as a general container for the static fields 212 on that screen 170.
  • Each static field 212 in a data template 210 can be used to automatically set the value of a global variable 162. This is done by setting an UpdateVar property associated with each static field 212. By setting this property to the selected global variable 162, the global variable 162 is reset to the value of this field 212 every time the screen 170 is received.
  • Table templates 220 are used to define tabular, repeating data fields 222 that are contained on the legacy screens 170. Table templates 220 are similar to data templates 210, except that they do not encompass the entire screen 170. Instead, table templates 220 are used to group repeating data fields 222 found in a portion of the screen 170. An example of this type of data can be seen in Figure 9.
  • the screen 170 displayed in the presentation viewspace 120 contains a table of data 223 relating to payments on a loan, including the date 224, amount 226, and type of transaction 228. These columns 224, 226, 228 are then repeated a second time. To define the table template 220, the user must select the area
  • the metrics 231 In addition to the origin 232 (screen location of the beginning of the table 223) and the end 233 (screen location of the end of the table 223) properties, the metrics 231 also describe the number of columns 234 and rows per record 235 in the table 223.
  • the number of columns 234 indicates how often the repeating data fields 222 that represent a single record repeat in multiple columns across the screen 170.
  • An example of a table 223 with two columns of repeating data can be seen in Figure 9, which shows that columns showing the date 224, amount 226, and type 228 data appear twice on the same screen 170.
  • the rows per record 235 indicates the number of rows used to display each record in the table 223. Generally, most tables 223 in legacy applications 10 have one row per record. However, there are some applications that have one or more empty rows after each record. In this case, this value 235 indicates the number of rows included in each record.
  • the record access properties 236 of the table template 220 specify when the invention should stop retrieving records.
  • Records From portion 237 of the record access properties 236 allows the template 220 to select only a limited range of records.
  • the Only Records From property 237 could specify that only records 1 from 20 should be retrieved, or only records from 20 to 100 should be retrieved.
  • the record access properties 236 could indicate at 238 that records could stop being retrieved after one or more occurrences of empty records or repeated records.
  • the user could also create a test at 238 that retrieves data until a particular match is found, such as a global variable 162 containing the message "end records.”
  • the user can also instruct the invention whether and how to "scroll" down to the next page of records using the page down action property 239. If this is the only screen that will contain records, no scrolling is needed. If there are additional screens that will contain records, the user can select the appropriate action 174 that will lead to the next screen 170.
  • the method panel 240 is shown in Figure 11.
  • a method is a logical grouping of screen transitions, navigational information, and input and output variables. It is methods that actually retrieve data from or input data to the legacy application 10. After methods are defined (step 400 of Figure 2), they are grouped together into one or more services that will execute the methods (step 420).
  • the method panel 240 displays methods 242, as well as the input variables 244, steps 245 - 247, and output variables 248 associated with each method.
  • a method 240 is capable of retrieving certain output variables 248 from the legacy application 10 based on the value of the input variables 244 by following the steps 245-247.
  • Input variables 244 are used to pass variable information into fields 212, 222 defined in templates 210, 220 for the legacy application 10.
  • Each input variable 244 is predefined to a specific type, such as a String, Integer, Date, or Double-byte variable.
  • Each input variable 244 is also associated with a single global variable 162.
  • the global variable 162 is associated with an action 174.
  • the action 174 is then associated with a traverse method step 245 or a perform method step 246, as explained below.
  • Output variables 248 are used to extract (or "scrape") specific information from information found on the screens 170 of the legacy application 10. More specifically, output variables 248 identify the fields 212, 222 that the methods 242 will be using to extract data from the legacy application 10.
  • these fields 212, 222 are mapped to data in the legacy application 10 as defined in a data or table template 210, 220.
  • output variables 248 are predefined to be a specific type. Output variables 248 can also be enabled or disabled so that an individual instance of the method 242 will not use the output variable 248.
  • Method steps 245-247 represent the actual activity performed by the method, such as screen traversal, inputting variable data into fields, and extracting returned data from fields.
  • Three types of method steps are available: traverse steps 245 (to navigate to a specified screen); perform steps 246 (to perform a specified action); and fetch steps 247 (to extract data from the screen 170).
  • Traverse steps 245 instruct the method 242 to traverse from the current screen 170 to another screen 170.
  • the first step in a method 242 will always be a traverse step 245, because the method 242 must first navigate to a specified screen 170 before it can perform any other activity.
  • the information required to perform the traversal is contained in the map, so all that is required is to identify the desired screen 170.
  • Perform method steps 246 instruct the method 242 to perform a specified action 174, usually to input a global variable 162 into the screen 170 associated with the action 174, and then execute the AID key 182 associated with the action 174.
  • Perform steps 246 execute an action 174 on the current screen 170, or execute global actions 164.
  • the information about the action 174, 164, such as the global variable 162 and the AID key 182 to be executed, is contained in the map, so all that is required is to identify the desired action 174.
  • Assigning a global action 164 to a method 242 allows the creation of an "on fail" method. In this way, any method steps 245-247 that return a failure can transition the application back to a known state.
  • Fetch steps 247 instruct the method 242 to extract data from the specified data template 210 or table template 220 where the specified field 212, 222 from the template 210, 220 has been defined as an output variable 248.
  • Output variables 248 must be created to identify specific fields 212, 222 from which data should be extracted.
  • the services panel 260 is shown in Figure 11.
  • the services panel 260 displays services 262, as well the methods 242 associated with the services 262.
  • Services 262 are a grouping of one or more methods 242.
  • Services 262 serve as the interface between the methods 242 and the environment that actually creates the new end user interfaces. It is the services 262 that are compiled into a reusable software components such as Java Beans. Clients can then invoke these compiled services in order to execute the method steps 245-247 contained within the methods 242.
  • the screen 170, action 174, data template 210, and table template 220 are classes found in the compiled services 262. By creating these elements as classes in the generated services 262, the present invention allows programmer customization through the use of custom subclasses. To define custom behavior, it is possible to overwrite some of the methods of the components.

Abstract

L'invention concerne un procédé et un appareil destiné à mapper des données d'application patrimoniale. Le procédé de mappage consiste à effectuer l'enregistrement de pistes (320), le mappage (360), et la création de modèles (380). Au cours de l'étape d'enregistrement de pistes, les interactions de l'utilisateur avec l'application patrimoniale (10) sont enregistrées comme piste (144). Chaque piste (144) est constituée d'instantanés (150) de chaque écran (170) trouvé, et de toutes les frappes saisies par l'utilisateur. Après la création des pistes, des mappes de l'application patrimoniale (10) sont créées par le classement des instantanés d'écran (150) en écrans (170). Le classement est effectué conformément à des règles spécifiques gouvernées par l'utilisateur final. Les règles par défaut allouent des instantanés (150) selon le nombre, la position, et l'emplacement des champs prédéfinis trouvés dans les instantanés (150). Des étiquettes additionnelles (172) peuvent être définies au moyen de texte alphanumérique afin d'aider à identifier correctement les écrans (170). Des modèles (210, 220) sont ensuite créés afin de permettre un accès direct aux données trouvées sur les écrans (170) de l'application patrimoniale. Des modèles différents (210, 220) permettent l'accès à des champs statiques (212) et à des champs tabulaires. Des procédés (242) sont ensuite définis afin d'accéder à des données particulières de l'application patrimoniale (10). Un ou plusieurs procédés (242) peuvent ensuite être définis comme services (262), compilés en une composante logicielle réutilisable.
EP00957918A 1999-09-01 2000-08-30 Procede et systeme permettant d'acceder a des donnees dans des applications patrimoniales Withdrawn EP1410179A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US15184299P 1999-09-01 1999-09-01
US151842P 1999-09-01
US09/551,704 US6836780B1 (en) 1999-09-01 2000-04-18 Method and system for accessing data in legacy applications
US551704 2000-04-18
PCT/US2000/023804 WO2001016720A2 (fr) 1999-09-01 2000-08-30 Procede et systeme permettant d'acceder a des donnees dans des applications patrimoniales

Publications (1)

Publication Number Publication Date
EP1410179A2 true EP1410179A2 (fr) 2004-04-21

Family

ID=26849023

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00957918A Withdrawn EP1410179A2 (fr) 1999-09-01 2000-08-30 Procede et systeme permettant d'acceder a des donnees dans des applications patrimoniales

Country Status (4)

Country Link
US (1) US6836780B1 (fr)
EP (1) EP1410179A2 (fr)
AU (1) AU6947000A (fr)
WO (1) WO2001016720A2 (fr)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7072916B1 (en) * 2000-08-18 2006-07-04 Network Appliance, Inc. Instant snapshot
US20020138570A1 (en) * 2001-03-23 2002-09-26 Neil Hickey System for and method of automatically migrating data among multiple legacy applications and accessible storage formats
US7882497B2 (en) * 2001-05-17 2011-02-01 Attachmate Corporation Symbiotic computer application and system and method for generation and presentation of same
US20040046787A1 (en) * 2001-06-01 2004-03-11 Attachmate Corporation System and method for screen connector design, configuration, and runtime access
US7451404B1 (en) * 2001-08-06 2008-11-11 At&T Intellectual Property I, L.P. Methods and systems for obtaining data from legacy computer systems
US7421427B2 (en) * 2001-10-22 2008-09-02 Attachmate Corporation Method and apparatus for allowing host application data to be accessed via standard database access techniques
US20080059954A1 (en) * 2002-06-18 2008-03-06 Martin Joseph B Universal system component emulator with human readable output
US7280955B2 (en) * 2002-06-18 2007-10-09 Martin Joseph B Universal system component emulator with human readable output
US20040027373A1 (en) * 2002-08-07 2004-02-12 Jacquot Bryan Joseph Linked screen demonstration program for computer application programs
AU2003208051A1 (en) 2003-01-28 2004-08-23 Fujitsu Frontech Limited Method for supporting data linkage between applications
CA2447361A1 (fr) * 2003-10-29 2005-04-29 Adrian Storisteanu Methode de synchronisation d'un document texte en lignes et d'un document texte en continu
EP1704471A1 (fr) * 2003-12-23 2006-09-27 Sentillion, Inc. Procedes et dispositifs permettant de controler de fa on externe une application logicielle pour creer un nouveau comportement logiciel
US7594183B2 (en) * 2004-08-12 2009-09-22 International Business Machines Corporation Capturing a workflow
US7647328B2 (en) 2004-10-08 2010-01-12 Sentillion, Inc. Method and apparatus for processing a context change request in a CCOW environment
US9766953B2 (en) * 2004-12-16 2017-09-19 Openspan, Inc. System and method for non-programmatically constructing software solutions
US20060235899A1 (en) * 2005-03-25 2006-10-19 Frontline Systems, Inc. Method of migrating legacy database systems
WO2007111648A2 (fr) * 2005-10-28 2007-10-04 Openconnect Systems, Incorporated Interactions de modelisation avec un systeme informatique
US7962899B2 (en) 2006-12-01 2011-06-14 Harris Corporation System for monitoring a target application and method thereof
US8635069B2 (en) 2007-08-16 2014-01-21 Crimson Corporation Scripting support for data identifiers, voice recognition and speech in a telnet session
US8910112B2 (en) * 2008-07-30 2014-12-09 Sap Ag Extended enterprise connector framework using direct web remoting (DWR)
US8869028B2 (en) * 2009-05-18 2014-10-21 Xerox Corporation Interface structures and associated method for automated mining of legacy systems using visual configuration tools
EP2348403B1 (fr) * 2009-12-22 2017-03-08 Software AG Procédé et système pour analyser un système existant basé sur des pistes dans le système existant
EP2587380B1 (fr) 2011-10-28 2016-01-27 Software AG Environnement de fonctionnement et procédé pour la surveillance non invasive d'applications logicielles
US9471405B1 (en) 2014-01-13 2016-10-18 OpenLegacy Technologies LTD Methods and systems for access to legacy programs using non-legacy interfaces
US9996216B2 (en) * 2015-06-25 2018-06-12 medCPU, Ltd. Smart display data capturing platform for record systems
US11610052B2 (en) * 2018-08-16 2023-03-21 Soroco Private Limited Techniques for automated control of computer programs through text-based user interfaces

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6131183A (en) 1993-05-24 2000-10-10 Raytheon Company Computer and method for enabling graphic user interface (GUI) control and command line (TTY) control of a computer program
US5533175A (en) * 1994-03-04 1996-07-02 Destiny Technology Corporation Low cost page printer system and method
US5627977A (en) * 1994-04-19 1997-05-06 Orchid Systems, Inc. Trainable user interface translator
US5754830A (en) 1996-04-01 1998-05-19 Openconnect Systems, Incorporated Server and web browser terminal emulator for persistent connection to a legacy host system and method of operation
US5914713A (en) 1996-09-23 1999-06-22 Fmr Corp. Accessing data fields from a non-terminal client
US5958008A (en) * 1996-10-15 1999-09-28 Mercury Interactive Corporation Software system and associated methods for scanning and mapping dynamically-generated web documents
US6144962A (en) * 1996-10-15 2000-11-07 Mercury Interactive Corporation Visualization of web sites and hierarchical data structures
US5857194A (en) 1996-11-07 1999-01-05 General Electric Company Automatic transmission of legacy system data
US5815149A (en) * 1997-02-19 1998-09-29 Unisys Corp. Method for generating code for modifying existing event routines for controls on a form
US5787433A (en) 1997-03-17 1998-07-28 International Business Machines Corporation Method and system for remapping an existing database to a new database system
US6490594B1 (en) * 1997-04-04 2002-12-03 Microsoft Corporation Database computer system with application recovery and dependency handling write cache
US6046747A (en) * 1997-08-04 2000-04-04 Hewlett-Packard Company Graphics application programming interface avoiding repetitive transfer of texture mapping data
US6052685A (en) 1997-08-13 2000-04-18 Mosaix, Inc. Integration of legacy database management systems with ODBC-compliant application programs
US6157936A (en) 1997-09-30 2000-12-05 Unisys Corp. Method for extending the hypertext markup language (HTML) to support a graphical user interface control presentation
US5974430A (en) 1997-09-30 1999-10-26 Unisys Corp. Method for dynamically embedding objects stored in a web server within HTML for display by a web browser
US5940075A (en) 1997-09-30 1999-08-17 Unisys Corp. Method for extending the hypertext markup language (HTML) to support enterprise application data binding
US6252591B1 (en) * 1997-10-10 2001-06-26 International Business Machines Corp. Method for mapping a text-oriented user interface to a graphics user interface by means of a class library
US6542909B1 (en) * 1998-06-30 2003-04-01 Emc Corporation System for determining mapping of logical objects in a computer system
US6329985B1 (en) * 1998-06-30 2001-12-11 Emc Corporation Method and apparatus for graphically displaying mapping of a logical object
US6385626B1 (en) * 1998-11-19 2002-05-07 Emc Corporation Method and apparatus for identifying changes to a logical object based on changes to the logical object at physical level
US6510468B1 (en) * 1999-01-22 2003-01-21 Micro Focus International Limited Adaptively transforming data from a first computer program for use in a second computer program
US6434681B1 (en) * 1999-12-02 2002-08-13 Emc Corporation Snapshot copy facility for a data storage system permitting continued host read/write access
US6341341B1 (en) * 1999-12-16 2002-01-22 Adaptec, Inc. System and method for disk control with snapshot feature including read-write snapshot half

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0116720A2 *

Also Published As

Publication number Publication date
WO2001016720A2 (fr) 2001-03-08
AU6947000A (en) 2001-03-26
WO2001016720A3 (fr) 2001-10-18
US6836780B1 (en) 2004-12-28

Similar Documents

Publication Publication Date Title
US6836780B1 (en) Method and system for accessing data in legacy applications
US5991534A (en) Method and apparatus for editing a software component
US6237004B1 (en) System and method for displaying data using graphical user interface control elements
US6119079A (en) Method and structure for tokenized message logging system
US6826553B1 (en) System for providing database functions for multiple internet sources
KR101323011B1 (ko) 데이터베이스 애플리케이션에 선택 가능 기능 컨트롤을디스플레이하기 위한 명령 사용자 인터페이스
US6882353B2 (en) Transmission of locale information
US6263347B1 (en) System for linking data between computer and portable remote terminal and data linking method therefor
US20110185273A1 (en) System and method for extracting content elements from multiple Internet sources
EP0587394A1 (fr) Editeur de resources graphiques
EP1635254A1 (fr) Interface configurable pour l'achèvement des modèles
JP2006302242A (ja) コントロールパネル機能との検索可能なタスクベースのインターフェイス
JP2004500645A (ja) ビジュアルデータ形式の記憶と検索
US7526487B1 (en) Business transaction processing systems and methods
JP2001236229A (ja) 表示画面テンプレートの生成方法およびシステム
EP0740258A2 (fr) Système de gestion de données
US8185562B2 (en) Business object browser for business query language
US7673245B2 (en) Converting user interface panels
US5961592A (en) Screen identification system
US7139768B1 (en) OLE DB data access system with schema modification features
EP1715418A1 (fr) Interface utilisateur extensible à la base de tâches
US8375324B1 (en) Computer-implemented document manager application enabler system and method
US7000182B1 (en) assistant for creation of layouts or reports for databases
US20050235207A1 (en) Aiding value input
US6774921B1 (en) Method and apparatus for dynamically saving/restoring the properties of controls in a screen dialog

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

17P Request for examination filed

Effective date: 20020812

17Q First examination report despatched

Effective date: 20050317

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20050928