RadView Software How-to

Building a Performance Testing Framework

Development frameworks have been around for years, and have served
as a catalyst for a more efficient development process. Next comes the
question of how to improve the efficiency of performance testing?

In this document will show how to build a testing framework that

improves the overall cost-effectiveness of performance testing with
WebLOAD.

April 2007

1
Table of Contents

Overview ..................................................................................................................... 3 
The Need For A Framework................................................................................. 3 
Load Testing Framework Architecture ............................................................ 5 
Framework Based Testing.................................................................................... 7 
The Complete Sample ........................................................................................... 9 
Using WebLOAD To Build Your Testing Framework ................................... 9 
Building the System API Proxy Layer .......................................................... 9 
Building The API Abstraction Layer ............................................................ 10 
How to Deploy the Framework in Your Testing Lab ................................ 11 
Determining The Included File Location ................................................... 12 
Distributing the Files To The Load Generator Machines .................... 12 
Change Management ........................................................................................... 12 
Future Enhancements.......................................................................................... 13 
Class browsing.................................................................................................... 13 
Include files intellisense ................................................................................. 14 
Multiple file editing ........................................................................................... 14 
Appendix – Using Excel As A Data Source For Testing Parameters .. 14 
Appendix – The CODE… ...................................................................................... 15 
The Agenda .......................................................................................................... 15 
The FrameworkSample-AbsAPI.js file ....................................................... 15 
The FrameworkSample-ProxyAPI.js file ................................................... 15 
The ExcelParamFunction.js File ................................................................... 16 

2
Overview
Load testing is a potentially ambiguous term with many definitions. We at
RadView define load testing by its goals: To guarantee the performance,
scalability and reliability of internet applications. As such, an enterprise
choosing our solutions for load testing shall find features that address
these needs.
By “performance”
we refer to testing
the response
time of a given
request while the
system is under
load. By
“scalability” we
refer to testing the
system in
response to
growing
numbers of
requests. Finally,
“reliability” is
about verifying
that the
response remains correct even under load.

When our support professionals work with development teams at large

enterprises , they are often asked how to take load testing to the next
step and lower the total cost of ownership (TCO) of the load testing
process. This document covers our load testing framework architecture
and demonstrates how an enterprise can leverage such a framework to
get faster and better results from its load testing team.

The Need For A Framework

Development frameworks have been around for years, as a means for
standardization and acceleration of the development process. The same
reasoning applies to testing frameworks. Yet, in the past, many
enterprises questioned its cost effectiveness as they questioned the need
for test automation at all.

While test automation of functional testing can be substituted by manual

testing, load testing is always done with automated tools or not done at
all. The question of how to make load testing cost effective is still valid
and this document will show how a load testing framework can be a
key element in justifying its cost.

Load testing architecture divides the system into three parts. First, the
client GUI application, usually implemented as a browser application
using static HTML or a rich internet application such as Ajax applications.

3
Second, is the internet protocol available to access the system under
test, usually HTTP/HTTPS but may also include multimedia protocols such
as RTP/RTSP or “Web 2.0” protocols such as SOAP/XML or RSS over HTTP.
Third and last is the system under test (SUT) which is the subject of our
load testing effort.

This leads to an important distinction we have to make between functional

testing and load testing. While both the client and the Server are tested
together in functional testing, each of these components is tested
separately during load testing. Adding the client side load into the
equation would skew the results because the client processing depends on
the client machine (CPU & Memory) which is not simulated using the
virtual client load testing model1.

Figure 1 - Load testing architecture

System under test

System
API

Internet protocols

Client GUI System API calls SUT processing

application using internet
protocols

The system API is a new layer that must be mentioned, which is now
easier to describe in the context of the growing adoption of service
oriented architecture (SOA). In the SOA world the system API are the set
of services offered by different sub systems and consumed by the client
application, usually in the form of web services. System APIs are of course
not limited to the implementation of SOA web services. Any reasonably
stable system has some form of separation between the GUI and the
business logic, so the business logic functions can be accessed via a stable
System API.

Since API’s are considered more stable than the trendy GUI application
consuming them, a method of load testing which is not affected by the
ever changing GUI application would create significant cost savings.

This is where the LOAD testing framework comes into play. It enables
repeatedly building new load test agendas without recording a new script,
eliminating the additional work that may have been caused by changes to
the UI. The Load Testing Framework avoids dependence on the UI by
directly calling the pre-defined system APIs, like any other callable object
within your JavaScript code. The agenda accesses an external resource to

