Dedicate a workstation or a server on which to create/develop the scripts. The development machine should ideally match the machines that will be running the finished scripts. Deploy a robot to the development machine, then deploy the e2e_appmon_dev probe to that robot. The dev package includes the installation to the NimRecorder which is a Windows thick client application. A successful install will add a folder under the Start ->All Programs -> Nimsoft Monitoring menu named E2E Scripting. Within that folder you will find the Script Editor menu item to launch the Editor/Recorder. The editor is the tool you use to record the initial scripts and to edit and enhance them so that they are a robust production ready script. The probe interface is where e2e 'profiles' are created to run completed scripts automatically. It can also be used to create script deployment packages in the archive. NOTE: The hub to which the robot is connected must have the distsrv probe on it for this feature to work. The created script package can then be moved to the primary archive as needed. There is a lot of preparation and work that goes into making a successful script. You should review the Nimbus-functions.src file that is included in the probe deployment (you can use the Script Editor to open and review the file) for all the UIM API functions such as sending QoS metrics, alarms, and ensuring CI metric definitions are in place so the e2e metrics are linked to the robot running the script in the USM portlet.
- UIM (any version)
- e2e_appmon_dev probe (any version)
Detailed requirements for running e2e transactions:
No one can RDP/login to the workstation as it needs to run undisturbed. e2e takes over the desktop (console 0/Winsta0). You are able to see/watch your running e2e transaction via remote control software such as VNC/Real VNC. Other remote viewers such as logmein/Lan Manager are not as well tested so we cannot guarantee behavior. You can see/watch the transaction via VNC/Real VNC but you shouldn't have to keep the session open to successfully run the script. As you may know you can determine if the scripts are running successfully via the e2e GUI status.
Do NOT use Remote desktop as it interferes with the interactive session. Since Vista, Windows makes a difference between Windows stations and desktops. The interactive window station, Winsta0, is the only window station that can display a user interface or receive user input. It is assigned to the logon session of the interactive user. So when Windows is logged out or locked or when you disconnect from a Remote session, the session still exists but not the interactive window station. So any interactive script that you try to run will fail. And when you minimize a Remote desktop session, the session is locked and so any interactive script will stop running properly. Note that you can login via RDP to record your synthetic transaction script but you must not leave the user logged in when you're finished - you must logoff the system.
You must install a Nimsoft Robot on the dedicated transaction workstation/desktop and then deploy the e2e_appmon_dev probe there.
Use the e2e_appmon_dev probe in all cases (and not just e2e_appmon). This is for convenience since if you have any trouble recording a script on one system, e.g., monitor and you try running it on the 2nd system and it fails for some reason, you can use the script editor to make modifications. You can do this while you're accessing any system since you have access to the full e2e development workbench with e2e_appmon_dev probe versus just e2e_appmon.
- Both systems need to be identical - for example, 1024x768 especially if you are copying image files to other dedicated workstations to run the scripts form a different location. Keep resolution the same on the workstations and within VNC session when recording scripts.
- e2e_appmon_dev user:
- You will need a login user name and password on the computer where the probe script(s) are run. userid/pwd entered in the profile must be for a domain account or local user account with full access and admin privileges as well as full privileges to the applications that need to be monitored..
You should create an account(s) that you can use to login to the application(s).
- Once the script/scripts are recorded, you can copy the .src, .lst, and .rob files as well as any .bmp/image files from the system where the scripts were recorded to the other system(s) you want to run the scripts from - other dedicated workstations at other physical locations for instance. The files must be stored in ...e2escripting\scripts. We can create and use a custom probe for that so you can copy the files via drag and drop. Note that later versions of e2e allow you to configure this within the probe.
You can deploy your remote_control probe on the hub/local system (requires VNC server on the workstation/laptop system) OR simply install VNC server on the remote system and VNC client on your primary hub if you want to watch the transactions execute. Some customers choose to use other remote control software such as LAN Manager, TightVNC but RealVNC seems to work best. Note that the old remote_control probe (internally developed) may no longer work with more recent versions of e2e.
- Security considerations for highly secured environment: You must keep the workstation desktop 'open' by disabling the screensaver, timeouts, etc. Note that you can use VMware to keep the Guest OS open but keep the physical machine locked. Other considerations for highly-secure environments include removing the monitor/keyboard, locking the rack/physical space.
Other Notes/Best Practices:
An "about blank" page is seen by IE8/IE9 under Windows 7 as a suspicious page. So avoid using StartBrowser("IE","about blank"), prefer to use StartBrowser("IE","www.my_site.com").
Use ClickOnBitmap (for mouse clicks not correctly executed)
This happens on software where options are not in the menus but in icons. WinTask does not access by object icons.
Two functions for addressing this problem:
Use the e2e wizard (double-click on Capture Functions->ClickOnBitmap) via the e2e Help Menu when in the e2e script editor to walk through the process and automatically generate the correct lines in the script. Hint use "somewhere in a defined area" in the page and define enough area to locate the object/window you want.
- Use e2e_appmon_dev version 2.20 or higher for 64-bit OS environments.
- In e2e_appmon_dev v 2.0 or higher, you can use IE10/11
- Chrome version 32
- Firefox (any version starting at version 10 or higher)
- The WTBho add on may be running in limited mode and can’t access the DOM (document object model) This can disable the proper functionality for text synchronization.
For any errors encountered during script execution check Articles.
According to WinTask Support note that since Windows 7, you can no longer use Pause and UseWindow when working on web pages.
OCR recognition: Even if it works for a while it can stop working.
This function's unreliability lies within WinTask itself or due to idiosyncrasies of Windows environments and is NOT reliable/consistent based on my experience in he field and in testing. Use either ClickOnBitmap or Sync on Image function instead.
Also note that as of the latest WinTask version, you cannot use "Wait for text" as it is no longer useable. As per the Help file in:
In the Remarks section it states:
"If the text to search is in a new window, prefer UseWindow function to wait for this new window (and so new text in this new window). Do not use a Pause until text to detect that a web page has finished to load, a UsePage is enough. Note too that within Internet Explorer, only a pause until OCR text can be used."
You can access the Help from the robot where e2e is deployed or you can access the basic WinTask functions online at:
For examples search using the Navigation menu on the left side of your browser:
Capturing Data in a Web Page
Capturing Data Using OCR
'Wait for Image' or even Wait for OCR Text example is available - just search on Wait for Image and note that the font is a bit hard to see on the left-side since its blue on blue.
See also nimWaitForWebContents in the Help file if you want to include that as a checkpoint within the NimRecorder script enabling the e2e_appmon probe to measure intermediate times in the process in addition to the total runtime of the script.
Other script example:
captured_string$ has the text captured from the indicated cell. Then an if-then-else statement can help as per below.
'UsePage("Cisco Unified CCX Serviceability")
ret = CaptureHTML("DIV[CONTENT='SHUTDOWN', INDEX='1']",captured_string$)
If captured_string$ = “SHUTDOWN” then
<generate alarm, do whatever else>
'UsePage("Cisco Unified CCX Serviceability")
ret = CaptureHTML("DIV[CONTENT='PARTIAL SERVICE', INDEX='1']",captured_string$)
If captured_string$ = “PARTIAL SERVICE” then
<generate alarm, do whatever else>
Your script continues from here…