Tracking Customers with Application Variables

Like Session variables, Application variables can be used to store information over multiple pages. Unlike Session variables, however, Application variables aren't associated with a particular user. The values stored in an Application variable can be assigned and retrieved by every user of your Web site.

To create an Application variable, you use the Application object. For example, to create an Application variable named "myVar", you would use the following statement:

Application( "myVar" ) = "Hello World"

To retrieve an Application variable, you also use the Application object. The following statement displays the contents of the Application variable named "myVar":

Response.Write Application( "myVar" )

When the value of an Application variable is changed, it is changed for every user of your Web site. For example, imagine that Ruth retrieves a page from your Web site which assigns the value blue to the Application variable named favoriteColor. Now, suppose that Andrew comes along and retrieves a page that assigns the value red to the Application variable favoriteColor. After Andrew changes the value of the favoriteColor Application variable, the value of this variable will be changed for everyone. After Andrew retrieves the page, the favorite- Color variable also has the value red for Ruth.

Because the same Application variable can be changed by different users of your Web site, conflicts can occur. For example, a common use of Application variables is for tracking the number of times a page has been viewed. The ASP code display simple page counter

<%

 Application( "counter" ) = Application( "counter" ) + 1

%>

 This page has been viewed

<%=Application( "counter" )%> times.

There is an important problem with the ASP code above. Imagine that two people request the page at the same time. Ruth requests the page and the counter Application variable has the value 345. At the same time, Andrew requests the page, and the application variable has the value 345. After both visitors retrieve the page, the Application variable will have the value 346. However, because two people have requested the page, it should have the value 347. Fortunately, there is an easy way to fix this problem. The Application object has two methods named Lock and Unlock. The Lock method locks all the Application variables and prevents anyone except the current user from reading or modifying them. The Unlock method releases the

Application variables once again.

  

<%

 Application.Lock

 Application( "counter" ) = Application( "counter" ) + 1

 Application.Unlock

 %>

This page has been viewed

<%=Application( "counter" )%> times.

The ASP above is the same as the ASP code we have earlier except that both the Lock and Unlock methods of the Application object are called. The Lock method is called in line 2. This prevents anyone else from reading or modifying the counter Application variable. After the Application variable has been modified in line 3, the Unlock method is called in line 4 to release the Application variables.

It is important to understand that calling the Lock method locks all the Application variables in memory. You cannot selectively lock Application variables.

After you call the Lock method, all Application variables will continue to be locked until either the Unlock method is called or the page finishes processing. This means that you cannot accidentally lock all Application variables forever within an ASP script.

You should also be aware that locking Application variables doesn't prevent other users from modifying an Application variable. If a number of users attempt to modify an Application variable at the same time, and each user requests a page that calls the Lock method, all the modifications will happen. However, the modifications will take place serially rather than concurrently.

Storing Arrays in Application Variables

One common use of Application variables is to store frequently accessed but infrequently modified database records in memory. Retrieving database records can be a slow process. If the records do not change often, I recommend that you retrieve the database records only once and store them in an Application array. This way, the records can be retrieved very quickly from the Application array the next time they are requested.

The script below demonstrates how you can assign an array to an Application variable named myArray.

<%

 DIM myArray( 10 )

 myArray( 0 ) = "Hello World!"

 Application( "myArray" ) = myArray

 %>

Although you can directly read the value of an element contained in an Application array, you can't modify it. For example, the following statement will have no effect:

Application( "myArray" )(2) = "Goodbye!"

If you want to change the value of an element in an Application array, you must first assign the Application array to a local array. For example, the script in below properly changes the value of an element contained in an Application array.

Modifying an Element in an Application Array

<%

   Application.Lock

   myArray = Application( "myArray" )

   myArray( 0 ) = "Goodbye!"

   Application( "myArray" ) = myArray

   Application( "myArray" ).Unlock

%>

The script above modifies an element of an Application array. In line 3, the Application array named myArray is assigned to a local array with the same name. Next, in line 4, an element of the local array is modified. Finally, in line 5, the local array is assigned to the Application array once again.

Removing Application Variables from Memory You should be careful when creating Application variables. Application variables take up memory. Unlike a Session variable, an Application variable is never automatically removed from memory.

Prior to the version of Active Server Pages included with Windows 2000, there was no way to remove an Application variable from memory using an ASP script. Application variables remained in memory until the Web service was stopped, the Global.asa file was modified, or your ASP Application was unloaded.