1
 A lot has been said on the need for client side load testing with regard to the growing use of 
client side code like Ajax technology, but still the argument for separating it from the server load 
testing is still valid and if we consider all the new mash‐up application created by consuming 
different services into a “bigger” application, the need for separate service testing becomes even 
clearer.   

4
get the parameters for each of the calls. A detailed explanation of the
framework architecture is provided in the next section.

We will show how the framework can also be resilient to changes in the
APIs themselves, acknowledging that backend systems are also prone to
change, albeit less often. A detailed description of how the framework
handles such changes is listed below, minimizing the effect on the
investment that was made in writing the test code itself.

Load Testing Framework Architecture

WebLOAD includes all the required elements for building a custom testing
framework and is built using a layered architecture approach. In this
section you will read about the different components comprising the
framework. Some are provided as part of WebLOAD support for the
enterprise, others are developed by the load testing team as an enterprise
specific framework, while the rest are testing agendas developed for
different load testing cycles. The following diagram presents the different
layers of such a framework; a detailed description for each part is
provided below.

WebLOAD IDE framework System API

Parameterization support

System under test

Database Txt Txt

Parameters WebLOAD API Abstraction Sys API

support layer agenda layer layer Proxy layer

Sys call C
Txt interface

Txt Sys call B

interface

Test Agenda
Database Sys call A
interface

System under test with System API – The system being tested is not
itself part of the framework, nor is anything that has to be installed on it.
It is included as part of the diagram to show that the framework accesses
the listed, pre-defined system API.

5
System API proxy layer – This layer represent a static entry point for
each of the system API. This layer is built by the testing team as a one-
time effort and serves as a basis for all future load testing of the system
and the services provided by that system. Each entry point includes only a
place holder for parameters, not the specific parameters for each call.
The following shows sample code for a System API proxy file:

/***** WLIDE - JavaScript - ID:4 *****/

// WebLoad IDE js file
function CelsiusToFahrenheit(Celsius)
{
/***** WLIDE - URL :
http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusToFahrenheit - ID:2 *****/
wlHttp.Header["Referer"] =
"http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit"
wlHttp.ContentType = "application/x-www-form-urlencoded"
wlHttp.FormData["Celsius"] = Celsius
wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusTo
Fahrenheit")
return document.wlXmls[0].documentElement.firstChild.nodeValue
}
function FahrenheitToCelsius(Fahrenheit)
{
/***** WLIDE - URL :
http://www.w3schools.com/webservices/tempconvert.asmx/FahrenheitToCelsius - ID:3 *****/
wlHttp.Header["Referer"] =
"http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius"
wlHttp.ContentType = "application/x-www-form-urlencoded"
wlHttp.FormData["Fahrenheit"] = Fahrenheit
wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/Fahrenhe
itToCelsius")
return document.wlXmls[0].documentElement.firstChild.nodeValue
}

API Abstraction layer – This layer serves two purposes. First, it

provides objects such as interfaces for the system services and makes
them easily accessible from the agenda. The second purpose is to provide
an abstraction layer for changes in the system API in case they happen. A
more detailed description on how to handle changes in the framework is
given in section 0. Advanced users can use this layer to achieve better
modularity in their test code by wrapping little static system calls in the
same object or by using this object for state management between calls.
Since this layer is implemented using JavaScript language, you can take
advantage of the object oriented characteristics of the language such as
templates and others.

The following shows sample code for an API abstraction file:

/***** WLIDE - JavaScript - ID:2 *****/

IncludeFile("FrameworkSample-ProxyAPI.js", WLExecuteScript)

function TemperatureConvertor()
{
this.ConvertCelsiusToFahrenheit = function (Celsius)
{
try {
return CelsiusToFahrenheit(Celsius)
} catch (e)
{

6
 warningMessage("CelsiusToFahrenheit returned an error")
}
}
this.ConvertFahrenheitToCelsius = function (Fahrenheit)
{
try {
return FahrenheitToCelsius(Fahrenheit)
} catch (e)
{
warningMessage("FahrenheitToCelsius returned an error")
}
}
}

WebLOAD agenda layer – This is the load test agenda written by the
load testing team. The agenda contains the test code itself, implementing
the test logic and setting the specific parameters for each function call.
The following shows sample code for an agenda file:

