Differentiating postback requests using a web server log analyzer

[Peter Jaffe]

I've seen a few posts on this topic, but still haven't found a clean
solution. Anyone have other suggestions or feel that one of the
options I highlight below is the way to go?

The Problem
-----------
A sequence of user interactions span multiple ASP.NET http POST
PostBacks within the same page. There is a need to be able to
identify each step of the interaction at the web server level (using a
log analyzer such as WebTrends). However, the requested resource,
query string, and cookies are the only things accessible and the true
differentiation is in the form post data.
Possible Solutions
------------------
I have considered the following options, but #2 seems like the only
"complete" solution, yet it still doesn't feel right...

1) Alter the ASP.NET framework's __doPostBack JavaScript method to
add the eventTarget to the query string of the form's action.
- This won't cover Buttons or ImageButtons since they don't use
__doPostBack
- It can result in cryptic page identifiers (e.g.
ucInquiryResult$grdList$_ctl5$_ctl0)
+ Implementation Options:
* A Response filter - quick POC provided feasible, but what is the
performance cost?
* Try to override the function that generates the __doPostBack
function, but it appears to be in the private method
System.Web.UI.Page.RenderPostBackScript(), so I don't think this is a
viable option.

2) Create custom WebControls that inherit from Button, ImageButton,
LinkButton, etc. These could expose a property whose value is passed
to client side JavaScript as part of the click event. The JavaScript
would rewrite the query string of the form's action attribute.
- Not sure how many controls this would involve. What about
LinkButtons in a ButtonColumn of a DataGrid...?

3) Implement a response filter that recognizes input and anchor
elements and inserts the necessary JavaScript to inject identifiers
into the form action's query string.
+ This is similar to #2, but would be implemented as a central
Response filter rather than having to use multiple custom WebControls.
- However, there is no clear place to specify the desired
"identifier" and therefore results in the same "cryptic identifier"
problem of option #1.
- The string manipulation to generate this additional JavaScript
could be messy and error prone.

4) Could do one-off logic on each relevant control that triggers a
PostBack.
- Hard to maintain. Requires a full sweep of the app and ongoing
diligence, or else the choice to respond to requests from those who
want to collect statistics. The later would have an annoying lag in
getting the requested "identifiers" into production.

5) Implement a page name mapping layer in an HttpModule so a set of
URLs (one for each "identifier") can be used to target the same page.
- This can help for recognizing multiple different entry points, but
the subsequent PostBack requests will be indistinguishable from the
previous without employing another strategy for altering the action of
the HTML form element.

6) Instrument from inside the application. Need to figure out how
this would be published so it can be consumed by the appropriate
people/tools.
Thanks for your time,

Pete

[John Saunders]

"Peter Jaffe" <pj****@nevo.com> wrote in message
news:5c**************************@posting.google.c om...

I've seen a few posts on this topic, but still haven't found a clean
solution. Anyone have other suggestions or feel that one of the
options I highlight below is the way to go?

The Problem
-----------
A sequence of user interactions span multiple ASP.NET http POST
PostBacks within the same page. There is a need to be able to
identify each step of the interaction at the web server level (using a
log analyzer such as WebTrends). However, the requested resource,
query string, and cookies are the only things accessible and the true
differentiation is in the form post data.

If I were you, I'd forget about all of the implementation ideas you came up
with, except for "6". Here's why.

You need to be able to log significant state changes. That's not a problem.
The problem is that all of the techniques you mention tie the logging of
state changes to the implementation details of how the page performed the
state change. Consider the case where you have a button which causes a state
change you need to log. What happens if you change that button to be a
LinkButton? If your logging mechanism needs to be concerned with the
implementation details of your page, you will have to change it.

Instead, have the code which performs the state change log the state change.
That way, it won't matter _how_ the state change is made, you'll log it just
the same. You might even want to centralize this in a class, so that you can
confirm that each state change is valid before you make it.
--
John Saunders
johnwsaundersiii at hotmail

[Peter Jaffe]

Hi John,

Thanks for the quick and insightful reply. I completely agree that #6 is
the more pure architectural choice. However, the other aspect of the
problem I am facing is that my client already has WebTrends in place for
website usage analysis, and a rewrite of the app from ASP to ASP.NET has
resulted in reduced information being available through WebTrends reports.
I was hoping to be able to find some reasonably elegant compromise that
would at least uniquely tag each "view" thereby restoring their ability to
get useful info out of WebTrends (even if it involved changing the WebTrends
reports a little as UI controls are changed).

I may have to just start fighting the battle of either hooking into a
WebTrends API (I still have to look into this) or else encouraging the
client to use different reporting tools to get the statistics they used to
consume from WebTrends.

Thanks again!

Pete

"John Saunders" <jo**************@notcoldmail.com> wrote in message
news:OA**************@TK2MSFTNGP10.phx.gbl...

"Peter Jaffe" <pj****@nevo.com> wrote in message
news:5c**************************@posting.google.c om...

