Handling Emulators with SecureLogin
Novell Cool Solutions: Feature
By David Guest
Digg This -
Posted: 4 Nov 2005
SecureLogin provides the ability to interact with Windows, Web, and Terminal Emulation applications. While the Windows applications are more or less straightforward, there is little information on how to handle applications using the various emulators.
This document will provide an approach to developing the script and handling the issues that are faced with the various emulator types.
There are four types of emulator that can be used with SecureLogin:
- Advanced Generic
- HLLAPI (High Level Language Application Programming Interface)
- DDE (Dynamic Data Exchange)
These can be put into two different groups, which are handled differently by the script. The first type of emulators is the Generic and Advanced Generic emulator. These use screen-scraping technology to determine what is being displayed on the emulator screen. The other group of emulators is HLLAPI and DDE; here, the script can interact more specifically with the emulation screen and can be much more specific with the actions it performs.
Screen Scrape - Generic Emulators
Using Screen Scraping presents a number of issues with the behavior of the script and the emulator. The screen scrape uses a "Select All + Copy" function to place all of the screen data into the buffer which SecureLogin reads.
If you have ever used a word processor and done a "Select All" you will have seen that the complete document is inverted - instead of black on white, the image on the screen becomes white on black. The same behavior occurs when the emulator is running. Each time the script performs a ReadText or a WaitForText, the screen inverts. This produces a blink on the emulator screen. While this is necessary for the script to function, it is not pleasant for the user.
To get around this, the SplashScreen commands (BeginSplashScreen and EndSplashScreen) are used. This means that the script must finish and have the SplashScreen removed before the user can interact with the application.
To write a script for this, it is necessary to determine all of the messages that can be seen before the actual application starts, as well as some necessary information from the initial page of the application. A loop is employed to ensure the handling of all the screen information, up to the point when the application itself starts.
The problem here is that if the user has a menu option that allows a change of password, SecureLogin will not be able to "see" the change and remember the password.
Looking at a sample script shows all of the features of a standard Emulator script. The normal script that is used is very simplistic:
WaitForText "ogin:" Type $Username Type @E WaitForText "assword:" Type $Password Type @E
Here we look for the text "ogin" on the screen and then put the Username in, then wait for "assword:" and insert the Password.
As an aside - one of the questions that is often asked is why is it "ogin:" and not "Login:"? The reason for this comes back to the use of Generic emulators. What we are doing is screen-scrape based, in many cases, using an offset that tells SecureLogin where on the emulator window to start to do the scraping. It is very easy to get this wrong (or even to use a different resolution) and to miss part, or all, of the screen. By using the short form of the word we are assuring that SecureLogin can "see" and react to it.
A more complex script for an emulator would be this:
WaitForText ?ogin:? Type $Username Type @E WaitForText ?assword:? Type $Password Type @E Repeat # Check for failed login Increment ?ScreenCount If ?ScreenCount eq 1 If -Text "ogin incorrect" Increment ?RunCount if ?RunCount eq 1 DisplayVariables "Please re-enter your ID and Password? Type $Username Type @E Delay 500 WaitForText "assword:" Type $Password Type @E Endif EndIf #Check for password expiry If -Text "New Password:" If ?PasswordChange eq <notset> Set ?PasswordChange 1 ChangePassword ?NewPassword "Your password must be changed." Type ?NewPassword Type @E Endif Endif EndIf If ?PasswordChange eq 1 If -Text "e-enter new Password:" Type ?NewPassword Type @E Endif Endif If -Text "Press RETURN key to continue ..." Type @E Endif If -Text "MENU" EndSplashScreen if ?PasswordChange eq 1 Set $Password ?NewPassword Set ?NewPassword <notset> endif Set ?PasswordChange <notset> Set ?ScreenCount <notset> break endif EndRepeat EndSplashScreen if ?PasswordChange eq 1 Set $Password ?NewPassword Set ?NewPassword <notset> endif Set ?PasswordChange <notset> Set ?ScreenCount <notset> break endif EndRepeat
This script looks for a lot of information coming from the emulator. Closer examination of the script shows that it starts with normal, basic authentication. The loop is then started, and the first thing that is looked for is login failure. The script then looks for password expiry and handles it as a sequence of logical steps. A counter is used to ensure that the correct instance of the "New Password" message that is seen.
Finally, the script looks for the text "MENU" on the screen. When this is seen, the application menu has been loaded, and SecureLogin should close and return control to the user. The splash screen is closed at this point.
Dynamic Read Emulation - HLLAPI and DDE
One of the advantages of the HLLAPI and DDE emulators is their ability to directly read specific portions of the screen without affecting the user operation. This means that the script can continue to run while the user is using the application. This allows the script to handle more specific issues - specifically, the password change within an application.In order for this to happen, the script uses the ReadText command. This has the following syntax:
ReadText ?Variable Column Row
The use of HLLAPI comes from the days of the IBM Mainframe and Mini computers, the S/390, the AS400, and the System 34, 36, and 38. These had, in some cases, the ability to run macros based on the information on the screen. This functionality was added in to the software-based emulators and, when configured correctly, can be used to let SecureLogin handle the same information.
For a guide to configuring an HLLAPI emulator please see:
With IBM S/390 systems, the emulation screen displays system messages in the same place on every screen of data. When this is visible, SecureLogin can read the message and determine its action correctly.
The following screen shows the specific point on the emulator screen that we need to be aware of.
Figure - Emulator screenWhen the script itself is considered, the messages to be looked for are the same as those used in generic emulators, that is:
- Password (Failure, Expiry)
- MOTD (Message of the Day)
However, the script itself gives much more flexibility. Because we can read specific portions of the screen there is no screen "blink." This means that the script can continue to run while the user is interacting with the emulator.
An example of an HLLAPI script follows:
Local ?runcount set ?runcount 0 repeat WaitForText "Request ====>" if ?runcount eq 0 repeat readtext ?message 9 2 2 If ?Message eq ?NSL567001? call DoLogon EndIf if ?message eq "NSL564211" displayvariables "The Userid and/or Password is incorrect. Please re-enter them" endif if ?message eq "NSL564151" messagebox "Your password has expired. Please change it" call chpassword endif if ?message eq "NSL564181" messagebox "Your account has been disabled. Please contact the helpdesk" killapp emulator.exe endscript endif increment ?runcount delay 500 endrepeat else messagebox -yesno ?result "You have logged out. Would you like to log in again?" if ?result eq "Yes" call DoLogon EndIf EndIf Sub DoLogon Type $Username Type @E Delay 250 Type $Password Type @E EndSub
Although this script is incomplete (I have removed some of the subroutines to make it easier to read), it handles a number of issues. Each action is based on the message that is displayed at Line 2, column 2. When the message is one that needs to be dealt with, the script kicks in to action, performs a specific task, and then continues to run in the background.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com