function InitAgenda()
{

IncludeFile("FrameworkSample-AbsAPI.js", WLExecuteScript);
}

var MyConvertorServices = new TemperatureConvertor ()

Far = MyConvertorServices.ConvertCelsiusToFahrenheit(30)
Cel = MyConvertorServices.ConvertFahrenheitToCelsius(86)

InfoMessage("30 degrees celsius are " + Far + " fahrenheit")

InfoMessage("86 degrees fahrenheit are " + Cel + " celsius")

Parameterization support – The parameterization support layer is part

of the WebLOAD offering which allows the tester to read parameters from
different data sources, including text files, excel files and databases. This
layer also allows the tester to write their own plug-ins for accessing
parameters during runtime.

Framework Based Testing

This section provides a step by step guide for writing an agenda based on
an existing framework. I will use a sample web service available on the
web which provides temperature conversion services. Throughout this
document the sample uses Web Services as the protocol between the
client and the server. However, non formal API such as XML over Http or
any messaging protocol can be used just the same.

We start by writing the agenda. Since we have the framework in place we

do not have to start with recording a session. Rather, we can go directly
to edit modeusing either JavaScript mode or visual edit mode. Let’s test
the ConvertCelsiusToFahrenheit service using parameters taken from a global
Excel input file. To do so we include the API abstraction layer file in our
agenda which makes the ConvertCelsiusToFahrenheit “known” to WebLOAD
and we declare the converter object:

7
 function InitAgenda()
{

IncludeFile("FrameworkSample-AbsAPI.js", WLExecuteScript);
}

var MyConvertorServices = new TemperatureConvertor ()

Now we will call our ConvertCelsiusToFahrenheit service which takes

the Celsius argument as an input parameter and returns the result in
Fahrenheit. In this sample we are still using the hard coded parameter
value (“30”) as input. Later we will replace it with an external parameter
taken from an Excel file.

Far = MyConvertorServices.ConvertCelsiusToFahrenheit(30)

InfoMessage("30 degrees celsius are " + Far + " fahrenheit")

Note that although the ConvertCelsiusToFahrenheit method

encapsulates an HTTP call to the server, the structure of the method, the
HTTP setting and all other technical issues are hidden from the agenda
author.

As with any good load test we will want to replace the hard coded
parameter (in our example, the Celsius argument) with a parameter taken
from an external source. Excel is an excellent source for storing test
parameters, since it is tabular, easy to use and provides good connectivity
to enterprise data sources2. In the following example we created a
JavaScript object which reads the lines from a given Excel file and stores
them in memory while providing an integrator function to get the
parameter. To simplify the code, no error handling is implemented here3.

function ReadExcelParameters(FileFullPath)
{
var xlApp = new ActiveXObject("Excel.Application");
var xlBook= xlApp.Workbooks.Open(FileFullPath);
xlBook.worksheets("Sheet1").activate;
var xlSheet = xlBook.activeSheet;
xlApp.visible = false;
var x=0 ;
for (x = 1;x<(xlSheet.UsedRange.Rows.Count+1);x++)
{
RowColData[x] = xlSheet.cells(x,1).value ;
}
xlBook.Close();
xlApp.Quit();
}

2
 Although you can read parameter from an external data source directly using your customer 
COM/Java object or using excel external data source connection, using static data stored in excel 
has several advantages, mainly it provides you with predictable results – meaning you can repeat 
your test over and over again knowing that the input parameters have not changed and not 
affected your results. More about Excel as a parameter repository see the appendix.   
3
 Note that in order for this sample to run Excel has to installed on the load generator machine. 

8
The Complete Sample
The following section lists the complete code of the sample for the above
scenario. This sample is based on the sample web service available at
http://www.w3schools.com/webservices/tempconvert.asmx.
As you can see the test code writing in the agenda itself is very clean and
simple which makes it easy to maintain. This sample is comprised of one
agenda file (showed below) which references both the
FrameworkSample-AbsAPI.js (which is the abstraction layer file) and
ExcelParamFunction.js, a helper file with the Excel parameter
extraction object . This sample also assumes you have an Excel file on
your c:\RadView\Input drive named TempDegrees.xls with a list of the
10 parameters which are to be converted to Fahrenheit.

