qileilove

This sampler allows you to write a sampler using the BeanShell scripting language.

For full details on using BeanShell, please see the BeanShell website.

The test element supports the ThreadListener and TestListener interface methods. These must be defined in the initialisation file. See the file BeanShellListeners.bshrc for example definitions.

From JMeter version 2.5.1, the BeanShell sampler also supports the Interruptible interface. The interrupt() method can be defined in the script or the init file.

Control Panel

Parameters

N.B. Each Sampler instance has its own BeanShell interpeter, and Samplers are only called from a single thread

If the property "beanshell.sampler.init" is defined, it is passed to the Interpreter as the name of a sourced file. This can be used to define common methods and variables. There is a sample init file in the bin directory: BeanShellSampler.bshrc.

If a script file is supplied, that will be used, otherwise the script will be used.

Before invoking the script, some variables are set up in the BeanShell interpreter:

The contents of the Parameters field is put into the variable "Parameters". The string is also split into separate tokens using a single space as the separator, and the resulting list is stored in the String array bsh.args.

The full list of BeanShell variables that is set up is as follows:

• log - the Logger
• Label - the Sampler label
• FileName - the file name, if any
• Parameters - text from the Parameters field
• bsh.args - the parameters, split as described above
• SampleResult - pointer to the current SampleResult
• ResponseCode = 200
• ResponseMessage = "OK"
• IsSuccess = true
• ctx - JMeterContext
• vars - JMeterVariables - e.g. vars.get("VAR1"); vars.put("VAR2","value"); vars.remove("VAR3"); vars.putObject("OBJ1",new Object());
• props - JMeterProperties (class java.util.Properties)- e.g. props.get("START.HMS"); props.put("PROP1","1234");

When the script completes, control is returned to the Sampler, and it copies the contents of the following script variables into the corresponding variables in the SampleResult :

• ResponseCode - for example 200
• ResponseMessage - for example "OK"
• IsSuccess - true/false

The SampleResult ResponseData is set from the return value of the script. Since version 2.1.2, if the script returns null, it can set the response directly, by using the method SampleResult.setResponseData(data), where data is either a String or a byte array. The data type defaults to "text", but can be set to binary by using the method SampleResult.setDataType(SampleResult.BINARY).

The SampleResult variable gives the script full access to all the fields and methods in the SampleResult. For example, the script has access to the methods setStopThread(boolean) and setStopTest(boolean). Here is a simple (not very useful!) example script:

if (bsh.args[0].equalsIgnoreCase("StopThread")) {
    log.info("Stop Thread detected!");
    SampleResult.setStopThread(true);
}
return "Data from sample with Label "+Label;
//or, since version 2.1.2
SampleResult.setResponseData("My data");
return null;

Another example: 
ensure that the property beanshell.sampler.init=BeanShellSampler.bshrc is defined in jmeter.properties. The following script will show the values of all the variables in the ResponseData field:

return getVariables();

For details on the methods available for the various classes ( JMeterVariables , SampleResult etc) please check the Javadoc or the source code. Beware however that misuse of any methods can cause subtle faults that may be difficult to find ...

18.1.11 BSF Sampler

This sampler allows you to write a sampler using a BSF scripting language. 
See the Apache Bean Scripting Framework website for details of the languages supported. You may need to download the appropriate jars for the language; they should be put in the JMeter lib directory.

By default, JMeter supports the following languages:

• javascript
• jexl (JMeter version 2.3.2 and later)
• xslt

Control Panel

Parameters

If a script file is supplied, that will be used, otherwise the script will be used.

Before invoking the script, some variables are set up. Note that these are BSF variables - i.e. they can be used directly in the script.

