Monday, December 19, 2011

Tracking customer with cookies/ Session and Application/ Global.asa in E-commerce applications (2/3)




Tracking Customers with Session Variables

You can use Session variables as another method of tracking customer information as a customer moves from page to page on your Web site. Session variables are closely related to cookies. In fact, Session variables rely on cookies.

The Webserver automatically adds a special cookie to every visitor's browser. This cookie is called the ASPSessionID cookie (when it's added to a customer's computer, extra randomly generated characters are added to the name of the cookie for security reasons).

The Web server uses the ASPSessionID cookie to associate Session variables with a particular user.  Session variables are stored in the memory of the Web server. You can use a Session variable to store any type of information including text, numbers, arrays and even ActiveX components.

Before you use Session variables, however, you should be warned that they have some of the same drawbacks as cookies. If a customer is using a browser that doesn't support cookies, the Web server cannot create the ASPSessionID cookie. Without the ASPSessionID cookie, Session variables cannot be associated with a customer as the customer moves between pages. So, it is a good idea to avoid using Session variables whenever possible:

 Using Session variables in your ASP application can also make your application less scalable. Each Session variable uses server memory. Furthermore, using Session variables makes it more difficult to use multiple Web servers for a Web site (a Web farm) because Session variables are created on an individual server.

 <HTML>
  <HEAD><BODY><TITLE>Session  Variable</TITLE></HEAD>
  <BODY>
 <% Session(  "favoriteColor" ) = "blue" %>
  </BODY>
  </HTML>

The Session variable is created in above code. You should notice immediately that, unlike a cookie, a Session variable can be created anywhere within an ASP page. Unlike a cookie, you aren’t required to create Session variables before any content is sent to the browser. After the favoriteColor Session variable has been created and assigned a value, it will retain that value throughout the time that a user visits your Web site. The favoriteColor Session variable will be associated with a particular user by using the ASPSessionID cookie.

 Below code is use for displaying a Session Variable

 <HTML>
  <HEAD><BODY><TITLE>Session  Variable</TITLE></HEAD>
  <BODY>
   Your favorite color is <%=Session(  "favoriteColor" )%>
  </BODY>
  </HTML>

It is important to understand that Session variables are created relative to particular users. For example, assume that Ruth visits your Web site and retrieves a page, which assigns the value blue to the Session variable named favoriteColor. Now assume that Andrew visits your Web site and retrieves a page, which assigns the value red to a Session variable named favoriteColor. After Andrew retrieves his page, the value of favorite Color doesn't change for Ruth. Each visitor has his own unique set of Session variables assigned to him.

Session variables persist until a user leaves your Web site. How does the Web server detect when this happens? By default, the Web server assumes that if a user doesn't request a page for more than 20 minutes, the user has left. You can change this default behavior with the Timeout property of the Session object.

For example, if you have a Web site that includes long product descriptions, which are time-consuming to read, you might want to change the Timeout property to 60 minutes. You can do this by adding the following statement at the top of a page:

 Session.Timeout = 60

You specify the value of the Timeout property in minutes. The new value of Timeout will apply to the user throughout the remainder of her user session.
  
 Storing Arrays in Session Variables

One common use for Session variables is for storing a customer's shopping cart. You can create a shopping cart by assigning an array to the Session variable. The elements in the array represent each of the products a customer has added to his shopping cart. The script in below illustrates how you can create an array, assign values to two of its elements, and then create a Session variable that contains the array.

  <%
 DIM ShoppingCart( 20 )
  ShoppingCart( 0 ) =  "toothpaste"
  ShoppingCart( 1 ) =  "comb"
  Session( "ShoppingCart"  ) = ShoppingCart
 %>

The ShoppingCart array is created in line 2. The array has 20 elements. Next, in lines 3 and 4, two of the array’s elements are assigned a value. Finally, in line 5, the array is assigned to a Session variable named ShoppingCart. After an array has been assigned to a Session variable, you can display any element of the array by referring to its index. For example, the following statement displays the element of the Session array with an index of 1.

 Response.Write Session(  "ShoppingCart" )( 1 )

 If the Session array were created with the script in Listing 3.4, the previous statement would display the value "comb".

However, you cannot change the value of an element in a Session array directly. To change any of the values in a Session array, you must first assign the Session array to a normal VBScript array, make the change, and then assign the array to the Session variable once again. For example, the script in Listing 3.5 demonstrates how to change the value of the second element of the ShoppingCart Session array from comb to toothbrush.

 Changing the Value of a Session Array

 <%
   ShoppingCart = Session(  "ShoppingCart" )
   ShoppingCart( 1 ) = "toothbrush"
   Session( "ShoppingCart" ) =  ShoppingCart
   %>

You might be tempted to try to change the value of a Session array directly. For example, you might try to use the following statement:

 Session ( "ShoppingCart"  )( 1 ) = "toothbrush"

This statement won't generate an error. However, it will have absolutely no effect. You cannot change a value of a Session array directly.

 Tracking a Session with a SessionID

The Session object has a valuable property for uniquely identifying users: the SessionID property. Each visitor to your Web site is automatically assigned a unique number. You can retrieve that unique number with the SessionID property.

For example, the below ASP code displays the value of SessionID for the person who requests the page.

 Displaying the SessionID Property

 <HTML>
  <HEAD><BODY><TITLE>Session  ID</TITLE></HEAD>
  <BODY>
  Your unique Session ID is  <%=Session.SessionID%>
  </BODY>
  </HTML>

 A SessionID is guaranteed to be unique for each user who is currently at your Web site. However, the same SessionID might be used again after your Web server has been restarted. This means that you shouldn't attempt to track the same user over time by using her SessionID.

Ending a User Session

By default, a user session ends after the user hasn't requested a page from your Web site for more than 20 minutes. However, you can force a session to end earlier than this by calling the Abandon method of the Session object. Calling the Abandon method removes all the Session variables associated with the user who requested the page from memory.

After you call the Abandon method, the user's session doesn't actually end until the current page is completely processed. This means that all the user's Session variables retain their values until the page finishes processing. Furthermore, the user's SessionID retains its value throughout the page

For example, consider the code below.

 <HTML>
  <HEAD><TITLE>Session  Abandon</TITLE></HEAD>
  <BODY>
 <%
   Session( "myVar" ) = "Hello  World!"
  %>
  <p>The value of myVar is:  <%=Session( "myVar" )%>
   <%
  Session.Abandon
  %>
  <p>The value of myVar is:  <%=Session( "myVar" )%>
 </BODY>
  </HTML>
  
The Abandon method is most often used when creating a Logoff page in a Web site. For example, you can store a customer’s username and password in Session variables to identify the customer on every page. When the customer is ready to leave your Web site, she can link to a page that calls the Abandon method to end her user session and remove her username and password from memory.

No comments:

Post a Comment