function InitAgenda()
{
IncludeFile("FrameworkSample-AbsAPI.js")
IncludeFile("ExcelParamFunction.js")
RowColData = new Array // To hold the temperature degrees values contained in
the Excel file
}
function InitClient()
{
ReadExcelParameters("C:\\RadView\\Input\\TempDegrees.xls")
}
for (i=1;i<RowColData.length;i++)
{
TemperatureConvertor(RowColData[i])
}

Using WebLOAD To Build Your Testing Framework

So far we have talked about the need for the framework and what
framework based testing looks like. In this section we will describe how to
build the enterprise testing framework using different WebLOAD features.

Building the System API Proxy Layer

The first step in this process is to build the system API proxy layer. This
could be done with a systematic approach where we build the whole layer
at once or with an ad hoc approach where we build the different API calls
on demand. We start by listing the different services we want to build,
usually from a given list supported by the back end system. We then
need a client application consuming these services. The client application
can be the actual client application used by the enterprise, if one exists, or
a test client application that was used by the service developers for unit
testing their service. We use the WebLOAD recording feature on this client
application to record each of its services at a time in a separate agenda
file. The result will be a recording of an HTTP call for a specific service
with specific parameters.

The following code shows a sample for such a recorded agenda:

9
 /***** WLIDE - URL :
http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit - ID:2
*****/
//This is the main test page of our web services
wlGlobals.GetFrames = false
wlHttp.Header["Referer"] =
"http://www.w3schools.com/webservices/tempconvert.asmx"
wlHttp.FormData["op"] = "CelsiusToFahrenheit"
wlHttp.Get("http://www.w3schools.com/webservices/tempconvert.asmx")

/***** WLIDE - Sleep - ID:3 *****/

Sleep(6149)

/***** WLIDE - URL :

http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusToFahrenheit - ID:4 *****/
//This is the call to one of the web services
wlHttp.Header["Referer"] =
"http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit"
wlHttp.ContentType = "application/x-www-form-urlencoded"
wlHttp.FormData["Celsius"] = "30" //Note the hard coded parameter in the
recording
wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusTo
Fahrenheit")

We now have to turn this specific agenda into a framework agenda. We

do this by wrapping the call with a function and extracting all the
parameters as arguments to that function. We also need to extract the
result from the response, which in our sample is the first element in the
XML. Once we are done we should use the SAVE AS option in the file
menu to save this file in the include directory (see deployment issues later
in this document).

The following code shows the recorded agenda converted to a function:

function CelsiusToFahrenheit(Celsius)
{
wlGlobals.GetFrames = false
wlHttp.Header["Referer"] =
"http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit"
wlHttp.ContentType = "application/x-www-form-urlencoded"
wlHttp.FormData["Celsius"] = Celsius //Note the hard coded parameter replaced
with function param
wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusTo
Fahrenheit")
//Extract the results
return document.wlXmls[0].documentElement.firstChild.nodeValue
}

We are done! We now have the first service implemented as a system API
proxy agenda. We now repeat this process for every service we want to
implement.

Building The API Abstraction Layer

We move on now to building the second layer, which is the API abstraction
layer. WebLOAD is based on open standards of web development and uses
JavaScript as its main programming language. As an Object Oriented
Programming (OOP) language, JavaScript allows you to define your own
objects and make your own variable types.

10
All that’s required to build the API abstraction layer is to declare an object
with a method and to implement it in a separate agenda file.
We will start by creating the object and defining its methods. Our object
does not need parameters during construction, so the creation of the
object is just a function with no parameters.

The following code shows the API abstraction layer object creation:

//=============================This is stored in a FrameworkSample-AbsAPI.js

/***API Abstraction layer ***/
IncludeFile("FrameworkSample-ProxyAPI.js", WLExecuteScript)

