{"id":1537,"date":"2010-09-27T09:00:57","date_gmt":"2010-09-27T13:00:57","guid":{"rendered":"http:\/\/www.webperformanceinc.com\/load_testing\/blog\/?p=1537"},"modified":"2017-05-24T11:49:43","modified_gmt":"2017-05-24T15:49:43","slug":"custom-extractors-in-web-performance-load-tester","status":"publish","type":"post","link":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/2010\/09\/custom-extractors-in-web-performance-load-tester\/","title":{"rendered":"Custom Extractors in Web Performance Load Tester"},"content":{"rendered":"

This tutorial will outline the steps to configure a custom extractor in Load Tester.\u00a0 Extractors are used to recognize small pieces of data in your application and apply them to future transactions within a test case.<\/p>\n

<\/p>\n

I will be assuming that you are already familiar with building and running a simple test case<\/a> in Web Performance Load Tester.\u00a0 I will also assume that you already know how to use a dataset to generate unique input<\/a> for a test case.<\/p>\n

If you prefer, you can watch this tutorial in the form of a screen cast<\/a>.<\/p>\n

We’ll be using SugarCRM<\/a> as the object of our test.\u00a0 Let’s begin by establishing the use case.<\/p>\n

Our Use Case
\n<\/strong><\/p>\n

1) We log in to Sugar, using a username and password we have already created:<\/p>\n

\"00100-sugar-login-prompt\"<\/a><\/p>\n

2) Then we choose to create a new contact:<\/p>\n

\"00200-sugar-create-contact\"<\/a><\/p>\n

3) And we choose to assign an account to that contact:<\/p>\n

\"00300-sugar-select-account\"<\/a><\/p>\n

4) We type “Account 7” into the “Account Search” form and click “Search.”\u00a0 Account 7 appears in the list and we click it.\u00a0 For the purpose of this tutorial, it’s important that we actually use the search feature.\u00a0 This assigns “Account 7” to our contact:<\/p>\n

\"00400-sugar-account-dialog\"<\/a><\/p>\n

5) And Sugar should now confirm that our new contact is associated with Account 7.<\/p>\n

\"00600-sugar-added-account-correctly\"<\/a><\/p>\n

Building a Test Case
\n<\/strong><\/p>\n

Now we’re going to create a test case in Web Performance Load Tester that will simulate this user interaction.\u00a0 Recording the test case is a simple matter of performing the above actions inside Load Tester’s record feature.<\/p>\n

Naturally, when we go to replay this test case, it won’t work, because on the subsequent run SugarCRM wisely complains that we already have a contact named George Jetson.\u00a0 Sugar’s complaint diverges from our canonical use case, triggering an error.<\/p>\n

The solution is to build a dataset of unique names:<\/p>\n

\"00700-set-up-data-table-of-names-and-accounts\"<\/a><\/p>\n

We went ahead and associated each name with a unique phone number and account — a good way to exercise our database.\u00a0 But when we go to replay our test case we notice another problem:<\/p>\n

\"00800-oh-noes-account-1\"<\/a><\/p>\n

Somehow Aaron Smith was associated with Account 1, when his line item associates him with Account 0.\u00a0 How did this happen?<\/p>\n

The first step is to look at our fields view, which is a table of all of the configurable outgoing data in any HTTP transaction.<\/p>\n

\"00900-fields-view\"<\/a><\/p>\n

We see that while Load Tester is correctly configured to pass in an account name from our data set (highlighted in blue), somehow there is an “account_id” (highlighted in red) field that has not been configured.<\/p>\n

We know whether or not a field is configured by the\u00a0\"01000-configured-icon\"<\/a> icon, which is present only for dynamic fields.\u00a0 If this icon is absent, then the field is a static literal.\u00a0 If this icon is present, then the field is taken from either a dataset or a user state variable.<\/p><\/blockquote>\n

It’s a fair guess that Sugar uses this 128-bit hex string as a unique identifier into account names.\u00a0 Although we pass the account name properly into the search field, Sugar sends back this unique identifier and uses it for the rest of the test case.<\/p>\n

Configuring a Custom Extractor<\/strong><\/p>\n

We can use an extractor to grab this hex string and store it in a user state variable.\u00a0 But we have to find it first:<\/p>\n

\"01100-grep-the-hex\"<\/a><\/p>\n

It takes a little bit of application-specific knowledge to know which instance of the hex string to extract.\u00a0 If we extract from the first page that contains it, we’re actually just extracting from a default list of accounts.\u00a0 The second page in our search results here also happens to represent the search results from SugarCRM.<\/p>\n

We see that the hex string appears in a “send_back” javascript onclick handler.<\/p>\n

We’ll create an extractor on that page.\u00a0 First, select Sugar’s account search results page in Load Tester.\u00a0 Click the “Actors” tab and choose “Extractors.”\u00a0 Then click the green plus (‘+’) sign to add an extractor:<\/p>\n

\"01150-add-an-extractor\"<\/a><\/p>\n