The new version of Active Server Pages included with Windows 2000 includes two new methods you can use to remove Application variables from memory: the Remove() and the RemoveAll() methods. The Remove() method removes a particular Application variable from memory. The RemoveAll() method removes all Application variables from memory.

For example, the script below creates two Application variables and then removes one of them.

Using the Remove() Method

<%

 Application( "myvar1" ) = "Red"

 Application( "myvar2" ) = "Blue"

 Application.Contents.Remove( "myvar1" )

 %>

In lines 2 and 3, two Application variables are created. In line 4, the Remove() method is used to remove the Application variable created in line 2. To remove all Application variables from memory, you can use the RemoveAll() method. The script below demonstrates how this method can be used.

 <%

 Application( "myvar1" ) = "Red"

 Application( "myvar2" ) = "Blue"

 Application.Contents.RemoveAll()

%>

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.

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

Before developing an eCommerce application I would like to describe how to keep track of users visiting your E-commerce web application Using Application and Session objects. The ability to track customers and personalize content is important because you can use it to increase sales. To take a simple example, you might want to display different advertisements to different customers depending on their interests. If you have recorded the fact that a certain customer likes looking at pages in your Web site related to fishing rods, you can automatically show this customer more advertisements related to fishing rods.

In this article you will discuss

• How to add cookies to customers' browsers so that you can automatically identify customers whenever they return to your Web site.
• How to use Session and Application variables to store persistent information.
• How to use the Global.asa file to detect when customers first arrive at your Web site and when they leave.

Tracking Customers with Cookies

We can use a cookie to store information on a customer’s computer when the customer visits our Web site. We can then use this information to identify the customer once again whenever the customer returns to our Web site. Without cookies, the interaction between Web servers and browsers is stateless. You cannot identify the same user of your Web site as the user moves from page to page. The stateless nature of Web server and browser interaction creates a number of problems for Web site developers. For example, imagine you have created a special area of your Web site that contains content, which only registered members can view. Without using cookies, it is difficult to track whether a particular user is a registered member. If the user logs in on one page, it is difficult to detect whether it is the same user on another page.

Types of cookies

There are two types of cookies:

Session cookies: Session cookies are stored in memory. They last on a customer's computer only while the customer is visiting your Web site.

Persistent Cookies: A persistent cookie, on the other hand, can last many months or even years. Persistent cookies are stored in a text file on the customer's computer. This text file is called the Cookie file on Windows computers and the Magic Cookie file on Macintosh computers.

You should never assume that a customer has cookies enabled on their browser. For example, a perfectly legitimate use of cookies is to automatically log in a user at your Web site. If you do this, however, you should include a way for users who do not have cookies enabled to log in.

Adding a Cookie to a Customer's Browser

You can add a cookie to a customer's browser by using the Cookies collection of the Response object. For example, imagine that you want to add a cookie named customer Name that contains a customer name. To add this cookie, you would use the following statement:

Response.Cookies( "customerName" ) = "Binay Tiwari"

This statement adds a cookie named "customerName"  that has the value "Binay Tiwari". The cookie that is created is a session cookie. It last only while the customer is visiting your Web site.

To create a persistent cookie, you must include the date when the cookie will expire. You do this by using the Expires attribute of the Cookies collection. For example, the following two statements create a cookie that will last until July 4, 2012:

 Response.Cookies( "customerName" ) = "Binay  Tiwari"

 Response.Cookies( "customerName" ).Expires =  "July 4, 2012"

When creating cookies, you must create the cookie before any  content is sent to the browser. Otherwise you will receive the following error:

Header Error

 “The HTTP headers are already written to the client browser.  Any HTTP header modifications must be made before writing page content.”

If you want to get around this limitation, you can buffer your ASP page. When you buffer an ASP page, the page is not sent immediately to  a browser. It is retained in memory until the whole page is processed. To buffer an ASP page, include the following statement at the top of the page:

<% Response.Buffer = TRUE %>

According to the original cookie specification a single computer can hold a maximum of 300 cookies from all Web sites. Furthermore, a single Web site cannot add more than 20 cookies to a customer's computer.  Finally, an individual cookie can hold no more than 4KB of data. This limit applies to a combination of the size of the cookie's name and the size of the data contained in the cookie.

Reading Cookies from a Customer's Browser