• log - the Logger
• Label - the Sampler label
• FileName - the file name, if any
• Parameters - text from the Parameters field
• args - the parameters, split as described above
• SampleResult - pointer to the current SampleResult
• sampler - pointer to current Sampler
• ctx - JMeterContext
• vars - JMeterVariables - e.g. vars.get("VAR1"); vars.put("VAR2","value"); vars.remove("VAR3"); vars.putObject("OBJ1",new Object());
• props - JMeterProperties (class java.util.Properties) - e.g. props.get("START.HMS"); props.put("PROP1","1234");
• OUT - System.out - e.g. OUT.println("message")

The SampleResult ResponseData is set from the return value of the script. If the script returns null, it can set the response directly, by using the method SampleResult.setResponseData(data), where data is either a String or a byte array. The data type defaults to "text", but can be set to binary by using the method SampleResult.setDataType(SampleResult.BINARY).

The SampleResult variable gives the script full access to all the fields and methods in the SampleResult. For example, the script has access to the methods setStopThread(boolean) and setStopTest(boolean).

Unlike the BeanShell Sampler, the BSF Sampler does not set the ResponseCode, ResponseMessage and sample status via script variables. Currently the only way to changes these is via the 

18.9.8 Debug Sampler

The Debug Sampler generates a sample containing the values of all JMeter variables and/or properties.

The values can be seen in the View Results Tree Listener Response Data pane.

Control Panel

Parameters

18.1.1 FTP Request

Latency is set to the time it takes to login (versions of JMeter after 2.3.1).

Control Panel

Parameters

See Also:

• Assertions
• FTP Request Defaults
• Building an FTP Test Plan

18.1.2 HTTP Request

This sampler lets you send an HTTP/HTTPS request to a web server. It also lets you control whether or not JMeter parses HTML files for images and other embedded resources and sends HTTP requests to retrieve them. The following types of embedded resource are retrieved:

• images
• applets
• stylesheets
• external scripts
• frames, iframes
• background images (body, table, TD, TR)
• background sound

The default parser is htmlparser. This can be changed by using the property "htmlparser.classname" - see jmeter.properties for details.

If you are going to send multiple requests to the same web server, consider using an HTTP Request Defaults Configuration Element so you do not have to enter the same information for each HTTP Request.

Or, instead of manually adding HTTP Requests, you may want to use JMeter's HTTP(S) Test Script Recorder to create them. This can save you time if you have a lot of HTTP requests or requests with many parameters.

There are two different screens for defining the samplers:

• AJP/1.3 Sampler - uses the Tomcat mod_jk protocol (allows testing of Tomcat in AJP mode without needing Apache httpd) The AJP Sampler does not support multiple file upload; only the first file will be used.
• HTTP Request - this has an implementation drop-down box, which selects the HTTP protocol implementation to be used:
• Java - uses the HTTP implementation provided by the JVM. This has some limitations in comparison with the HttpClient implementations - see below.
• HTTPClient3.1 - uses Apache Commons HttpClient 3.1. This is no longer being developed, and support for this may be dropped in a future JMeter release.
• HTTPClient4 - uses Apache HttpComponents HttpClient 4.x.
• Blank Value - does not set implementationon HTTP Samplers, so relies on HTTP Request Defaults if present or on jmeter.httpsampler property defined in jmeter.properties

The Java HTTP implementation has some limitations:

• There is no control over how connections are re-used. When a connection is released by JMeter, it may or may not be re-used by the same thread.
• The API is best suited to single-threaded usage - various settings are defined via system properties, and therefore apply to all connections.
• There is a bug in the handling of HTTPS via a Proxy (the CONNECT is not handled correctly). See Java bugs 6226610 and 6208335.
• It does not support virtual hosts.

Note: the FILE protocol is intended for testing puposes only. It is handled by the same code regardless of which HTTP Sampler is used.

If the request requires server or proxy login authorization (i.e. where a browser would create a pop-up dialog box), you will also have to add an HTTP Authorization Manager Configuration Element. For normal logins (i.e. where the user enters login information in a form), you will need to work out what the form submit button does, and create an HTTP request with the appropriate method (usually POST) and the appropriate parameters from the form definition. If the page uses HTTP, you can use the JMeter Proxy to capture the login sequence.