I've seen a few posts on this topic, but still haven't found a clean
solution. Anyone have other suggestions or feel that one of the
options I highlight below is the way to go?

The Problem
-----------
A sequence of user interactions span multiple ASP.NET http POST
PostBacks within the same page. There is a need to be able to
identify each step of the interaction at the web server level (using a
log analyzer such as WebTrends). However, the requested resource,
query string, and cookies are the only things accessible and the true
differentiation is in the form post data.
If I were you, I'd forget about all of the implementation ideas you came

up with, except for "6". Here's why.

You need to be able to log significant state changes. That's not a problem. The problem is that all of the techniques you mention tie the logging of
state changes to the implementation details of how the page performed the
state change. Consider the case where you have a button which causes a state change you need to log. What happens if you change that button to be a
LinkButton? If your logging mechanism needs to be concerned with the
implementation details of your page, you will have to change it.

Instead, have the code which performs the state change log the state change. That way, it won't matter _how_ the state change is made, you'll log it just the same. You might even want to centralize this in a class, so that you can confirm that each state change is valid before you make it.
--
John Saunders
johnwsaundersiii at hotmail

[bruce barker]

the approach I use is a custom log filter, which looks at custom headers
your app adds for instrumentation.
-- bruce (sqlwork.com)

"Peter Jaffe" <pj****@nevo.com> wrote in message
news:5c**************************@posting.google.c om...

I've seen a few posts on this topic, but still haven't found a clean
solution. Anyone have other suggestions or feel that one of the
options I highlight below is the way to go?

The Problem
-----------
A sequence of user interactions span multiple ASP.NET http POST
PostBacks within the same page. There is a need to be able to
identify each step of the interaction at the web server level (using a
log analyzer such as WebTrends). However, the requested resource,
query string, and cookies are the only things accessible and the true
differentiation is in the form post data.
Possible Solutions
------------------
I have considered the following options, but #2 seems like the only
"complete" solution, yet it still doesn't feel right...

1) Alter the ASP.NET framework's __doPostBack JavaScript method to
add the eventTarget to the query string of the form's action.
- This won't cover Buttons or ImageButtons since they don't use
__doPostBack
- It can result in cryptic page identifiers (e.g.
ucInquiryResult$grdList$_ctl5$_ctl0)
+ Implementation Options:
* A Response filter - quick POC provided feasible, but what is the
performance cost?
* Try to override the function that generates the __doPostBack
function, but it appears to be in the private method
System.Web.UI.Page.RenderPostBackScript(), so I don't think this is a
viable option.

2) Create custom WebControls that inherit from Button, ImageButton,
LinkButton, etc. These could expose a property whose value is passed
to client side JavaScript as part of the click event. The JavaScript
would rewrite the query string of the form's action attribute.
- Not sure how many controls this would involve. What about
LinkButtons in a ButtonColumn of a DataGrid...?

3) Implement a response filter that recognizes input and anchor
elements and inserts the necessary JavaScript to inject identifiers
into the form action's query string.
+ This is similar to #2, but would be implemented as a central
Response filter rather than having to use multiple custom WebControls.
- However, there is no clear place to specify the desired
"identifier" and therefore results in the same "cryptic identifier"
problem of option #1.
- The string manipulation to generate this additional JavaScript
could be messy and error prone.

4) Could do one-off logic on each relevant control that triggers a
PostBack.
- Hard to maintain. Requires a full sweep of the app and ongoing
diligence, or else the choice to respond to requests from those who
want to collect statistics. The later would have an annoying lag in
getting the requested "identifiers" into production.

5) Implement a page name mapping layer in an HttpModule so a set of
URLs (one for each "identifier") can be used to target the same page.
- This can help for recognizing multiple different entry points, but
the subsequent PostBack requests will be indistinguishable from the
previous without employing another strategy for altering the action of
the HTML form element.

6) Instrument from inside the application. Need to figure out how
this would be published so it can be consumed by the appropriate
people/tools.
Thanks for your time,

Pete

[John Saunders]

"Peter Jaffe" <pj****@nevo.com> wrote in message
news:eQ**************@TK2MSFTNGP11.phx.gbl...

Hi John,

Thanks for the quick and insightful reply. I completely agree that #6 is
the more pure architectural choice. However, the other aspect of the
problem I am facing is that my client already has WebTrends in place for
website usage analysis, and a rewrite of the app from ASP to ASP.NET has
resulted in reduced information being available through WebTrends reports.
I was hoping to be able to find some reasonably elegant compromise that
would at least uniquely tag each "view" thereby restoring their ability to
get useful info out of WebTrends (even if it involved changing the WebTrends reports a little as UI controls are changed).

I may have to just start fighting the battle of either hooking into a
WebTrends API (I still have to look into this) or else encouraging the
client to use different reporting tools to get the statistics they used to
consume from WebTrends.

Peter, how was this accomplished with ASP?
--
John Saunders
johnwsaundersiii at hotmail