xdocs/usermanual/build-ldapext-test-plan.xml - jmeter - Git at Google

 <?xml version="1.0"?>
 <!--
    Licensed to the Apache Software Foundation (ASF) under one or more
    contributor license agreements.  See the NOTICE file distributed with
    this work for additional information regarding copyright ownership.
    The ASF licenses this file to You under the Apache License, Version 2.0
    (the "License"); you may not use this file except in compliance with
    the License.  You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.
 -->

 <!DOCTYPE document[
 <!ENTITY sect-num '9b'>
 <!ENTITY rarr     "&#x02192;" >
 ]>

 <document prev="build-ldap-test-plan.html" next="build-ws-test-plan.html" id="$Id$">


 <properties>
   <title>User's Manual: Building an Extended LDAP Test Plan</title>
 </properties>

 <body>
 <section name="&sect-num;. Building an Extended LDAP Test Plan" anchor="ldapexttest">
 <p>
 In this section, you will learn how to create a basic Test Plan to test an LDAP
 server.</p>
 <p>
 As the Extended LDAP Sampler is highly configurable, this also means that it takes
 some time to build a correct testplan. You can however tune it exactly up to your
 needs.
 </p>

 <p>
 You will create four users that send requests for four tests on the LDAP server. Also, you will tell
 the users to run their tests one time. So,  the total number of requests is <code>(1 users) x (9 requests) x
 repeat 1 time) = 9</code> LDAP requests. To construct the Test Plan, you will use the following elements:<br/>
 <a href="test_plan.html#thread_group">Thread Group</a>,<br/>
 <complink name="Adding LDAP Extended Request Defaults"/>,<br/>
 <complink name="Adding LDAP Requests"/>, and<br/>
 <complink name="Adding a Listener to View/Store the Test Results"/>
 </p>
 <p>
 This example assumes that the LDAP Server is available at <code>ldap.test.com</code>.
 </p>
 <p>
 For the less experienced LDAP users, I build a <a href="ldapops_tutor.html">small
 LDAP tutorial</a> which shortly explains
 the several LDAP operations that can be used in building a complex testplan.
 </p>
 <p>
 Take care when using LDAP special characters in the distinguished name, in that case (e.g. you want to use a <code>+</code> sign in a
 distinguished name) you need to escape the character by adding an "<code>\</code>" sign before that character.
 Extra exception: if you want to add a <code>\</code> character in a distinguished name (in an add or rename operation), you need to use 4 backslashes.
 </p>
 Examples:
 <dl>
 <dt><code>cn=dolf\+smits</code></dt><dd>to add/search an entry with the name like <code>cn=dolf+smits</code></dd>
 <dt><code>cn=dolf \\ smits</code></dt><dd>to search an entry with the name <code>cn=dolf \ smits</code></dd>
 <dt><code>cn=c:\\\\log.txt</code></dt><dd>to add an entry with a name like <code>cn=c:\log.txt</code></dd>
 </dl>


     <subsection name="&sect-num;.1 Adding Users" anchor="ext_adding_users">
 <p>
 The first step you want to do with every JMeter Test Plan is to add a Thread Group element.
 The Thread Group tells JMeter the number of users you want to simulate, how often the users should send
 requests, and the how many requests  they should send.
 </p>
 <p>
 Go ahead and add the <code>Thread Group</code> element by first selecting the <code>Test Plan</code>, clicking your
 right mouse button to get the <code>Add</code> menu, and then select <code>Add</code>&rarr;<code>Threads (Users)</code>&rarr;<code>Thread Group</code>.
 You should now see the <code>Thread Group</code> element under <code>Test Plan</code>. If you do not see the element, then "expand" the Test Plan tree by
 clicking on the Test Plan element.
 </p>
 <p>
 <figure image="ldaptest/extthreadgroup.png">
 Figure &sect-num;.1. Thread Group with Default Values</figure>

 </p>
 </subsection>
     <subsection name="&sect-num;.2 Adding LDAP Extended Request Defaults" anchor="add_ldapext_defaults">
 <p>
 Begin by selecting the LDAP Ext Users element. Click your right mouse button
 to get the <code>Add</code> menu, and then select <code>Add</code>&rarr;<code>Config Element</code>&rarr;<code>LDAP Extended Request Defaults</code>. Then,
 select this new element to view its Control Panel.
 </p>
 <p>
 Like most JMeter elements, the <code>LDAP Extended Request Defaults</code> Control Panel has a name
 field that you can modify. In this example, leave this field with the default value.
 </p>
 <p><figure image="ldaptest/extrequestdefaults.png"><br/>
   Figure &sect-num;.2 LDAP Defaults for our Test Plan</figure>
 </p>
 <p>
             For each of the different operations, some default values can be filled in.
             In All cases, when a default is filled in, this is used for the LDAP extended requests.
             For each request, you can override the defaults by filling in the values in the LDAP extended request sampler.
             When no value is entered which is necessary for a test, the test will fail in an unpredictable way!
             </p>
             We will not enter any default values here, as we will build a very small testplan, so we will explain all the different fields when we add the LDAP Extended samplers.
 </subsection>
 <subsection name="&sect-num;.3 Adding LDAP Requests" anchor="add_extrequests">
 <p>
 In our Test Plan, we want to use all 9 LDAP requests.
 </p>
    <ol>
 <li>
 Thread bind
 </li>
 <li>
 Search Test
 </li>
 <li>
 Compare Test
 </li>
 <li>
 Single bind/unbind Test
 </li>
 <li>
 Add Test
 </li>
 <li>
 Modify Test
 </li>
 <li>
 Rename entry (moddn)
 </li>
 <li>
 Delete Test
 </li>
 <li>
 Thread unbind
 </li>
 </ol>
    <p>
 JMeter sends requests in the order that you add them to the tree.
 </p>
 <p>
 Adding a requests always start by:<br/>
 Adding the <code>LDAP Extended Request</code> to the LDAP Ext Users element (<code>Add</code>&rarr;
 <code>Sampler</code>&rarr;<code>LDAP Ext Request</code>). Then, select the <code>LDAP Ext Request</code> element in the tree
 and edit the following properties.</p>


 <subsection name="&sect-num;.3.1 Adding a Thread bind Request" anchor="add_threadbind">
 <p>
    <ol>
 <li>
 Rename the element: "<code>1. Thread bind</code>"
 </li>
 <li>
 Select the "<code>Thread bind</code>" button.
 </li>
 <li>
 Enter the hostname value from the LDAP server in the Servername field
 </li>
 <li>
 Enter the portnumber from the LDAP server (<code>636</code> : ldap over SSL) in the port field
 </li>
 <li>
 <i>(Optional)</i> Enter the baseDN in the DN field, this baseDN will be used as the starting point for searches, add, deletes, etc.<br/>
 take care that this must be the uppermost shared level for all your request, e.g. when all information is stored under <code>ou=Users, dc=test, dc=com</code>, you can use this value in the basedn.<br/>
 </li>
 <li>
 <i>(Optional)</i> Enter the distinguished name from the user you want to use for authentication.
 When this field is kept empty, an anonymous bind will be established.
 </li>
 <li>
 <i>(Optional)</i> Enter the password for the user you want to authenticate with, an empty password will also lead to an anonymous bind.
 </li>
 <li>
 <i>(Optional)</i> Enter a value for the connection timeout with LDAP
 </li>
 <li>
 <i>(Optional)</i> Check the box Use Secure LDAP Protocol if you access with LDAP over SSL (ldaps)
 </li>
 </ol>
 </p>
 <p>
 <figure image="ldaptest/extthreadbind.png">
 Figure &sect-num;.3.1. Thread Bind example</figure>
 </p>
 </subsection>

 <subsection name="&sect-num;.3.2 Adding a search Request" anchor="add_searchreq">
 <p>
    <ol>
 <li>
 Rename the element: "<code>2. Search Test</code>"
 </li>
 <li>
 Select the "<code>Search Test</code>" button.
 </li>
 <li>
 <i>(Optional)</i> enter the searchbase under which you want to perform the search, relative to the basedn, used in the thread bind request.<br/>
 When left empty, the basedn is used as a search base, this files is important if you want to use a "base-entry" or "one-level" search (see below)
 </li>
 <li>
 Enter the searchfilter, any decent LDAP search filter will do, but for now, use something simple, like <code>(sn=Doe)</code> or <code>(cn=*)</code>
 </li>
 <li>
 <i>(Optional)</i> Enter the scope in the scope field, it has three options:
      <ol>
      <li>baseobject search<br/>only the given searchbase is used, only for checking attributes or existence.
      </li>
      <li>onelevel search<br/>Only search in one level below given searchbase is used
      </li>
      <li>subtree search<br/> Searches for object at any point below the given basedn
      </li></ol>
 </li>
 <li>
 <i>(Optional)</i> Size limit, specifies the maximum number of returned entries,
 </li>
 <li>
 <i>(Optional)</i> Time limit, specifies the maximum number of milliseconds, the SERVER can use for performing the search. It is NOT the maximum time the application will wait.<br/>
 When a very large returnset is returned, from a very fast server, over a very slow line, you may have to wait for ages for the completion of the search request, but this parameter will not influence this.
 </li>
 <li><i>(Optional)</i> Attributes you want in the search answer. This can be used to limit the size of the answer, especially when an object has very large attributes (like <code>jpegPhoto</code>). There are three possibilities:
 <ol><li>Leave empty (the default setting must also be empty) This will return all attributes.
 </li>
 <li>Put in one empty value (<code>""</code>), it will request a non-existent attributes, so in reality it returns no attributes
 </li>
 <li>Put in the attributes, separated by a semi-colon. It will return only the requested attributes
 </li></ol></li>
 <li>
 <i>(Optional)</i> Return object. Checked will return all java-object attributes, it will add these to the requested attributes, as specified above.<br/>
 Unchecked will mean no java-object attributes will be returned.
 </li>
 <li>
 <i>(Optional)</i> Dereference aliases. Checked will mean it will follow references, Unchecked says it will not.
 </li>
 <li>
 <i>(Optional)</i> Parse the search results?. Checked will mean it gets all results in response data, Unchecked says it will not.
 </li>
 </ol>
 </p>
 <p>
 <figure image="ldaptest/extsearch.png">
 Figure &sect-num;.3.2. search request example</figure>
 </p></subsection>

 <subsection name="&sect-num;.3.3 Adding a Compare Request" anchor="add_comparereq">
 <p>
    <ol>
 <li>
 Rename the element: "<code>3. Compare Test</code>"
 </li>
 <li>
 Select the "<code>Compare</code>" button.
 </li>
 <li>
 enter the entryname form the object on which you want the compare operation to work, relative to the basedn, e.g. "<code>cn=jdoe,ou=Users</code>"
 </li>
 <li>
 Enter the compare filter, this must be in the form "<code>attribute=value</code>", e.g. "<code>mail=jdoe@test.com</code>"
 </li>
 </ol>
 </p>
 <p>
 <figure image="ldaptest/extcompare.png">
 Figure &sect-num;.3.3. Compare example</figure>
 </p>
 </subsection>

 <subsection name="&sect-num;.3.4 Adding a Single bind/unbind" anchor="add_sbind">
 <p>
    <ol>
 <li>
 Rename the element: "<code>4. Single bind/unbind Test</code>"
 </li>
 <li>
 Select the "<code>Single bind/unbind</code>" button.
 </li>
 <li>
 Enter the FULL distinguished name from the user you want to use for authentication.<br/>
 E.g. <code>cn=jdoe,ou=Users,dc=test,dc=com</code>
 When this field is kept empty, an anonymous bind will be established.
 </li>
 <li>
 Enter the password for the user you want to authenticate with, an empty password will also lead to an anonymous bind.
 </li>
 </ol>
 <b>Take care</b>: This single bind/unbind is in reality two separate operations but cannot easily be split!
 </p><p>
 <figure image="ldaptest/extsbind.png">
 Figure &sect-num;.3.4. Single bind/unbind example</figure>
 </p>
 </subsection>

 <subsection name="&sect-num;.3.5 Adding an Add Request" anchor="add_addreq">
 <p>
    <ol>
 <li>
 Rename the element: "<code>5. Add Test</code>"
 </li>
 <li>
 Select the "<code>Add</code>" button.
 </li>
 <li>
 Enter the distinguished name for the object to add, relative to the basedn.
 </li>
 <li>
 Add a line in the "<code>add test</code>" table, fill in the attribute and value.<br/>
 When you need the same attribute more than once, just add a new line, add the attribute again, and a different value.<br/>
 All necessary attributes and values must be specified to pass the test, see picture!<br/>
 (sometimes the server adds the attribute "<code>objectClass=top</code>", this might give a problem.
 </li>
 </ol>
 </p>
 <p>
 <figure image="ldaptest/extadd.png">
 Figure &sect-num;.3.5. Add request example</figure>
 </p>
 </subsection>

 <subsection name="&sect-num;.3.6 Adding a Modify Request" anchor="add_modreq">
 <p>
    <ol>
 <li>
 Rename the element: "<code>6. Modify Test</code>"
 </li>
 <li>
 Select the "<code>Modify test</code>" button.
 </li>
 <li>
 Enter the distinguished name for the object to modify, relative to the basedn.
 </li>
 <li>
 Add a line in the "<code>modify test</code>" table, with the "<code>add</code>" button.
 </li>
 <li>
 You need to enter the attribute you want to modify, (optional) a value, and the opcode. The meaning of this opcode:
 <dl>
 <dt><code>add</code></dt><dd>this will mean that the attribute value (not optional in this case) will be added to the attribute.<br/>
 When the attribute is not existing, it will be created and the value added<br/>
 When it is existing, and defined multi-valued, the new value is added.<br/>
 when it is existing, but single valued, it will fail.</dd>
 <dt><code>replace</code></dt><dd>
 This will overwrite the attribute with the given new value (not optional here)<br/>
 When the attribute is not existing, it will be created and the value added<br/>
 When it is existing, old values are removed, the new value is added.</dd>
 <dt><code>delete</code></dt><dd>
 When no value is given, all values will be removed<br/>
 When a value is given, only that value will be removed<br/>
  when the given value is not existing, the test will fail
 </dd>
 </dl>
 </li>
 <li>
 <i>(Optional)</i> Add more modifications in the "<code>modify test</code>" table.<br/>
 All modifications which are specified must succeed, to let the modification test pass. When one modification fails,
 NO modifications at all will be made and the entry will remain unchanged.
 </li>
 </ol>
 </p>
 <p>
 <figure image="ldaptest/extmod.png">
 Figure &sect-num;.3.6. Modify example</figure>
 </p>
 </subsection>

 <subsection name="&sect-num;.3.7 Adding a Rename Request (moddn)" anchor="add_moddn">
 <p>
    <ol>
 <li>
 Rename the element: "<code>7. Rename entry (moddn)</code>"
 </li>
 <li>
 Select the "<code>Rename Entry</code>" button.
 </li>
 <li>
 Enter the name of the entry, relative to the baseDN, in the "<code>old entry name</code>"-Field.<br/>
 that is, if you want to rename "<code>cn=Little John Doe,ou=Users</code>", and you set the baseDN to "<code>dc=test,dc=com</code>",
 you need to enter "<code>cn=John Junior Doe,ou=Users</code>" in the <code>old entry name</code>-Field.
 </li>
 <li>
 Enter the new name of the entry, relative to the baseDN, in the "<code>new distinguished name</code>"-Field.<br/>
 when you only change the RDN, it will simply rename the entry<br/>
 when you also add a different subtree, e.g. you change from <code>cn=john doe,ou=Users</code> to <code>cn=john doe,ou=oldusers</code>, it will move the entry.
 You can also move a complete subtree (If your LDAP server supports this!), e.g. <code>ou=Users,ou=retired</code>, to <code>ou=oldusers,ou=users</code>,
 this will move the complete subtree, plus all retired people in the subtree to the new place in the tree.
 </li>
 </ol>
 </p>
 <p>
 <figure image="ldaptest/extmoddn.png">
 Figure &sect-num;.3.8. Rename example</figure>
 </p>
 </subsection>

 <subsection name="&sect-num;.3.8 Adding a Delete Request" anchor="add_delreq">
 <p>
    <ol>
 <li>
 Rename the element: "<code>8. Delete Test</code>"
 </li>
 <li>
 Select the "<code>Delete</code>" button.
 </li>
 <li>
 Enter the name of the entry, relative to the baseDN, in the <code>Delete</code>-Field.<br/>
 that is, if you want to remove "<code>cn=John Junior Doe,ou=Users,dc=test,dc=com</code>", and you set the baseDN to "<code>dc=test,dc=com</code>",
 you need to enter "<code>cn=John Junior Doe,ou=Users</code>" in the <code>Delete</code>-field.
 </li>
 </ol>
 </p>
 <p>
 <figure image="ldaptest/extdel.png">
 Figure &sect-num;.3.7. Delete example</figure>
 </p>
 </subsection>

 <subsection name="&sect-num;.3.9 Adding an unbind Request" anchor="add_unbind">
 <p>
    <ol>
 <li>
 Rename the element: "<code>9. Thread unbind</code>"
 </li>
 <li>
 Select the "<code>Thread unbind</code>" button.
 This will be enough as it just closes the current connection.
 The information which is needed is already known by the system
 </li></ol>
 </p>
 <p>
 <figure image="ldaptest/extthreadunbind.png">
 Figure &sect-num;.3.9. Unbind example</figure>
 </p>
 </subsection>
 </subsection>

 <subsection name="&sect-num;.4 Adding a Listener to View/Store the Test Results" anchor="add_ldapext_listener">
 <p>
 The final element you need to add to your Test Plan is a Listener.
  This element is responsible for storing all of the results of your LDAP
 requests in a file  and presenting a visual model of the data. Select the Thread group
 element and add a <code>View Results Tree</code> (<code>Add</code>&rarr;<code>Listener</code>&rarr;<code>View Results Tree</code>)
 </p>
 <p>
 <figure image="ldaptest/extviewtree.png">
 Figure &sect-num;.4. View Result Tree Listener</figure>
 </p>
 <p>
 In this listener you have three tabs to view, the sampler result, the request and the response data.
 <ol>
 <li>
 The sampler result just contains the response time, the returncode and return message
 </li>
 <li>
 The request gives a short description of the request that was made, in practice no relevant information
 is contained here.
 </li>
 <li>
 The response data contains the full details of the sent request, as well the full details of the received answer,
 this is given in a (self defined) xml-style.
 <a href="ldapanswer_xml.html">The full description can be found here.</a>
 </li>
 </ol>
 </p>
 </subsection>
 </section>
 </body>
 </document>
	<?xml version="1.0"?>
	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->

	<!DOCTYPE document[
	<!ENTITY sect-num '9b'>
	<!ENTITY rarr "→" >
	]>

	<document prev="build-ldap-test-plan.html" next="build-ws-test-plan.html" id="$Id$">


	<properties>
	<title>User's Manual: Building an Extended LDAP Test Plan</title>
	</properties>

	<body>
	<section name="&sect-num;. Building an Extended LDAP Test Plan" anchor="ldapexttest">
	<p>
	In this section, you will learn how to create a basic Test Plan to test an LDAP
	server.</p>
	<p>
	As the Extended LDAP Sampler is highly configurable, this also means that it takes
	some time to build a correct testplan. You can however tune it exactly up to your
	needs.
	</p>

	<p>
	You will create four users that send requests for four tests on the LDAP server. Also, you will tell
	the users to run their tests one time. So, the total number of requests is <code>(1 users) x (9 requests) x
	repeat 1 time) = 9</code> LDAP requests. To construct the Test Plan, you will use the following elements:<br/>
	<a href="test_plan.html#thread_group">Thread Group</a>,<br/>
	<complink name="Adding LDAP Extended Request Defaults"/>,<br/>
	<complink name="Adding LDAP Requests"/>, and<br/>
	<complink name="Adding a Listener to View/Store the Test Results"/>
	</p>
	<p>
	This example assumes that the LDAP Server is available at <code>ldap.test.com</code>.
	</p>
	<p>
	For the less experienced LDAP users, I build a <a href="ldapops_tutor.html">small
	LDAP tutorial</a> which shortly explains
	the several LDAP operations that can be used in building a complex testplan.
	</p>
	<p>
	Take care when using LDAP special characters in the distinguished name, in that case (e.g. you want to use a <code>+</code> sign in a
	distinguished name) you need to escape the character by adding an "<code>\</code>" sign before that character.
	Extra exception: if you want to add a <code>\</code> character in a distinguished name (in an add or rename operation), you need to use 4 backslashes.
	</p>
	Examples:
	<dl>
	<dt><code>cn=dolf\+smits</code></dt><dd>to add/search an entry with the name like <code>cn=dolf+smits</code></dd>
	<dt><code>cn=dolf \\ smits</code></dt><dd>to search an entry with the name <code>cn=dolf \ smits</code></dd>
	<dt><code>cn=c:\\\\log.txt</code></dt><dd>to add an entry with a name like <code>cn=c:\log.txt</code></dd>
	</dl>


	<subsection name="&sect-num;.1 Adding Users" anchor="ext_adding_users">
	<p>
	The first step you want to do with every JMeter Test Plan is to add a Thread Group element.
	The Thread Group tells JMeter the number of users you want to simulate, how often the users should send
	requests, and the how many requests they should send.
	</p>
	<p>
	Go ahead and add the <code>Thread Group</code> element by first selecting the <code>Test Plan</code>, clicking your
	right mouse button to get the <code>Add</code> menu, and then select <code>Add</code>→<code>Threads (Users)</code>→<code>Thread Group</code>.
	You should now see the <code>Thread Group</code> element under <code>Test Plan</code>. If you do not see the element, then "expand" the Test Plan tree by
	clicking on the Test Plan element.
	</p>
	<p>
	<figure image="ldaptest/extthreadgroup.png">
	Figure &sect-num;.1. Thread Group with Default Values</figure>

	</p>
	</subsection>
	<subsection name="&sect-num;.2 Adding LDAP Extended Request Defaults" anchor="add_ldapext_defaults">
	<p>
	Begin by selecting the LDAP Ext Users element. Click your right mouse button
	to get the <code>Add</code> menu, and then select <code>Add</code>→<code>Config Element</code>→<code>LDAP Extended Request Defaults</code>. Then,
	select this new element to view its Control Panel.
	</p>
	<p>
	Like most JMeter elements, the <code>LDAP Extended Request Defaults</code> Control Panel has a name
	field that you can modify. In this example, leave this field with the default value.
	</p>
	<p><figure image="ldaptest/extrequestdefaults.png"><br/>
	Figure &sect-num;.2 LDAP Defaults for our Test Plan</figure>
	</p>
	<p>
	For each of the different operations, some default values can be filled in.
	In All cases, when a default is filled in, this is used for the LDAP extended requests.
	For each request, you can override the defaults by filling in the values in the LDAP extended request sampler.
	When no value is entered which is necessary for a test, the test will fail in an unpredictable way!
	</p>
	We will not enter any default values here, as we will build a very small testplan, so we will explain all the different fields when we add the LDAP Extended samplers.
	</subsection>
	<subsection name="&sect-num;.3 Adding LDAP Requests" anchor="add_extrequests">
	<p>
	In our Test Plan, we want to use all 9 LDAP requests.
	</p>
	<ol>
	<li>
	Thread bind
	</li>
	<li>
	Search Test
	</li>
	<li>
	Compare Test
	</li>
	<li>
	Single bind/unbind Test
	</li>
	<li>
	Add Test
	</li>
	<li>
	Modify Test
	</li>
	<li>
	Rename entry (moddn)
	</li>
	<li>
	Delete Test
	</li>
	<li>
	Thread unbind
	</li>
	</ol>
	<p>
	JMeter sends requests in the order that you add them to the tree.
	</p>
	<p>
	Adding a requests always start by:<br/>
	Adding the <code>LDAP Extended Request</code> to the LDAP Ext Users element (<code>Add</code>→
	<code>Sampler</code>→<code>LDAP Ext Request</code>). Then, select the <code>LDAP Ext Request</code> element in the tree
	and edit the following properties.</p>


	<subsection name="&sect-num;.3.1 Adding a Thread bind Request" anchor="add_threadbind">
	<p>
	<ol>
	<li>
	Rename the element: "<code>1. Thread bind</code>"
	</li>
	<li>
	Select the "<code>Thread bind</code>" button.
	</li>
	<li>
	Enter the hostname value from the LDAP server in the Servername field
	</li>
	<li>
	Enter the portnumber from the LDAP server (<code>636</code> : ldap over SSL) in the port field
	</li>
	<li>
	<i>(Optional)</i> Enter the baseDN in the DN field, this baseDN will be used as the starting point for searches, add, deletes, etc.<br/>
	take care that this must be the uppermost shared level for all your request, e.g. when all information is stored under <code>ou=Users, dc=test, dc=com</code>, you can use this value in the basedn.<br/>
	</li>
	<li>
	<i>(Optional)</i> Enter the distinguished name from the user you want to use for authentication.
	When this field is kept empty, an anonymous bind will be established.
	</li>
	<li>
	<i>(Optional)</i> Enter the password for the user you want to authenticate with, an empty password will also lead to an anonymous bind.
	</li>
	<li>
	<i>(Optional)</i> Enter a value for the connection timeout with LDAP
	</li>
	<li>
	<i>(Optional)</i> Check the box Use Secure LDAP Protocol if you access with LDAP over SSL (ldaps)
	</li>
	</ol>
	</p>
	<p>
	<figure image="ldaptest/extthreadbind.png">
	Figure &sect-num;.3.1. Thread Bind example</figure>
	</p>
	</subsection>

	<subsection name="&sect-num;.3.2 Adding a search Request" anchor="add_searchreq">
	<p>
	<ol>
	<li>
	Rename the element: "<code>2. Search Test</code>"
	</li>
	<li>
	Select the "<code>Search Test</code>" button.
	</li>
	<li>
	<i>(Optional)</i> enter the searchbase under which you want to perform the search, relative to the basedn, used in the thread bind request.<br/>
	When left empty, the basedn is used as a search base, this files is important if you want to use a "base-entry" or "one-level" search (see below)
	</li>
	<li>
	Enter the searchfilter, any decent LDAP search filter will do, but for now, use something simple, like <code>(sn=Doe)</code> or <code>(cn=*)</code>
	</li>
	<li>
	<i>(Optional)</i> Enter the scope in the scope field, it has three options:
	<ol>
	<li>baseobject search<br/>only the given searchbase is used, only for checking attributes or existence.
	</li>
	<li>onelevel search<br/>Only search in one level below given searchbase is used
	</li>
	<li>subtree search<br/> Searches for object at any point below the given basedn
	</li></ol>
	</li>
	<li>
	<i>(Optional)</i> Size limit, specifies the maximum number of returned entries,
	</li>
	<li>
	<i>(Optional)</i> Time limit, specifies the maximum number of milliseconds, the SERVER can use for performing the search. It is NOT the maximum time the application will wait.<br/>
	When a very large returnset is returned, from a very fast server, over a very slow line, you may have to wait for ages for the completion of the search request, but this parameter will not influence this.
	</li>
	<li><i>(Optional)</i> Attributes you want in the search answer. This can be used to limit the size of the answer, especially when an object has very large attributes (like <code>jpegPhoto</code>). There are three possibilities:
	<ol><li>Leave empty (the default setting must also be empty) This will return all attributes.
	</li>
	<li>Put in one empty value (<code>""</code>), it will request a non-existent attributes, so in reality it returns no attributes
	</li>
	<li>Put in the attributes, separated by a semi-colon. It will return only the requested attributes
	</li></ol></li>
	<li>
	<i>(Optional)</i> Return object. Checked will return all java-object attributes, it will add these to the requested attributes, as specified above.<br/>
	Unchecked will mean no java-object attributes will be returned.
	</li>
	<li>
	<i>(Optional)</i> Dereference aliases. Checked will mean it will follow references, Unchecked says it will not.
	</li>
	<li>
	<i>(Optional)</i> Parse the search results?. Checked will mean it gets all results in response data, Unchecked says it will not.
	</li>
	</ol>
	</p>
	<p>
	<figure image="ldaptest/extsearch.png">
	Figure &sect-num;.3.2. search request example</figure>
	</p></subsection>

	<subsection name="&sect-num;.3.3 Adding a Compare Request" anchor="add_comparereq">
	<p>
	<ol>
	<li>
	Rename the element: "<code>3. Compare Test</code>"
	</li>
	<li>
	Select the "<code>Compare</code>" button.
	</li>
	<li>
	enter the entryname form the object on which you want the compare operation to work, relative to the basedn, e.g. "<code>cn=jdoe,ou=Users</code>"
	</li>
	<li>
	Enter the compare filter, this must be in the form "<code>attribute=value</code>", e.g. "<code>mail=jdoe@test.com</code>"
	</li>
	</ol>
	</p>
	<p>
	<figure image="ldaptest/extcompare.png">
	Figure &sect-num;.3.3. Compare example</figure>
	</p>
	</subsection>

	<subsection name="&sect-num;.3.4 Adding a Single bind/unbind" anchor="add_sbind">
	<p>
	<ol>
	<li>
	Rename the element: "<code>4. Single bind/unbind Test</code>"
	</li>
	<li>
	Select the "<code>Single bind/unbind</code>" button.
	</li>
	<li>
	Enter the FULL distinguished name from the user you want to use for authentication.<br/>
	E.g. <code>cn=jdoe,ou=Users,dc=test,dc=com</code>
	When this field is kept empty, an anonymous bind will be established.
	</li>
	<li>
	Enter the password for the user you want to authenticate with, an empty password will also lead to an anonymous bind.
	</li>
	</ol>
	<b>Take care</b>: This single bind/unbind is in reality two separate operations but cannot easily be split!
	</p><p>
	<figure image="ldaptest/extsbind.png">
	Figure &sect-num;.3.4. Single bind/unbind example</figure>
	</p>
	</subsection>

	<subsection name="&sect-num;.3.5 Adding an Add Request" anchor="add_addreq">
	<p>
	<ol>
	<li>
	Rename the element: "<code>5. Add Test</code>"
	</li>
	<li>
	Select the "<code>Add</code>" button.
	</li>
	<li>
	Enter the distinguished name for the object to add, relative to the basedn.
	</li>
	<li>
	Add a line in the "<code>add test</code>" table, fill in the attribute and value.<br/>
	When you need the same attribute more than once, just add a new line, add the attribute again, and a different value.<br/>
	All necessary attributes and values must be specified to pass the test, see picture!<br/>
	(sometimes the server adds the attribute "<code>objectClass=top</code>", this might give a problem.
	</li>
	</ol>
	</p>
	<p>
	<figure image="ldaptest/extadd.png">
	Figure &sect-num;.3.5. Add request example</figure>
	</p>
	</subsection>

	<subsection name="&sect-num;.3.6 Adding a Modify Request" anchor="add_modreq">
	<p>
	<ol>
	<li>
	Rename the element: "<code>6. Modify Test</code>"
	</li>
	<li>
	Select the "<code>Modify test</code>" button.
	</li>
	<li>
	Enter the distinguished name for the object to modify, relative to the basedn.
	</li>
	<li>
	Add a line in the "<code>modify test</code>" table, with the "<code>add</code>" button.
	</li>
	<li>
	You need to enter the attribute you want to modify, (optional) a value, and the opcode. The meaning of this opcode:
	<dl>
	<dt><code>add</code></dt><dd>this will mean that the attribute value (not optional in this case) will be added to the attribute.<br/>
	When the attribute is not existing, it will be created and the value added<br/>
	When it is existing, and defined multi-valued, the new value is added.<br/>
	when it is existing, but single valued, it will fail.</dd>
	<dt><code>replace</code></dt><dd>
	This will overwrite the attribute with the given new value (not optional here)<br/>
	When the attribute is not existing, it will be created and the value added<br/>
	When it is existing, old values are removed, the new value is added.</dd>
	<dt><code>delete</code></dt><dd>
	When no value is given, all values will be removed<br/>
	When a value is given, only that value will be removed<br/>
	when the given value is not existing, the test will fail
	</dd>
	</dl>
	</li>
	<li>
	<i>(Optional)</i> Add more modifications in the "<code>modify test</code>" table.<br/>
	All modifications which are specified must succeed, to let the modification test pass. When one modification fails,
	NO modifications at all will be made and the entry will remain unchanged.
	</li>
	</ol>
	</p>
	<p>
	<figure image="ldaptest/extmod.png">
	Figure &sect-num;.3.6. Modify example</figure>
	</p>
	</subsection>

	<subsection name="&sect-num;.3.7 Adding a Rename Request (moddn)" anchor="add_moddn">
	<p>
	<ol>
	<li>
	Rename the element: "<code>7. Rename entry (moddn)</code>"
	</li>
	<li>
	Select the "<code>Rename Entry</code>" button.
	</li>
	<li>
	Enter the name of the entry, relative to the baseDN, in the "<code>old entry name</code>"-Field.<br/>
	that is, if you want to rename "<code>cn=Little John Doe,ou=Users</code>", and you set the baseDN to "<code>dc=test,dc=com</code>",
	you need to enter "<code>cn=John Junior Doe,ou=Users</code>" in the <code>old entry name</code>-Field.
	</li>
	<li>
	Enter the new name of the entry, relative to the baseDN, in the "<code>new distinguished name</code>"-Field.<br/>
	when you only change the RDN, it will simply rename the entry<br/>
	when you also add a different subtree, e.g. you change from <code>cn=john doe,ou=Users</code> to <code>cn=john doe,ou=oldusers</code>, it will move the entry.
	You can also move a complete subtree (If your LDAP server supports this!), e.g. <code>ou=Users,ou=retired</code>, to <code>ou=oldusers,ou=users</code>,
	this will move the complete subtree, plus all retired people in the subtree to the new place in the tree.
	</li>
	</ol>
	</p>
	<p>
	<figure image="ldaptest/extmoddn.png">
	Figure &sect-num;.3.8. Rename example</figure>
	</p>
	</subsection>

	<subsection name="&sect-num;.3.8 Adding a Delete Request" anchor="add_delreq">
	<p>
	<ol>
	<li>
	Rename the element: "<code>8. Delete Test</code>"
	</li>
	<li>
	Select the "<code>Delete</code>" button.
	</li>
	<li>
	Enter the name of the entry, relative to the baseDN, in the <code>Delete</code>-Field.<br/>
	that is, if you want to remove "<code>cn=John Junior Doe,ou=Users,dc=test,dc=com</code>", and you set the baseDN to "<code>dc=test,dc=com</code>",
	you need to enter "<code>cn=John Junior Doe,ou=Users</code>" in the <code>Delete</code>-field.
	</li>
	</ol>
	</p>
	<p>
	<figure image="ldaptest/extdel.png">
	Figure &sect-num;.3.7. Delete example</figure>
	</p>
	</subsection>

	<subsection name="&sect-num;.3.9 Adding an unbind Request" anchor="add_unbind">
	<p>
	<ol>
	<li>
	Rename the element: "<code>9. Thread unbind</code>"
	</li>
	<li>
	Select the "<code>Thread unbind</code>" button.
	This will be enough as it just closes the current connection.
	The information which is needed is already known by the system
	</li></ol>
	</p>
	<p>
	<figure image="ldaptest/extthreadunbind.png">
	Figure &sect-num;.3.9. Unbind example</figure>
	</p>
	</subsection>
	</subsection>

	<subsection name="&sect-num;.4 Adding a Listener to View/Store the Test Results" anchor="add_ldapext_listener">
	<p>
	The final element you need to add to your Test Plan is a Listener.
	This element is responsible for storing all of the results of your LDAP
	requests in a file and presenting a visual model of the data. Select the Thread group
	element and add a <code>View Results Tree</code> (<code>Add</code>→<code>Listener</code>→<code>View Results Tree</code>)
	</p>
	<p>
	<figure image="ldaptest/extviewtree.png">
	Figure &sect-num;.4. View Result Tree Listener</figure>
	</p>
	<p>
	In this listener you have three tabs to view, the sampler result, the request and the response data.
	<ol>
	<li>
	The sampler result just contains the response time, the returncode and return message
	</li>
	<li>
	The request gives a short description of the request that was made, in practice no relevant information
	is contained here.
	</li>
	<li>
	The response data contains the full details of the sent request, as well the full details of the received answer,
	this is given in a (self defined) xml-style.
	<a href="ldapanswer_xml.html">The full description can be found here.</a>
	</li>
	</ol>
	</p>
	</subsection>
	</section>
	</body>
	</document>