In versions of JMeter up to 2.2, only a single SSL context was used for all threads and samplers. This did not generate the proper load for multiple users. A separate SSL context is now used for each thread. To revert to the original behaviour, set the JMeter property:

https.sessioncontext.shared=true  

https.use.cached.ssl.context=false  

JMeter defaults to the SSL protocol level TLS. If the server needs a different level, e.g. SSLv3, change the JMeter property, for example:

https.default.protocol=SSLv3  

JMeter also allows one to enable additional protocols, by changing the property https.socket.protocols .

If the request uses cookies, then you will also need an HTTP Cookie Manager . You can add either of these elements to the Thread Group or the HTTP Request. If you have more than one HTTP Request that needs authorizations or cookies, then add the elements to the Thread Group. That way, all HTTP Request controllers will share the same Authorization Manager and Cookie Manager elements.

If the request uses a technique called "URL Rewriting" to maintain sessions, then see section 6.1 Handling User Sessions With URL Rewriting for additional configuration steps.

Control Panel

Parameters

N.B. when using Automatic Redirection, cookies are only sent for the initial URL. This can cause unexpected behaviour for web-sites that redirect to a local server. E.g. if www.example.com redirects to www.example.co.uk. In this case the server will probably return cookies for both URLs, but JMeter will only see the cookies for the last host, i.e. www.example.co.uk. If the next request in the test plan uses www.example.com, rather than www.example.co.uk, it will not get the correct cookies. Likewise, Headers are sent for the initial request, and won't be sent for the redirect. This is generally only a problem for manually created test plans, as a test plan created using a recorder would continue from the redirected URL.

Parameter Handling: 
For the POST and PUT method, if there is no file to send, and the name(s) of the parameter(s) are omitted, then the body is created by concatenating all the value(s) of the parameters. Note that the values are concatenated without adding any end-of-line characters. These can be added by using the __char() function in the value fields. This allows arbitrary bodies to be sent. The values are encoded if the encoding flag is set (versions of JMeter after 2.3). See also the MIME Type above how you can control the content-type request header that is sent. 
For other methods, if the name of the parameter is missing, then the parameter is ignored. This allows the use of optional parameters defined by variables. (versions of JMeter after 2.3)

Since JMeter 2.6, you have the option to switch to Post Body when a request has only unnamed parameters (or no parameters at all). This option is useful in the following cases (amongst others):

• GWT RPC HTTP Request
• JSON REST HTTP Request
• XML REST HTTP Request
• SOAP HTTP Request

In Post Body mode, each line will be sent with CRLF appended, apart from the last line. To send a CRLF after the last line of data, just ensure that there is an empty line following it. (This cannot be seen, except by noting whether the cursor can be placed on the subsequent line.)

Figure 1 - HTTP Request with one unnamed parameter

Figure 2 - Confirm dialog to switch

Figure 3 - HTTP Request using Body Data

Method Handling: 
The POST, PUT and PATCH request methods work similarly, except that the PUT and PATCH methods do not support multipart requests or file upload. The PUT and PATCH method body must be provided as one of the following:

• define the body as a file with empty Parameter name field; in which case the MIME Type is used as the Content-Type
• define the body as parameter value(s) with no name
• use the Post Body tab

Upto and including JMeter 2.1.1, only responses with the content-type "text/html" were scanned for embedded resources. Other content-types were assumed to be something other than HTML. JMeter 2.1.2 introduces the a new property HTTPResponse.parsers , which is a list of parser ids, e.g. htmlParser andwmlParser . For each id found, JMeter checks two further properties:

• id.types - a list of content types
• id.className - the parser to be used to extract the embedded resources

See jmeter.properties file for the details of the settings. If the HTTPResponse.parser property is not set, JMeter reverts to the previous behaviour, i.e. only text/html responses will be scanned

