RE: help

[John Kavadias <jo...@nstc.nec.com.au>]

Rohit wrote:

 - Sample Test Plan
   - Thread Group
     - HTTP Request -> jsp/login.jsp
     - HTTP Request -> jsp/pageView.jsp?workItemId=2334&workFlowId=14
     - HTTP Request -> jsp/nextPage.jsp?workItemId=.*&workFlowId=.*
       - HTML Link Parser
     - HTTP Request -> jsp/thirdPage.jsp?workItemId=.*&workFlowId=.*
       - HTML Link Parser
     - HTTP Request -> jsp/fourthPage.jsp?workItemId=.*&workFlowId=.*
       - HTML Link Parser
     - HTTP Request -> jsp/fifthPage.jsp?entityItemId=<Value of 
workItemId>&workFlowId=.*
       - HTML Link Parser

> Is the above example possible?

Yes, the intent of the plan is possible in JMeter.

> 1) Do I need to use HTML Link Parser for all the subsequent HTTP requests to grab the value of 'workItemId'?

When structuring your plan around HTML Link Parser capabilities, I think so. 

The Path of the HTTP Request is important to the substitution of '.*', not just the parameter name. I found this out the hard way.

I think if you use __regexFunction() to drive your test sequence, you won't need to use any HTML Link Parsers and will make JMeter do less work to get the outcome you want.

However using regex may have implications for the durability of your test plan if the application changes. This is an issue only you can judge properly.

> 2) I'm not well aware of regex maybe I need to go through some documentation before I understand

If you do not know regex, here is a pointer:

http://jakarta.apache.org/oro/api/org/apache/oro/text/regex/package-summary.html#package_description

If this is too steep or terse, try reading a manual page or article about sed or awk, or follow the link on the page above to the Perl documentation. Be aware that sed and awk regex (or RE) have a more limited syntax and thus not as terse as Perl regex.

> but meanwhile if you can you let me know if I can grab value of 'workItemId' and pass it to 'entitityItemId' using regex .. that would be actually great. 

Yes. I'll try and show how by evolving your test plan in two steps.

OK, my habit in organising test trees is to have the HTML Link Parser precede the HTTP request that USES the results of its parsing. So I would suggest:

 - Sample Test Plan
   - Thread Group
     - HTTP Request -> jsp/login.jsp
A    - HTTP Request -> jsp/pageView.jsp?workItemId=2334&workFlowId=14
B    - HTML Link Parser
C    - HTTP Request -> jsp/nextPage.jsp?workItemId=.*&workFlowId=.*
D    - HTML Link Parser
E    - HTTP Request -> jsp/thirdPage.jsp?workItemId=.*&workFlowId=.*
F    - HTML Link Parser
G    - HTTP Request -> jsp/fourthPage.jsp?workItemId=.*&workFlowId=.*
H    - HTML Link Parser
I    - HTTP Request -> jsp/fifthPage.jsp?entityItemId=<Value of workItemId>&workFlowId=.*

The HTML Link Parsers are preceding siblings of the HTTP Requests in this setup, rather than immediate children.

[[ Anyone more in the know, please comment on whether this makes a difference. I expected that it would, given the JMeter manual examples are structured more like this than Rohit's original. I cannot be more definite as I have read little of the JMeter source and don't know its structure and strategies for compiling and executing test plans. ]]

OK, now your problem will be that you need to generate

  entityItemId=<Value of workItemId>

as a parameter to the last HTTP Request, labelled 'I'.

The substitution of '.*' for HTTP Request vs the results of the most recent HTML Link Parse cannot do this for you, I think. The URL path and parameter names must match for substitutions to occur. You would end up with a generated parameter value of '.*'.

So, I would drop the HTML Link Parser labelled 'H' and use something like this, specified as the value field of parameter entityItemId of HTTP Request labelled 'I':

  ${__regexFunction(workItemId=(\d+)\D,$1$,1,,NOMATCH,wiidREF)}

The first parameter in the comma separated list is the regex. The second is the substitution value, the 'output' of the function invocation.

There is one (parethesised) group in the regex: (\d+). The $1$ in the substitution value will expand to the string matched by \d+. $1$ matches the first parenthesised group, $2$ the second (if present), etc. $0$ is the whole regex match.

