notable to capture viewstate /event validation dynamic value
Srik
LR engine is unable to capture the dynamic value in the Fee&Escrows
Page (F&E Page) & encounters below error
" Invalid postback or callback argument. Event validation is
enabled using <pages enableEventValidation="true"/> in
configuration or <%@ Page EnableEventValidation="true"
%> in a page. For security purposes, this feature verifies
that arguments to postback or callback events originate from the
server control that originally rendered them. If the data is
valid and expected, use the
ClientScriptManager.RegisterForEventValidation method in order to
register the postback or callback data for validation."
We have re verified the LB, RB by capturing the values from View Source
a) By navigating manually to that F&E page
b) F&E page in the run time viewer window
c) from the Generation log and found they all are same
( FYI: Sometimes script runs fine with out any issues, but we
encounter this issue frequently).
We have googled the solution for this issue it is suggested to
maintain proper delays while recording and before executing the page.
We followed the same and maintained a delay upto 20 seconds while
recording (i.e. navigating from page to page) still the LR engine is
not able to capture the F&S page server response.
The error persists.
Application: .net app
LR Version: 9.52
Following are the Correlation details
web_reg_save_param("LFP_VS06",
"LB/IC=<input type=\"hidden\" name=\"__VIEWSTATE\" id=\"__VIEWSTATE\" value=\"",
"RB/IC=\" />",
"IgnoreRedirections=Yes",
"RelFrameID=1",
LAST);
web_reg_save_param("LFP_EV06",
"LB/IC=<input type=\"hidden\" name=\"__EVENTVALIDATION\"
id=\"__EVENTVALIDATION\" value=\"",
"RB/IC=\" />",
"IgnoreRedirections=Yes",
"RelFrameID=1",
LAST);
Also attached snapshot of the error.Any help will ne appreciated
Thanks in advance
Srikk
James Pulley
aspx application just fine up to 20MB in size for substantially long
business processes 90-150 steps. You are having difficulties in
implementation. One is a tool issue, the second a local issue.
(1) State management is not something captured once for an app, but
typically has to be updated with almost every page
(2) Multiple sets of state management variables could be active at any given
point. As we ask developers to be cognizant of their use of resources, once
you understand how many sets of state management variables are active then
reuse your existing state management variables to conserve memory on a per
virtual user basis. If you're not reusing you could simply be exhausting
memory on the local client.
(3) Your state management variable may be beyond the standard buffer length
for collection and you may need to expand this buffer
(4) If you are not checking to ensure that you are on the page you expect
then there is a very good chance that you are not and that the actual source
of the error is one or two pages previous to where you have the "dump" from
the web server
(5) Make sure that the data you are using is in the correct 'state' for the
set of actions you are taking, i.e. you are not checking the balance of a
closed account as an example. This is directly related to (4) above.
(6) Have you considered trimming your LB and RB conditions to just what you
need:
"LB=__VIEWSTATE\" value=\"","RB=\" "
"LB=__EVENTVALIDATION\" value=\"","RB/IC=\" "
James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix
Hi,
Thanks in advance
Srikk
--
You received this message because you are subscribed to the Google
"LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com To
unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en
Srikk
Please find my responses below to your suggestions.
> (1) State management is not something captured once for an app, but
> typically has to be updated with almost every page
> (2) Multiple sets of state management variables could be active at any given
> point. As we ask developers to be cognizant of their use of resources, once
> you understand how many sets of state management variables are active then
> reuse your existing state management variables to conserve memory on a per
> virtual user basis. If you're not reusing you could simply be exhausting
> memory on the local client.
> (3) Your state management variable may be beyond the standard buffer length
> for collection and you may need to expand this buffer
Five Viewstate & event validations in the previous pages. Also we have
increased the buffer size up to 3890100
> (4) If you are not checking to ensure that you are on the page you expect
> then there is a very good chance that you are not and that the actual source
> of the error is one or two pages previous to where you have the "dump" from
> the web server
previous pages containing the VS & EV are correlated successfully) and
verified the first occurance and trying to capture the dynamic value
from it.
I can describe the scenario like this
web_reg_save_param("LFP_VS5");
web_reg_save_param("LFP_EV5");
web_submit_data("Property page.aspx”); -- Successfully captured&
substitited the VS & EV
web_reg_save_param("LFP_VS6");
web_reg_save_param("LFP_EV6");
web_submit_data("FeesandEscrows.aspx"); -- LR Engine is not able to
capture ( or i can say intermittently) the dynamic value.
> (5) Make sure that the data you are using is in the correct 'state' for the
> set of actions you are taking, i.e. you are not checking the balance of a
> closed account as an example. This is directly related to (4) above.
> (6) Have you considered trimming your LB and RB conditions to just what you
> need:
> "LB=__VIEWSTATE\" value=\"","RB=\" "
> "LB=__EVENTVALIDATION\" value=\"","RB/IC=\" "
verified the boundaries from the View source window, yet the result is
same.
Also you were speaking about the tool issue & Local issue. can you
elobarate on this.
Regards
Srikk
> -----Original Message-----
> From: lr-loa...@googlegroups.com [mailto:lr-loa...@googlegroups.com]
>
> On Behalf Of Srik
> Sent: Wednesday, March 09, 2011 12:10 PM
> To: LR-Loa...@googlegroups.com
>
> - Show quoted text -
James Pulley
returned was in fact returned. You can have a viewstate collected off of an
unexpected page directly related to the state of the data or an error page
for the application. You need to be explicit in your examination of
returned pages. See web_reg_find() (and not the automated variety) for
insight on implementation.
Local vs Tool issue: LoadRunner has a very long proven track record of
being able to collect viewstates and successfully replace viewstate
information on playback. However if the business process fails in some way
before the page in question is loaded, then the valid collection of a
viewstate will result in an error when the state passed back as a part of a
request where the request has no possible context to the state in question,
i.e. you cannot submit a form from a page which did not return a form.
James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix
Floris Kraak
>> (3) Your state management variable may be beyond the standard buffer length
>> for collection and you may need to expand this buffer
>
> Srik: Yes we have successfully captured & substituted all the previous
> Five Viewstate & event validations in the previous pages. Also we have
> increased the buffer size up to 3890100
*cough*
What?!?
You need almost 4MB to capture a single viewstate variable?
Here is where a good performance tester will tell the development team
to go back to the drawing board and redesign the state management.
Performance issues are all but guaranteed if this much data needs to
be transferred back and forth between each step. Consider for a second
what happens to your response times when someone on a remote site with
a 2Mb/512k split ADSL link needs to send that back to
How many of these 4Mb variables do you typically need to capture on a
single page? How much memory do you have available on your load
generators? How much memory does the server side of this application
have, for that matter?
>> (4) If you are not checking to ensure that you are on the page you expect
>> then there is a very good chance that you are not and that the actual source
>> of the error is one or two pages previous to where you have the "dump" from
>> the web server
>
> Srik: We are sure that we are on the right page ( bescause all the
> previous pages containing the VS & EV are correlated successfully) and
> verified the first occurance and trying to capture the dynamic value
> from it.
Are you certain that each page displays the expected result, as well?
Just correlating dynamic variables is not necessarily enough if all
pages look the same. You need to make 100% sure that what the customer
is supposed to see is actually on the page in question.
Regards,
Floris
---
'Many people asked me if I was afraid to fly and implied that I should
have stayed home, close to family and friends. I replied that if I had
stayed home, the terrorists would have won.
Unfortunately, my government does not agree with my definition of
winning. They think that living in fear and trying desperately to keep
us all 100% safe while flying is the most effective way to fight
terrorism. It reminds me of a boss that told me he liked it when
people lived in fear of being fired, they worked harder. I told him
being fired held no fear for me. When you live in fear, you do
irrational things - like sending millions of people's shoes through an
xray scanner every day.'
-- Stormy Peters
Srikk
Every previous page is validated with a text check (Login, Edit Page,
F&S property Page.). Manully the business flow is working fine. But
iam not finding any way why it is not capturing the value. more over
we dont find any dynamic values other than VS & EV. But any how we
will recheck & concentrate on that page which is being submtting to
server (But also we can recall intermittently the script works fine)
On Mar 10, 6:25 pm, "James Pulley" <loadrunner-li...@jamespulley.com>
wrote:
> A capture of aviewstatedoes not mean that the page you expected to be
> returned was in fact returned. You can have aviewstatecollected off of an
> for the application. You need to be explicit in your examination of
> returned pages. See web_reg_find() (and not the automated variety) for
> insight on implementation.
>
> Local vs Tool issue: LoadRunner has a very long proven track record of
> being able to collect viewstates and successfully replaceviewstate
> information on playback. However if the business process fails in some way
> i.e. you cannot submit a form from a page which did not return a form.
>
>
>
> -----Original Message-----
> From: lr-loa...@googlegroups.com [mailto:lr-loa...@googlegroups.com]
>
> On Behalf Of Srikk
> Sent: Thursday, March 10, 2011 6:17 AM
> To: LoadRunner
> James,
>
> Please find my responses below to your suggestions.
>
> > (1) State management is not something captured once for an app, but
> > typically has to be updated with almost every page
> > (2) Multiple sets of state management variables could be active at any
> given
> > point. As we ask developers to be cognizant of their use of resources,
> once
> > you understand how many sets of state management variables are active then
> > reuse your existing state management variables to conserve memory on a per
> > virtual user basis. If you're not reusing you could simply be exhausting
> > memory on the local client.
> > (3) Your state management variable may be beyond the standard buffer
> length
> > for collection and you may need to expand this buffer
>
> Srik: Yes we have successfully captured & substituted all the previous
> > - Show quoted text -
>
> --
> You received this message because you are subscribed to the Google
> "LoadRunner" group.
> To post to this group, send email to LR-Loa...@googlegroups.com
> To unsubscribe from this group, send email to
> LR-LoadRunne...@googlegroups.com
Srikk
> You need almost 4MB to capture a singleviewstatevariable?
>
> Here is where a good performance tester will tell the development team
> to go back to the drawing board and redesign the state management.
> Performance issues are all but guaranteed if this much data needs to
> be transferred back and forth between each step. Consider for a second
> what happens to your response times when someone on a remote site with
> a 2Mb/512k split ADSL link needs to send that back to
>
> How many of these 4Mb variables do you typically need to capture on a
> single page? How much memory do you have available on your load
> generators? How much memory does the server side of this application
> have, for that matter?
lengthiest one. Still we haven’t have any access for LG we are in the
phase of scripting more over we don’t have acces on the server side of
the application.
> Are you certain that each page displays the expected result, as well?
> Just correlating dynamic variables is not necessarily enough if all
> pages look the same. You need to make 100% sure that what the customer
> is supposed to see is actually on the page in question.
EV can be observed with proper data being populated also they are
valiadted with proper text checks
Earlier pages are
Login
Click on Edit link
Click On F&S link
Click on Add Fee - is the page where script fails.