# Define characters per second > 0 to emulate slow connections #httpclient.socket.http.cps=0 #httpclient.socket.https.cps=0  

Response size calculation 
Optional properties to allow change the method to get response size: 

• Gets the real network size in bytes for the body response

  sampleresult.getbytes.body_real_size=true 

• Add HTTP headers to full response size

  sampleresult.getbytes.headers_size=true 

Retry handling 
In version 2.5 of JMeter, the HttpClient4 and Commons HttpClient 3.1 samplers used the default retry count, which was 3. In later versions, the retry count has been set to 1, which is what the Java implementation appears to do. The retry count can be overridden by setting the relevant JMeter property, for example:

httpclient4.retrycount=3 httpclient3.retrycount=3  

See Also:

• Assertion
• Building a Web Test Plan
• Building an Advanced Web Test Plan
• HTTP Authorization Manager
• HTTP Cookie Manager
• HTTP Header Manager
• HTML Link Parser
• HTTP(S) Test Script Recorder
• HTTP Request Defaults
• HTTP Requests and Session ID's: URL Rewriting

18.1.4 Java Request

This sampler lets you control a java class that implements the org.apache.jmeter.protocol.java.sampler.JavaSamplerClient interface. By writing your own implementation of this interface, you can use JMeter to harness multiple threads, input parameter control, and data collection.

The pull-down menu provides the list of all such implementations found by JMeter in its classpath. The parameters can then be specified in the table below - as defined by your implementation. Two simple examples (JavaTest and SleepTest) are provided.

The JavaTest example sampler can be useful for checking test plans, because it allows one to set values in almost all the fields. These can then be used by Assertions, etc. The fields allow variables to be used, so the values of these can readily be seen.

Control Panel

Parameters

The following parameters apply to the SleepTest and JavaTest implementations:

Parameters

The following parameters apply additionaly to the JavaTest implementation:

Parameters

18.1.3 JDBC Request

This sampler lets you send an JDBC Request (an SQL query) to a database.

Before using this you need to set up a JDBC Connection Configuration Configuration element

If the Variable Names list is provided, then for each row returned by a Select statement, the variables are set up with the value of the corresponding column (if a variable name is provided), and the count of rows is also set up. For example, if the Select statement returns 2 rows of 3 columns, and the variable list is A,,C , then the following variables will be set up:

A_#=2 (number of rows) A_1=column 1, row 1 A_2=column 1, row 2 C_#=2 (number of rows) C_1=column 3, row 1 C_2=column 3, row 2  

Old variables are cleared if necessary - e.g. if the first select retrieves 6 rows and a second select returns only 3 rows, the additional variables for rows 4, 5 and 6 will be removed.

Note: The latency time is set from the time it took to acquire a connection.

Control Panel

Parameters

"Dbl-Quote: "" and Comma: ," 

See Also:

• Building a Database Test Plan
• JDBC Connection Configuration

18.1.15 JMS Point-to-Point

This sampler sends and optionally receives JMS Messages through point-to-point connections (queues). It is different from pub/sub messages and is generally used for handling transactions.

Request Only will typically used to put load on a JMS System. 
Request Response will be used when you want to test response time of a JMS service that processes messages sent to the Request Queue as this mode will wait for the response on the Reply queue sent by this service. 

Versions of JMeter after 2.3.2 use the properties java.naming.security.[principal|credentials] - if present - when creating the Queue Connection. If this behaviour is not desired, set the JMeter property JMSSampler.useSecurity.properties=false

Control Panel

Parameters

18.1.13 JMS Publisher

JMS Publisher will publish messages to a given destination (topic/queue). For those not familiar with JMS, it is the J2EE specification for messaging. There are numerous JMS servers on the market and several open source options.

Control Panel

Parameters

For the MapMessage type, JMeter reads the source as lines of text. Each line must have 3 fields, delimited by commas. The fields are:

• Name of entry
• Object class name, e.g. "String" (assumes java.lang package if not specified)
• Object string value