You can read a cookie you have placed on a customer’s computer by using the Cookies collection of the Request object. For example, to retrieve a cookie named username and assign it to a local variable named username, you would use the following statement:

username = Request.Cookies( "username" )

You can display all the cookies that have been added by your Web site by iterating through the contents of the Cookies collection.

  <HTML><HEAD><TITLE>All  Cookies</TITLE></HEAD>

  <BODY>

   <

   FOR EACH cookie IN  Request.Cookies

   Response.Write  cookie& "=" &Request.Cookies( cookie )&  "<BR>"

   NEXT

  %>

  </BODY>

  </HTML>

WHAT ABOUT THE LIMITATIONS OF E-COMMERCE

Isaac Newton’s 3rd Law of Motion, ‘For every action there is an equal and opposite reaction’ suggests that for all the benefits there are limitations to e-commerce. These again will be dealt with according to the three major stakeholders – organizations, consumers and society

Limitations of e-commerce to organizations

Rapidly evolving and changing technology, so there is always a feeling of trying to ‘catch up’ and not be left behind.

Under pressure to innovate and develop business models to exploit the new opportunities which sometimes leads to strategies detrimental to the Organization. The ease with which business models can be copied and emulated over the Internet increase that pressure and curtail longer-term Competitive advantage.

Limitations of e-commerce to consumers

Computing equipment is needed for individuals to participate in the new ‘digital’ economy, which means an initial capital cost to customers.

A basic technical knowledge is required of both computing equipment and navigation of the Internet and the World Wide Web

Lack of security and privacy of personal data. There is no real control of data that is collected over the Web or Internet. Data protection laws are not universal and so websites hosted in different countries may or may not have laws, which protect privacy of personal data.

Electronic processes replace physical contact and relationships. Customers are unable to touch and feel goods being sold on-line or gauge Voices and reactions of human beings

Limitations of e-commerce to society

Breakdown in human interaction. As people become more used to interacting Electronically there could be an erosion of personal and social skills, which Introduction to e-commerce 15 might eventually be detrimental to the world we live in where people are more comfortable interacting with a screen than face to face.

WHAT ARE THE BENEFITS OF E-COMMERCE?

The previous sections have included discussions about what e-commerce is and its impact, but what are the benefits of e-commerce? What does it offer and why do it? The benefits of e-commerce can be seen to affect three major stakeholders: organizations, consumers and society.

Benefits of e-commerce to organizations

International marketplace. What used to be a single physical marketplace located in a geographical area has now become a borderless marketplace including national and international markets. By becoming e-commerce enabled, businesses now have access to people all around the world. In effect all e-commerce businesses have become virtual multinational corporations

Operational cost savings. The cost of creating, processing, distributing, storing and retrieving paper-based information has decreased (see Intel mini-case).

Mass customization. E-commerce has revolutionized the way consumers buy good and services. The pull-type processing allows for products and services to be customized to the customer’s requirements. In the past when Ford first started making motor cars, customers could have any colors so long as it was black. Now customers can configure a car according to their specifications within minutes on-line via the www.ford.com website.

Lower telecommunications cost. The Internet is much cheaper than value added networks (VANs) which were based on leasing telephone lines for the sole use of the organisation and its authorised partners. It is also cheaper to send a fax or e-mail via the Internet than direct dialling.

No more 24-hour-time constraints. Businesses can be contacted by or contact customers or suppliers at any time.

Benefits of e-commerce to consumer

24/7 access. Enables customers to shop or conduct other transactions 24 hours a day, all year round from almost any location. For example, checking balances, making payments, obtaining travel and other information. In one case a pop star set up web cameras in every room in his house, so that he could check the status of his home by logging onto the Internet when he was away from home on tour

More choices. Customers not only have a whole range of products that they can choose from and customize, but also an international selection of supplier

Price comparisons. Customers can ‘shop’ around the world and conduct comparisons either directly by visiting different sites, or by visiting a single site where prices are aggregated from a number of providers and compared

Benefits of e-commerce to society

Enables more flexible working practices, which enhances the quality of life for a whole host of people in society, enabling them to work from home. Not only is this more convenient and provides happier and less stressful working environments, it so potentially reduces environmental pollution as fewer people have to travel to work regularly.

Facilitates delivery of public services. For example, health services available over the Internet (on-line consultation with doctors or nurses), filing taxes over the Internet through the Inland Revenue website