The simplest type of extractor is the “String Delimited Extractor.”\u00a0 This extractor needs a prefix and suffix string to capture a value from the HTML content of the search page.\u00a0 We use this extractor to recognize the onclick handler and function call and capture everything between single-quote marks, representing SugarCRM’s internal hex string.<\/p>\n

\"01200-making-the-extractor\"<\/a><\/p>\n

\"01300-extractor-configured-and-named\"<\/a><\/p>\n

We then store the result of the extractor into a user state variable called “account_id.”\u00a0 We choose this name to match the “account_id” field, but we could have named it anything, such as “foo” or “value_of_account_id”.<\/p>\n

User state variables that are created by Load Tester’s Application State Management Wizard get a hash prefix (‘#’) and, if it occurs more than once, an index number in square brackets.\u00a0 For example, “#record [2]”.\u00a0 These annotations are designed to help the human user interpret the Application State Management Wizard’s behavior.\u00a0 You should name variables according to any convention that you find easy to understand, but note that the Application State Management Wizard may overwrite your work if you begin a variable name with a non-alphanumeric character,<\/p><\/blockquote>\n

We also see that the “Create Extractor” dialog box displays the extracted value and highlights the extraction in blue.\u00a0 This is a way to verify that we are actually extracting the value we intended.<\/p>\n

Click OK, switch to the fields view, and double click the unconfigured “account_id” field to bring up the configuration dialog box:<\/p>\n

\"01400-double-click-the-configure-for-the-field\"<\/a><\/p>\n

We then set the “account_id” field to read a value dynamically from the “account_id” user state variable:<\/p>\n

\"01500-store-account-id-to-field\"<\/a><\/p>\n

We can then test our new configuration by running another replay.\u00a0 We should find that new contacts get associated with the correct account name on each replay:<\/p>\n

\"01600-account-id-works-yay\"<\/a><\/p>\n

Configuring a Detection Rule
\n<\/strong><\/p>\n

We made this extractor work correctly.\u00a0 But do we need to configure a new extractor every time we perform a recording that uses this “account_id” field?\u00a0 No — we can extend the Application State Management Wizard’s logic to recognize the javascript “send_back” method.<\/p>\n

Access the Detection Rules editor inside Load Tester’s preferences dialog box.\u00a0 Browse to Web Performance > Configuration Wizards > Application State > Detection Rules.<\/p>\n

\"01700-detection-rule-preferences-box\"<\/a><\/p>\n

We can parametrize nearly any rule via a system of name-value pairs.\u00a0 For our detector, we’ll use “sdd” (String Delimited Detector) as the detector type, and enter the correct prefix and suffix string.\u00a0 The “detector.name” name-value pair is an arbitrary name for our detector, but the “field.name” tells the Application State Management Wizard which field it should try to apply the detection rule to.<\/p>\n

Use the \u201cTest selected Rule(s)\u201d button to verify that your name-value pairs match the legal expected format of the Application State Management Wizard’s logic model.<\/p>\n

Whenever we create another recording, or simply re-run the Application State Management Wizard, Load Tester will scan for additional onclick handlers that call \u201csend_back\u201d with the ‘Accounts’ parameter, and match those handlers with any outgoing fields.<\/p>\n

Custom Detection Rules are, however, an advanced feature of Load Tester, so you should review the reference documentation before you create your own.\u00a0 You can find reference documentation under the headings \u201cAdvanced Field Assignments<\/a>\u201d and \u201cConfiguring Dynamic Fields<\/a>\u201d in Load Tester’s build-in help service.<\/p>\n

Summary
\n<\/strong><\/p>\n

Extractors capture data from HTTP responses, user state variables retain this data until it is needed, and the fields view allows us to direct this data back to the server.\u00a0 The Application State Management Wizard can automatically configure the overwhelming majority of dynamic fields, but occasionally an important field is left unconfigured, and we can use a custom extractor to configure that field.<\/p>\n

We can use custom detection rules to generate custom extractor-field pairs automatically.\u00a0 Detection rules are an advanced feature, so we should only use a custom detection rule when we find that manually configuring an extractor is too repetitive.\u00a0 However, when we actually need them, detection rules can save hours of our time.<\/p>\n

— Lane, Engineer at Web Performance<\/p>\n","protected":false},"excerpt":{"rendered":"

This tutorial will outline the steps to configure a custom extractor in Load Tester.\u00a0 Extractors are used to recognize small pieces of data in your application and apply them to future transactions within a test case.<\/p>\n","protected":false},"author":53,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[53,103,104,30],"class_list":["post-1537","post","type-post","status-publish","format-standard","hentry","category-load-tester-software","tag-extractor","tag-field","tag-sugarcrm","tag-tutorial"],"_links":{"self":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/1537","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/comments?post=1537"}],"version-history":[{"count":40,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/1537\/revisions"}],"predecessor-version":[{"id":5793,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/1537\/revisions\/5793"}],"wp:attachment":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/media?parent=1537"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/categories?post=1537"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/tags?post=1537"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}