name,String,Example size,Integer,1234  

The following table shows some values which may be useful when configuring JMS:

18.1.14 JMS Subscriber

JMS Publisher will subscribe to messages in a given destination (topic or queue). For those not familiar with JMS, it is the J2EE specification for messaging. There are numerous JMS servers on the market and several open source options.

Control Panel

Parameters

NOTE: JMeter 2.3.4 and earlier used a different strategy for the MessageConsumer.receive() client. Previously this started a background thread which polled for messages. This thread continued when the sampler completed, so the net effect was similar to the MessageListener.onMessage() strategy.

18.1.11.1 JSR223 Sampler

The JSR223 Sampler allows JSR223 script code to be used to perform a sample.

The JSR223 test elements have a feature (compilation) that can significantly increase performance. To benefit from this feature:

• Use Script files instead of inlining them. This will make JMeter compile them if this feature is available on ScriptEngine and cache them.
• Or Use Script Text and fill in script cache key property, ensure it is unique across Test Plan as JMeter will use it to cache result of compilation.

   

  When using this feature, ensure you script code does not use JMeter variables directly in script code as caching would only cache first replacement. Instead use script parameters.

   

   

  To benefit fomr Caching and compilation, language engine used for scripting must implement JSR223 Compilable interface (Groovy is one of these, java, beanshell and javascript are not)

   

• jsr223.compiled_scripts_cache_size=100

Control Panel

18.1.16 JUnit Request

Control Panel

Parameters

The following JUnit4 annotations are recognised:

• @Test - used to find test methods and classes. The "expected" and "timeout" attributes are supported.
• @Before - treated the same as setUp() in JUnit3
• @After - treated the same as tearDown() in JUnit3
• @BeforeClass, @AfterClass - treated as test methods so they can be run independently as required

Note that JMeter currently runs the test methods directly, rather than leaving it to JUnit. This is to allow the setUp/tearDown methods to be excluded from the sample time.

18.4.11 LDAP Request Defaults

The LDAP Request Defaults component lets you set default values for LDAP testing. See the LDAP Request .

Control Panel

18.1.7 LDAP Request

If you are going to send multiple requests to the same LDAP server, consider using an LDAP Request Defaults Configuration Element so you do not have to enter the same information for each LDAP Request.

Control Panel

There are two ways to create test cases for testing an LDAP Server.

1. Inbuilt Test cases.
2. User defined Test cases.

There are four test scenarios of testing LDAP. The tests are given below:

1. Add Test
1. Inbuilt test :

   This will add a pre-defined entry in the LDAP Server and calculate the execution time. After execution of the test, the created entry will be deleted from the LDAP Server.

2. User defined test :

   This will add the entry in the LDAP Server. User has to enter all the attributes in the table.The entries are collected from the table to add. The execution time is calculated. The created entry will not be deleted after the test.

2. Modify Test
1. Inbuilt test :

   This will create a pre-defined entry first, then will modify the created entry in the LDAP Server.And calculate the execution time. After execution of the test, the created entry will be deleted from the LDAP Server.

2. User defined test

   This will modify the entry in the LDAP Server. User has to enter all the attributes in the table. The entries are collected from the table to modify. The execution time is calculated. The entry will not be deleted from the LDAP Server.

3. Search Test
1. Inbuilt test :

   This will create the entry first, then will search if the attributes are available. It calculates the execution time of the search query. At the end of the execution,created entry will be deleted from the LDAP Server.

2. User defined test

   This will search the user defined entry(Search filter) in the Search base (again, defined by the user). The entries should be available in the LDAP Server. The execution time is calculated.

4. Delete Test
1. Inbuilt test :

   This will create a pre-defined entry first, then it will be deleted from the LDAP Server. The execution time is calculated.

2. User defined test

   This will delete the user-defined entry in the LDAP Server. The entries should be available in the LDAP Server. The execution time is calculated.

Parameters

See Also:

• Building an Ldap Test Plan
• LDAP Request Defaults

