After discussing the dynamic data handling in the previous post in detail, let’s move to the next post-processor element called ‘Boundry Extractor’. In JMeter, the purpose of Boundary Extractor is as same as for Regular Expression Extractor i.e. to get the dynamic value from the response, but the way of implementation is different. In a Regular Expression Extractor, we use the regular expression (statement) to fetch the dynamic value but in Boundary Extractor, instead of using a one-linear regular expression statement with a complex token we just need to provide left and right boundaries of the dynamic value which needs to be captured.
If we compare Regular Expression Extractor and Boundary Extractor with LoadRunner correlation functions then we find that Regular Expression Extractor acts as web_reg_save_param_regexp() while the Boundary Extractor element acts as the normal correlation function of LoadRunner i.e. web_reg_save_param(). If you want to get more details on how and why dynamic values need to correlate then refer to the previous post.
How to add a ‘Boundary Extractor’?
Follow the below steps:
- Select the ‘Sampler’ element whose response contains the dynamic value and you want to capture it.
- Right-click on the element
- Hover the mouse on ‘Add’
- Hover the mouse on ‘Post Processors’
- Click ‘Boundary Extractor’
What are the input fields of the ‘Boundary Extractor’?
‘Boundary Extractor’ has the following input fields:
- Name: To provide the name of the post-processor
- Comments: To provide arbitrary comments (if any)
- Apply to: To define the search scope of dynamic value.
- Main sample and sub-samples: In case, the request is redirected then use this search scope, so that dynamic content can be searched in the response of both main and re-directed requests.
- Main sample only: When the request is not re-directed or dynamic value is present only in the response of the main request then use this search scope.
- Sub-samples only: When the request is re-directed and dynamic value is available in the response of the re-directed request then you can use this search scope.
- JMeter Variable Name to use: If the dynamic value needs to be extracted from the value of any JMeter variable then you need to select this option and provide the JMeter Variable name in the text field.
- Field to check: It refines the search scope and instructs JMeter to search the dynamic value in the specific part of a sample, sub-sample or JMeter variable depending on the option you selected in the “Apply to” section.
- Body: This option instructs JMeter to search in the body of the response. The header of the response does not include in the search scope.
- Body (unescaped): The search includes all the HTML escaped code like &, ", < etc. This search scope impacts JMeter performance, hence it is recommended to select this option when really required.
- Body as a Document: This option allows JMeter to search the dynamic value in the document returned by the server.
- Response Headers: The search will be conducted only on the header part of the response and captured the dynamic value. This option does not apply to the non-HTTP request.
- Request Headers: This option instructs JMeter to search in the header part of the request. It is helpful when the request is redirected and the dynamic value is passed in the header of the sub-request. This option does not apply to non-HTTP requests.
- URL: The search scope will be URL only when you select this option. This option is used when the request is re-directed and the dynamic value is available in the URL part. The best example of this is OAuth access token capturing.
- Response Code: This option is used to capture the response code. Let’s say you have two transaction flows and selection of any flow depends on the pass (Response code = 200) and Fail (Response code != 200) staus of the previous request. In such a scenario you can choose “Response Code” as an option which returns the response code.
- Response Message: To capture the response message this option is used. The response message could be like OK, Gateway Timeout etc.
- Name of created variable: The name of the variable in which dynamic value will be stored. This is also called a RegEx variable.
- Left Boundary: The left boundary of the dynamic value. The value of the left boundary attribute is case-sensitive and do not support regular expressions. This is a mandatory attribute.
- Right Boundary: The right boundary of the dynamic value. The value of the right boundary attribute is case-sensitive and do not support regular expressions. This is a mandatory attribute.
- Match No. (0 for random): If more than 1 string is matched in a response data and you need to capture a dynamic value which comes at a particular place (say 4th place) then you have to give 4 as an input and JMeter will recognize all the matched values on the page but store only 5th value in the regular expression variable. It is as same as the ordinal in the LoadRunner. ‘-1’ is used to capture all the values while ‘0’ is used to pick a random value from the list of match dynamic values.
- Default Value: If the regular expression does not match, then the regex variable will be set to the default value (e.g. Not_Found). This is particularly useful for debugging tests.
- Use empty default value: If this checkbox is selected then JMeter set the empty string for regular expression variable. This is not recommended because you can not identify whether regular expression working properly or not?
You may be interested:
- Performance Testing Tutorial
- Performance Engineering Tutorial
- Micro Focus LoadRunner Tutorial
- NeoLoad Tutorial