Web Response Monitor PlusPack
Script Recorder - creates a WRM transaction script by monitoring a browser session. Captures URLs and any POST data.
Details: See WRMScriptRecorder.doc for complete details.
SSL URLs - this version supports secure URLs. A separate secure version and license is no longer required.
Details: The usual RTMCServer.exe will be installed. The screening for https URLs has been removed so it will now handle those requests as well.
NTLM Support - Integrated Windows authentication is supported for web servers as well as proxy servers.
Details: Microsofts WININET interface has been added to RTMCServer to support connections to an IIS Web Server with Integrated Windows authentication (also known as NT Challenge Response). The use of this interface is controlled via a flag in the RTM configuration.
RTM Encrypted Configuration - the WRM configuration file that may contain proxy security information can now be encrypted.
Details: A RTM Configuration item has been added the WMO program group. This launches a Java GUI application to maintain the rtmcserver.ini file. If a user elects to not encrypt this file, then it may edited as usual with any text editor. If the encrypt checkbox on the GUI is selected, then the entire ini file will be encrypted and of course will then only be able to be modified via the Java application. It can be set back to clear text by un-checking the encrypt checkbox.
UserAgent variable - The User_Agent header that WRM uses to identify itself to proxy and web servers is now a variable that can be modified.
Details: A client (browser) needs to identify itself to a web server and WRM uses the following as a default.
Mozilla/3.0 (compatible; CA Web Response Monitor 4.2) We have found that some companies have configured their proxy servers to only accept requests from certain browsers. The rtmcserver.ini has a UserAgent specification that provides the ability to modify WRMs identity.
SSL version - The version of SSL to be used can be set on an individual URL or script.
Details: RTMCServer uses SSLv23 as the default version to use for https URLs. Some web servers, specifically the IBM WebSphere version of the Apache Server, require SSLv3. Adding the SSL version to the URL specification gives WRM the flexibility to be easily modified as needed.
Multipart/form-data Encoding - post data can be sent in this format.
Details: Post data from a form is usually sent using an enctype of application/x-www-form-urlencoded. Another type of encoding is multipart/form-data which is used for files and binary data. When multipart is set to yes on a WRM URL specification or in a script request, any post data is converted into this format. This was added to WRM specifically to support file uploads. See next item.
File Upload - a file can be uploaded via a mulitpart/form-data encoded post.
Details: A file can be uploaded to a web server via a mulitpart/form-data encoded post (see previous item). File uploads are not usually supported by default on a web server, this functionality has to be added/configured. IIS has an ISAPI extension DLL called the Posting Acceptor. Other back-end server processes can be used as well such as CGI, PHP, etc. WRM requires three pieces of information, the form variable name, the file name including the path, and optionally, the MIME content type such as plain/text, etc. The file must exist on the agent machine. RTMCServer reads the file before every send. The agent only keeps the file specification, not the file itself.
Page Debug - the content returned for an individual URL request can be written to a file.
Details: A debug switch has been added to the URL specification. This will result in a file being written containing the content of the returned page. It is especially useful in determining why accuracy checks are not performing as expected. These files are written in the webresponseagent directory under tngagentsbin and will have a file name equal to the URL with slashes replaced by periods.
Date Variables - scripting has built in variables that represent the day, month, 2 digit year, and 4 digit year.
Details: These variables are %%day%%, %%month%%, %%year2%%, and %%year4%%. They are updated at the start of every script execution and may be used like any other variable anywhere in a script.
Setvar Tag - scripting variables can be defined via this tag and their values set to a string, an arithmetic expression, or the output of a program/command. The values may include other script variables.
Details: In WRM 4.0, the only way to define user variables was via the parse tag which set the variable value from parsing the returned page content. The setvar tag has been added to WRM scripting to support creating variables with any value a user wishes. The syntax of this tag is variable=expression. For example:
Anywhere in the script that %%var1%% is specified will now have testvalue substituted for it. The setvar tag can contain other variables as well so it can be used to increment a variable or combine variables. For example:
<setvar>var1=%%day%% + 1</setvar>
will result in a variable var1 with a value of the day incremented by 1. External programs or scripts may also be used to assign values to a variable. The process specified on the setvar tag will be executed and whatever is written to stdout will be used as the value for that variable. For example:
<setvar>var1=exec(cmd.exe /c testext.bat)</setvar>
Every time var1 is evaluated, testext.bat will be executed and the resulting stdout will be redirected to a file which WRM then reads to get the value to use for var1. The files are written to the webresponseagent directory with a file name of scriptname.variablename.
WRM will wait 2 seconds for the process to execute. If more time is required, an optional timeout value in seconds can be specified in the setvar tag.
<setvar>var1=exec(c:longprogram.exe),timeout=5</setvar> If the timeout has expired and no value is found, WRM will attempt to kill the running process.
Cookie Tag - cookies can be defined in a script to be sent on a request.
Details: Some web applications use browser scripting to create a cookie dynamically. The normal cookie processing in WRM has no way of handling this. This tag can be used to set a cookie to be included with a request.
<cookie>cookiename=cookievalue; path=path; domain=domain;</cookie> Multiple cookie tags may be specified. The path and domain are optional. If not specified, the path and domain of the request it is set with will be used. When a cookie is set in a request, it is in effect for the remainder of the script, subject to usual path and domain control.
Script Editor - The script editor dialogs have been updated to include all of the new functionality pertaining to scripts.
Multiple Traps - a script can now send multiple traps.
Details: WRM 4.0 only allowed for one sendtrap tag to be in effect within a request. This restriction has been removed so that multiple traps may be specified within a request.
<request> <url>www.cai.com</url> <if>%%respstatus%%=critical</endif> <then> <sendtrap>first trap message</sendtrap> <sendtrap>second trap message</sendtrap> </then> </request>
RTM logging - RTMCServer logging in debug mode has been expanded.
Details: When RTMCServer is started with a -d argument, a debugging trace file is created. Level2 has created a special version of RTM that they have used for prior releases and their log messages have been added to WRM 4.2.
Large Post Data - post data larger than 1k would crash the agent. There is no longer any limitation.
Null Cookies - cookies set to null values were still being sent on a request.
First URL Cookies - cookies were not saved if they were set on the first reply and that reply was redirected.
Duplicate Cookie - a cookie with no specified path was not saved if it was set after a cookie with the same name that had a path.
Null Request - a request that did not contain a URL crashed the agent.
Updating Scripts - when a script was updated in the agent after items in the script were deleted, the deleted items would still be in effect in the agent.
This is the Plus Pack install for Web Response Monitor. It will upgrade an existing WRM install from Web Management Option 4.0, MasterIT 4.0, or Unicenter Management for Web Servers 4.1.
The install consists of three components.
The Agent component consists of the agent and should be installed on the existing agent machine.
The Console component consists of the agent interface and should be installed on the Worldview machine.
The Manager consists of the DSM policies and should be installed on the Distributed State Machine.
Download Plus Pack now. (17.1 MB)