18.1.17 Mail Reader Sampler

The Mail Reader Sampler can read (and optionally delete) mail messages using POP3(S) or IMAP(S) protocols.

Control Panel

Parameters

Messages are stored as subsamples of the main sampler. In versions of JMeter after 2.3.4, multipart message parts are stored as subsamples of the message.

Special handling for "file" protocol: 
The file JavaMail provider can be used to read raw messages from files. The server field is used to specify the path to the parent of the folder . Individual message files should be stored with the name n.msg , where n is the message number. Alternatively, the server field can be the name of a file which contains a single message. The current implementation is quite basic, and is mainly intended for debugging purposes.

18.1.20 OS Process Sampler

The OS Process Sampler is a sampler that can be used to execute commands on the local machine. 
It should allow execution of any command that can be run from the command line. 
Validation of the return code can be enabled, and the expected return code can be specified. 

Note that OS shells generally provide command-line parsing. This varies between OSes, but generally the shell will split parameters on white-space. Some shells expand wild-card file names; some don't. The quoting mechanism also varies between OSes. The sampler deliberately does not do any parsing or quote handling. The command and its parameters must be provided in the form expected by the executable. This means that the sampler settings will not be portable between OSes.

Many OSes have some built-in commands which are not provided as separate executables. For example the Windows DIR command is part of the command interpreter (CMD.EXE). These built-ins cannot be run as independent programs, but have to be provided as arguments to the appropriate command interpreter.

For example, the Windows command-line: DIR C:\TEMP needs to be specified as follows:

command:   CMD Param 1:   /C Param 2:   DIR Param 3:   C:\TEMP  

Control Panel

Parameters

18.1.19 SMTP Sampler

The SMTP Sampler can send mail messages using SMTP/SMTPS protocol. It is possible to set security propocols for the connection (SSL and TLS), as well as user authentication. If a security protocol is used a verification on the server certificate will occur. 
Two alternatives to handle this verification are available: 

• Trust all certificates. This will ignore certificate chain verification
• Use a local truststore. With this option the certificate chain will be validated against the local truststore file.

Control Panel

Parameters

18.1.5 SOAP/XML-RPC Request

This sampler lets you send a SOAP request to a webservice. It can also be used to send XML-RPC over HTTP. It creates an HTTP POST request, with the specified XML as the POST content. To change the "Content-type" from the default of "text/xml", use a HeaderManager. Note that the sampler will use all the headers from the HeaderManager. If a SOAP action is specified, that will override any SOAPaction in the HeaderManager. The primary difference between the soap sampler and webservice sampler, is the soap sampler uses raw post and does not require conformance to SOAP 1.1.

Control Panel

Parameters

18.1.12 TCP Sampler

The TCP Sampler opens a TCP/IP connection to the specified server. It then sends the text, and waits for a response. 
If "Re-use connection" is selected, connections are shared between Samplers in the same thread, provided that the exact same host name string and port are used. Different hosts/port combinations will use different connections, as will different threads. If both of "Re-use connection" and "Close connection" are selected, the socket will be closed after running the sampler. On the next sampler, another socket will be created. You may want to close a socket at the end of each thread loop. 
If an error is detected - or "Re-use connection" is not selected - the socket is closed. Another socket will be reopened on the next sample. 
The following properties can be used to control its operation:

• tcp.status.prefix - text that precedes a status number
• tcp.status.suffix - text that follows a status number
• tcp.status.properties - name of property file to convert status codes to messages
• tcp.handler - Name of TCP Handler class (default TCPClientImpl) - only used if not specified on the GUI

Users can provide their own implementation. The class must extend org.apache.jmeter.protocol.tcp.sampler.TCPClient.

The following implementations are currently provided.

• TCPClientImpl
• BinaryTCPClientImpl
• LengthPrefixedBinaryTCPClientImpl