To explain the rest of the argument list, the documentation on __regexFunction is here (or use the JMeter doc from your build of JMeter):

http://jakarta.apache.org/jmeter/usermanual/component_reference.html#__regexFunction

You may want RAND as the third argument rather than 1. This depends on the details of you application.

The general documentation on JMeter functions is here:

http://jakarta.apache.org/jmeter/usermanual/functions.html

[[ Create the function string with the JMeter Function Helper Dialog, which allows you to encode the function string. Copy the generated encoded string and paste it into the HTTP Request parameter value field. ]]

Now, the LAST argument to __regexFunction() 'tags' the particular regex invocation and give you a handle to the results of the most recent execution of the function.

So, the last complete match, which you would reference as $0$ in the second argument of __regexFunction, is available as ${wiidREF_g0}.

The 'sub-matches' made by parenthesised groups in the regex are available as ${wiidREF_g1}. ${wiidREF_g2} does not exist in our example, but in general _g2 for the sub-match of the second group, _g3 for the third, etc.

Now, you can see that if your Id parameters in you request URLs are fixed for the entire request sequence, you need only extract them once from the first response that contains them, with a single ${__regexFunction()} call. For the rest of the sequence just use the ${tag_gN} mechanism.

What you lose in comparison with HTML Link Parser is the requirement to match the Path of the current request in the content of the previous response. Depending on the precise content of your response, you may be able to extend the regex approach to regain this.

Is THAT the time?
See you all later.
John Kavadias.

RE: help

[Mike Stover <ms...@apache.org>]

> OK, my habit in organising test trees is to have the HTML Link Parser precede the HTTP request that USES the results of its parsing. So I would suggest:
> 
>  - Sample Test Plan
>    - Thread Group
>      - HTTP Request -> jsp/login.jsp
> A    - HTTP Request -> jsp/pageView.jsp?workItemId=2334&workFlowId=14
> B    - HTML Link Parser
> C    - HTTP Request -> jsp/nextPage.jsp?workItemId=.*&workFlowId=.*
> D    - HTML Link Parser
> E    - HTTP Request -> jsp/thirdPage.jsp?workItemId=.*&workFlowId=.*
> F    - HTML Link Parser
> G    - HTTP Request -> jsp/fourthPage.jsp?workItemId=.*&workFlowId=.*
> H    - HTML Link Parser
> I    - HTTP Request -> jsp/fifthPage.jsp?entityItemId=<Value of workItemId>&workFlowId=.*
> 
> The HTML Link Parsers are preceding siblings of the HTTP Requests in this setup, rather than immediate children.
> 
> [[ Anyone more in the know, please comment on whether this makes a difference. I expected that it would, given the JMeter manual examples are structured more like this than Rohit's original. I cannot be more definite as I have read little of the JMeter source and don't know its structure and 
strategies for compiling and executing test plans. ]]

Better to attach the Link Parser as children to the HTTP Requests that need it.  If a test plan 
were made as above, then every Request would be passed through each of those Link 
Parsers for potential modification, which would be a performance drain.  The Link Parsers 
should not be thought of as "going in order" like Sampler go in order from top to bottom.  In 
fact, Samplers are the only elements that have an order.  All other elements are hierarchical 
only.  A more compact way to do this would be:

  - Sample Test Plan
    - Thread Group
      - HTTP Request -> jsp/login.jsp
 A    - HTTP Request -> jsp/pageView.jsp?workItemId=2334&workFlowId=14
 B    - Simple Controller
 C        - HTML Link Parser
 D        - HTTP Request -> jsp/nextPage.jsp?workItemId=.*&workFlowId=.*
 E        - HTTP Request -> jsp/thirdPage.jsp?workItemId=.*&workFlowId=.*
 F        - HTTP Request -> jsp/fourthPage.jsp?workItemId=.*&workFlowId=.*
 G         - HTTP Request -> jsp/fifthPage.jsp?entityItemId=<Value of 
workItemId>&workFlowId=.*

In this plan, the HTML Link Parser will be applied to each of the HTTP Requests that also live 
under the Simple Controller.  This is how JMeter works in general - Timers, Listeners, Config 
Elements, Modifiers, etc.

--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>