function TemperatureConvertor()
{
this.ConvertCelsiusToFahrenheit = function (Celsius)
{
try {
return CelsiusToFahrenheit(Celsius)
} catch (e)
{
warningMessage("CelsiusToFahrenheit returned an error")
}
}

As noted before this is a very simplified sample of the abstraction layer.

In its place, you can implement any object oriented design practice, for
example storing the account number between calls as a property,
reporting errors in a centralized manner etc.

How to Deploy the Framework in Your Testing Lab

Our testing framework makes use of WebLOAD’s ability to split the agenda
into different files and include them in runtime. It is important to
understand the search order WebLOAD uses when looking for a given
include file.

11
Determining The Included File Location
By default, Included Files should be in the “User Include Files” directory
specified in the “File Locations” dialog box. You may redirect the default
directory location if necessary by double clicking on the “User Include
Files” entry and specifying a new file location from the pop-up “Modify
Location” browse box. In general, WebLOAD searches for the included file
using the following search precedence:
 The load engine first looks for the included file in the default “User
Include Files” directory. If the file is not there, the file request is
handed over to WebLOAD, which searches for the file using the
following search path order:
 If a full path name has been hardcoded into the IncludeFile
command, the system searches the specified location. If the file is
not found in an explicitly coded directory, the system returns an
error code of File Not Found and will not search in any other
locations.

Note: It is not recommended to hard-code a full path name, since

the Agenda will then not be portable between different systems.
This is especially important for networks that use both Linux and
Windows systems.

 Assuming there is no hardcoded full path name in the Agenda code,

the system looks for the file in the default “User Include Files”
directory.
 If the file is not found, the system looks for the file in the current
working directory, the directory from which WebLOAD was originally
executed.
Finally, if the file is still not found, the system searches for the file
sequentially through all of the directories listed in the
Tools | Options | File Locations dialog box.

Distributing the Files To The Load Generator Machines

WebLOAD technology eliminates the need to copy the agenda or any of
the include files to the load generator machine. By placing your
framework include files in the user include file directory and specifying
them as described in the previous section, WebLOAD automatically copies
these files to the target load generator machine.

Change Management
Change management is one of the key obstacles to test automation.
Much effort was put into software engineering with object oriented design
patterns and practices all in an effort to minimize the cost of changes.
While changes in the code are somewhat acceptable, derived changes in
the test code are less acceptable. In this section we show how the
framework deals with minimizing the effect of changes and allows better
control of the change process.

12
The first step in the process is to understand where changes happen. The
most common change in an internet application are changes in the GUI
which typically result from a new design or UI fashion or due to the
changing needs of clients. By deploying a WebLOAD testing framework,
your testing remains unaffected by these types of changes, owing to the
protocol-based load testing architecture employed by WebLOAD. Since
this architecture is not based on a user emulation level, the test script
does not have to change so long as the services called by the application
are not changed. Also, since we deployed the testing framework, all of the
system APIs are already available to us with no need to record them.
Here again, we see that UI changes do not affect us.

The second type of changes are changes in the services themselves.

Changes to these services are not common and with more and more
enterprises implementing Service Oriented Architecture (SOA), these
services will become even more immutable. SOA is not another form of
object oriented design. It is an evolution of OOP and the three tier
architecture, where one of the key factors for making an implementation a
successful one are the immutable interfaces. The services interface must
be as well defined and immutable as possible, otherwise external users
(outside of the scope of your monolithic application users) will not be able
to keep up-to-date with your interface changes. However, acknowledging
that services do sometime change, it is in our interest to control the
change process as much as possible. When service calls change by the
addition or removal of a parameter, the first part that is affected is the
transaction API calls layer. A new transaction has to be recorded for
the given changed service, which does not require a big effort. The
question now is how to handle all the scripts that depended on this API
call? The framework helps us by using the JavaScript interface layer to
control the change. The object in this layer gets the call from the agenda
and passes it to the underlying function API layer. Inside this object we
can add a default value for the missing parameter, or cut off the extra
parameter passed from the agenda layer. Although the API has changed,
we can keep our entire agenda repository running by changing only two
files. Obviously, a log call can be added in the JavaScript object to log
each agenda that uses the “old interface” in order to help the testing team
to gradually migrate the test code without breaking it first.

Future Enhancements
This document demonstrated how WebLOAD 8.0 can be used to build a
testing framework, improving the process of your performance testing
team, thus reducing the overall TCO. In future versions of WebLOAD we
are considering a few new features which will improve the productivity of
framework based testing even more. Here are some examples of areas
under development.

Class browsing
As noted in this document the framework makes heavy use of include
files. A future version of WebLOAD may include some type of object
browser which will make navigation through the different framework
classes a much easier task.

13
Include files intellisense
As with other development environments, it would be very convenient if
once we declare an object or function in our JavaScript library it would
also show up in our editor with intellisense support.

Multiple file editing

Another useful improvement for WebLOAD IDE would be the capability for
multiple file editing, eliminating the need to close and open each file over
again. Although this task is relevant mainly during the framework
development process, other testing tasks might benefit from it as well.

Appendix – Using Excel As A Data Source For Testing

Parameters
As noted before, Excel is a great tool for managing the test data for both
input parameters and test results. With Excel you can choose between
using constant test parameters for predictable regression tests, or
refreshing the data
whenever it is
updated by linking
an excel sheet to
an external data
source. The main
benefit of linking
to external data is
that this data can
periodically be
used in Microsoft
Office Excel
without repeatedly
copying the data,
which is an
operation that can be time-consuming. After linking to external data, you
can also automatically refresh (or update) your Excel workbooks from the
original data source whenever the data source is updated with new
information. While this is good for testing with real data from existing
systems, it has an adverse effect on the predictability of the results since
changes in the input parameters affect the results of the test. Therefore, a
good test run will include a combination of static regression tests with
some dynamic tests.

Another advantage of using Excel as a repository for the parameters is

test source code management. The Excel file can be easily saved with the
agenda file in any source control system allowing better control for the QA
team over the test environment configuration. Most projects would like to
freeze their test cases along with their code freeze of every version,
allowing them to rollback both if needed. This process is much harder to
manage if you are using an external data source directly without storing
the data in a separate file.

14
Appendix – The CODE…
Below is the code for all files used in this document

The Agenda
function InitAgenda()
{
IncludeFile("FrameworkSample-AbsAPI.js")
IncludeFile("ExcelParamFunction.js")
RowColData = new Array // To hold the temperature degrees values contained in the Excel
file
}
function InitClient()
{
ReadExcelParameters("C:\\RadView\\Input\\TempDegrees.xls")
}
for (i=1;i<RowColData.length;i++)
{
TemperatureConvertor(RowColData[i])
}

The FrameworkSample-AbsAPI.js file

IncludeFile("FrameworkSample-ProxyAPI.js", WLExecuteScript);
function TemperatureConvertor()
{
this.ConvertCelsiusToFahrenheit = function (Celsius)
{
try {
return CelsiusToFahrenheit(Celsius);
} catch (e)
{
warningMessage("CelsiusToFahrenheit returned an error");
}
}
this.ConvertFahrenheitToCelsius = function (Fahrenheit)
{
try {
return FahrenheitToCelsius(Fahrenheit);
} catch (e)
{
warningMessage("FahrenheitToCelsius returned an error");
}
}
}

The FrameworkSample-ProxyAPI.js file

function CelsiusToFahrenheit(Celsius)
{
/***** WLIDE - URL :
http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusToFahrenheit - ID:2 *****/
wlHttp.Header["Referer"] =
"http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit"
wlHttp.ContentType = "application/x-www-form-urlencoded"
wlHttp.FormData["Celsius"] = Celsius
wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusToFahrenhei
t")
return document.wlXmls[0].documentElement.firstChild.nodeValue
}
function FahrenheitToCelsius(Fahrenheit)
{
/***** WLIDE - URL :
http://www.w3schools.com/webservices/tempconvert.asmx/FahrenheitToCelsius - ID:3 *****/
wlHttp.Header["Referer"] =
"http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius"
wlHttp.ContentType = "application/x-www-form-urlencoded"

15
 wlHttp.FormData["Fahrenheit"] = Fahrenheit
wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/FahrenheitToCelsiu
s")
return document.wlXmls[0].documentElement.firstChild.nodeValue
}

The ExcelParamFunction.js File

function ReadExcelParameters(FileFullPath)
{
var xlApp = new ActiveXObject("Excel.Application");
var xlBook= xlApp.Workbooks.Open(FileFullPath);
xlBook.worksheets("Sheet1").activate;
var xlSheet = xlBook.activeSheet;
xlApp.visible = false;
var x=0 ;
for (x = 1;x<(xlSheet.UsedRange.Rows.Count+1);x++)
{
RowColData[x] = xlSheet.cells(x,1).value ;
}
xlBook.Close();
xlApp.Quit();

Contact Information:

North America RadView Software Inc.

111 Deerwood Road, Suite: 200
San Ramon, California 94583

Phone: 925-831-4808
Fax: 925-831-4807
Toll Free: 1-888-RadView

United Kingdom RadView Software (UK)

Phone: +44-207-716-5840

Other Countries RadView Software Ltd.

14 Hamelacha Street
Rosh Haayin 48091, Israel

Phone: +972-3-915-7060
Fax: +972-3-915-7683

RadView corporate website: www.radview.com

WebLOAD community website: www.webload.org

16