TCPClientImpl 
This implementation is fairly basic. When reading the response, it reads until the end of line byte, if this is defined by setting the propertytcp.eolByte , otherwise until the end of the input stream. You can control charset encoding by setting tcp.charset , which will default to Platform default encoding.

BinaryTCPClientImpl 
This implementation converts the GUI input, which must be a hex-encoded string, into binary, and performs the reverse when reading the response. When reading the response, it reads until the end of message byte, if this is defined by setting the property tcp.BinaryTCPClient.eomByte , otherwise until the end of the input stream.

LengthPrefixedBinaryTCPClientImpl 
This implementation extends BinaryTCPClientImpl by prefixing the binary message data with a binary length byte. The length prefix defaults to 2 bytes. This can be changed by setting the property tcp.binarylength.prefix.length .

Timeout handling If the timeout is set, the read will be terminated when this expires. So if you are using an eolByte/eomByte, make sure the timeout is sufficiently long, otherwise the read will be terminated early.

Response handling 
If tcp.status.prefix is defined, then the response message is searched for the text following that up to the suffix. If any such text is found, it is used to set the response code. The response message is then fetched from the properties file (if provided). 
For example, if the prefix = "[" and the suffix = "]", then the following repsonse: 
[J28] XI123,23,GBP,CR 
would have the response code J28. 
Response codes in the range "400"-"499" and "500"-"599" are currently regarded as failures; all others are successful. [This needs to be made configurable!]

Control Panel

Parameters

8.1.18 Test Action

This sampler can also be useful in conjunction with the Transaction Controller, as it allows pauses to be included without needing to generate a sample. For variable delays, set the pause time to zero, and add a Timer as a child.

The "Stop" action stops the thread or test after completing any samples that are in progress. The "Stop Now" action stops the test without waiting for samples to complete; it will interrupt any active samples. If some threads fail to stop within the 5 second time-limit, a message will be displayed in GUI mode. You can try using the Stop command to see if this will stop the threads, but if not, you should exit JMeter. In non-GUI mode, JMeter will exit if some threads fail to stop within the 5 second time limit. [This can be changed using the JMeter property jmeterengine.threadstop.wait ]

Control Panel

Parameters

18.1.6 WebService(SOAP) Request (DEPRECATED)

This sampler has been tested with IIS Webservice running .NET 1.0 and .NET 1.1. It has been tested with SUN JWSDP, IBM webservices, Axis and gSoap toolkit for C/C++. The sampler uses Apache SOAP driver to serialize the message and set the header with the correct SOAPAction. Right now the sampler doesn't support automatic WSDL handling, since Apache SOAP currently does not provide support for it. Both IBM and SUN provide WSDL drivers. There are 3 options for the post data: text area, external file, or directory. If you want the sampler to randomly select a message, use the directory. Otherwise, use the text area or a file. The if either the file or path are set, it will not use the message in the text area. If you need to test a soap service that uses different encoding, use the file or path. If you paste the message in to text area, it will not retain the encoding and will result in errors. Save your message to a file with the proper encoding, and the sampler will read it as java.io.FileInputStream.

An important note on the sampler is it will automatically use the proxy host and port passed to JMeter from command line, if those fields in the sampler are left blank. If a sampler has values in the proxy host and port text field, it will use the ones provided by the user. This behavior may not be what users expect.

By default, the webservice sampler sets SOAPHTTPConnection.setMaintainSession (true). If you need to maintain the session, add a blank Header Manager. The sampler uses the Header Manager to store the SOAPHTTPConnection object, since the version of apache soap does not provide a easy way to get and set the cookies.

Note: If you are using CSVDataSet, do not check "Memory Cache". If memory cache is checked, it will not iterate to the next value. That means all the requests will use the first value.

Make sure you use <soap:Envelope rather than <Envelope. For example:

<?xml version="1.0" encoding="utf-8"?> <soap:Envelope  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <foo xmlns="http://clients-xlmns"/> </soap:Body> </soap:Envelope>  

Control Panel

Parameters