1. Technical Field
The present invention relates in general to a system and method for replaying a session without recreating the session. More particularly, the present invention relates to a system and method that records data relating to an HTTP session with a web server, and then replays the HTTP session without recreating the actual session.
2. Description of the Related Art
More and more companies, both large and small, are developing web applications that allow their customers and clients to perform on-line operations and business transactions. For example, most banks allow their customers to view their accounts, transfer money, update their address, order checks, and perform many other banking transactions over the Internet. Financial management companies typically provide web applications that allow their clients to manage their portfolios, trade stocks, and update personal information, such as their address, using the web application.
Unfortunately, corporate web applications are not fool-proof. Occasionally, a customer or a client has a problem using the web application. Sometimes the problem is an operational problem with the web application, such as poor performance, a system crash, a network outage, or depletion of buffer pools, storage, or CPU threshold. Other times, the problem is a logical problem, such as poor web application logic, broken or missing links, client error, returned pages with cryptic error messages, blank web pages, or partially rendered web pages. Logical problems such as these are difficult to detect using traditional application, resource manager, and operational monitoring solutions. Therefore, logical problems often result in the customer making a call to the company's help desk for assistance in resolving the problem.
Help desk professionals typically resolve computer application problems by talking to a customer on the telephone (or sometimes via an on-line chat session), and attempting to walk the customer through the problem. The difficulty with this technique is that the help desk professional can not physically see the customer's computer monitor, and therefore must interpret what the customer is saying in an effort to determine the interaction between the customer and the corporate web application, and the resulting display. This type of problem determination is time consuming and error-prone, as it is often difficult for the help desk professional to interpret the customer's rendition of the problem. Sometimes a help desk professional will attempt to recreate the customer's problem, however, it is not always possible to make the same error occur again. In addition, it is not always desirable to recreate an error. For example, if the customer was attempting to transfer money from one account to another account when the error occured, the help desk professional may inadvertently transfer the sum of money several times in an attempt to recreate the error.
Furthermore, help desks are one of the more expensive dealings that a company has with customers, and many companies attempt to avoid having customers deal with help desk professionals. Companies use voice automation systems and on-line knowledge bases to avoid assigning a help desk professional to a customer problem. In those cases where a help desk professional is needed, companies attempt to limit the amount of time that the help desk professional must actually spend working directly with the customer.
What is needed, therefore, is a system and method that reduces the cost of help desk operations by minimizing the amount of time that a help desk professional must spend with a customer when analyzing and attempting to solve the customer's problem.
It has been discovered that the aforementioned challenges are resolved using a method for replaying sessions. The method obtains stored page metadata corresponding to a previous client session. One or more of the inputs referenced in the stored page metadata is disabled, resulting in a first replay representation. The method further retrieves one or more stored client transactions corresponding to the stored page metadata. The method modifies the first replay representation based upon the stored client transactions, resulting in a second replay representation. The first and second replay representations are rendered, using a browser.
In another embodiment, the aforementioned challenges are resolved using an information handling system capable of executing the method described above. In yet another embodiment, the aforementioned challenges are resolved using a computer program product stored in a computer operable media, and containing instructions which, when executed by computer, cause the computer to execute the method described above.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention, which is defined in the claims following the description.
The present invention is a method, system, and computer program product that records page metadata regarding a session and then uses the metadata to replay the session without recreating it. A help desk professional sees an almost mirror image of a customer's computer monitor from a window on the help desk's own monitor. This allows the help desk to see what happened on the customer's screen when an error occurred. Thus, the help desk does not have to interpret the customer's description of the problem, but rather, can replay the interaction between the customer and the web application. The help desk is able to observe the problem, and can even “rewind” and observe the problem over again if necessary to resolve the problem.
Replaying, rather than recreating, a problem has several advantages. Some problems are difficult to recreate, and so being able to replay the problem allows a help desk professional to observe what happened, even if the help desk professional is unable to make the problem reoccur. Also, in some cases it is not desirable to recreate the problem, as this may have unintended consequences, such as causing transactions to occur numerous times while trying to duplicate the error. By replaying the session, the help desk can see what happened without having to recreate the problem.
Recording metadata in order to replay a session has many uses, and is not limited to the help desk field. For example, a software developer may replay a testing session to observe errors that occurred while testing. In a testing situation, it is often very difficult to recreate an error, as many errors are caused by timing problems that are difficult to recreate. However, by replaying a testing session, a developer is able to observe an error, many times if necessary, in an attempt to discover what went wrong.
As used herein, the term “client” is used to denote the entity that is interacting with an application, such as a corporate web application. Those skilled in the art will understand that a client includes, but is not limited to, a user, a customer, an employee, a computing device, such as a computer system or a client computer, or a pervasive device, such as a personal digital assistant (PDA) or web-enabled mobile phone.
The packet collector program analyzes the packets that are collected by the packet sniffer (step 220). A packet is received (step 230) and a determination is made regarding whether the received packet is a packet of interest (decision 240). As discussed above, the packet collector program may be interested in all HTML and HTTP GET, PUT, and POST packets, or only those that pertain to a particular user or setting. If it is determined that the packet is not a packet of interest, decision 240 branches to “no” branch 255, whereupon processing continues at decision 260. If, however, it is determined that the packet is a packet of interest, then decision 240 branches to “yes” branch 245, whereupon the packet and its user identifier information is stored in session data 170 (step 250). A decision is made regarding whether to continue collecting packets (decision 260). If it is determined to continue collecting packets, decision 260 branches to “yes” branch 265, whereupon processing continues at step 230. If, however, the packet collector program has collected sufficient packets, or has been stopped, decision 260 branches to “no” branch 270, whereupon processing ends at 295.
The packet data stored in session data 170 is preferably referred to as “page metadata.” This is because session data 170 does not include every packet or every transaction between users 110 and 120 and web server 150. Rather, only selected packets are collected and stored. The selected packets, in this example HTML packets, and HTTP GET, PUT, and POST packets, are the packets necessary to reconstruct and replay a session. A significant amount of storage space is saved by only collecting and storing selected packets, rather than recording everything that passes between users 110 and 120 and web server 150. In particular, many embedded graphic objects are not stored in session data 170, which saves much storage space, as graphics objects typically consume large amounts of storage. As described below in
The page metadata that is stored in session data store 170 can include various user identification data. For example, each HTML and HTTP GET, PUT, and POST packet may be stored, along with a TCP/IP address, instance level, userID, and session number. The user identification data that is stored will depend on the application being monitored. Some applications will have userIDs associated with them, while other applications will have instance levels in addition to, or instead of, UserIDs.
An example showing the type of data that can be stored as page metadata is depicted in session data 170. In this exemplary embodiment, the Anchor is a pointer that points to, or anchors, the data that has been stored. Typically, the Anchor is a memory address that is stored in a known location. Each individual session is identified by a TCP/IP network address. Thus, in the list depicted in session data 170, there are two main entries, each denoted by a TCP/IP address. There are two instances of a recording shown for the second TCP/IP address. For example, one may have been recorded yesterday and one may have been recorded today. Instance #2 has more than one UserID associated with it, possibly because more than one user is reusing the same TCP/IP address (for example, this may occur when using a proxy server, such as proxy server 130, depicted in
Returning to decision 330, if the selected session is the session of interest, decision 330 branches to “yes” branch 365, whereupon the session retrieval program locates the first HTML page for the selected session (referred to as the starting page) (step 370). The HTML page is then replayed (predefined process 380), as depicted in
Processing begins at 400, whereupon HTML page 410 is retrieved from session data 170 (step 405). Processing modifies the HTML to disable input to the web page (step 415). This may be done, for example, by adding an HTML tag to the page that makes it a read-only page. Disabling input to the web page is a security precaution that prevents anyone who is replaying the web page from actually interacting with it. Next, a determination is made as to whether to display any embedded objects referenced in the web page (decision 420). Embedded objects are typically graphics objects. The help desk professional, or other professional who is replaying the session, may decide to display all embedded objects, just some embedded objects, or no embedded objects. It may be that the embedded objects are not needed to resolve a problem, and for efficiency reasons, it may be quicker to only display some of the objects, or perhaps not to display any embedded objects. The decision regarding whether or not to display embedded objects may be made by checking a setting or flag that is pre-selected by the help desk professional, or that is selected as an option during the replay process.
If it is determined not to display any embedded objects, decision 420 branches to “no” branch 465, whereupon HTML page 410 is modified to remove all embedded object references (step 470). Processing then continues at step 480. If it is decided to display some, or all, of the embedded objects, then decision 420 branches to “yes” branch 425, whereupon a further decision is made regarding whether to display embedded objects from select sites only (decision 430). For example, it may be efficient to only display embedded objects that are found on local web sites. Alternately, the help desk professional may determine a list of select sites from which embedded objects should be displayed in order to better analyze the current problem. If it is determined to display all embedded objects, rather than just those from select sites, decision 430 branches to “no” branch 445, whereupon processing continues at step 480. If, however, it is determined to only display objects from selected sites, decision 430 branches to “yes” branch 435, whereupon a list of select sites 450 is read (step 440). For example, list 450 may contain a list of sites from which to retrieve embedded objects. Alternately, list 450 may indicate that only “local” objects, i.e. those objects found on local sites, should be retrieved. Processing then modifies HTML page 410 to remove the embedded object references for those embedded objects which are not from selected sites (step 460).
The resulting HTML page, referred to as a first replay representation, is then sent to a browser, typically on the help desk professional's display (step 480). The replay representation is then rendered, i.e. replayed, by the browser, without actually recreating the session. The browser replays the page without recreating, or rerunning, the session with the corporate web application. Processing then continues by traversing the session (predefined process 490) as shown in
If the next session data is not an HTML page, then this means the next session data must be an HTTP GET, PUT, or POST packet. In this case, decision 550 branches to “no” branch 565, whereupon HTML page 410 is further modified based on the GET, PUT, or POST data (step 570). In a typical interaction between a customer (i.e. client or user) and a web application, the customer interacts with a web page by filling in a form and/or checking display boxes. These are reflected in the HTTP GET, PUT, and POST protocols. As depicted in step 570, in order to replay the image that the customer saw, the HTTP GET, PUT, and POST packets stored in session data 170 are used. The information found in the HTTP GET, PUT, and/or POST packets is inserted into the modified HTML page (i.e. the HTML that has already been modified and rendered as shown in
The further modified HTML page, referred to as a second replay representation, is then rendered using a browser (step 580). Processing then loops back to process the next request (step 590). It is important to note that the HTTP GET, PUT, and POST packets are never sent from the browser to the actual web server application. If the HTTP GET, PUT, and/or POST packets were sent to the web server application, then this may duplicate the functions that the customer had already done. By recording and replaying the interactions between the customer and the web server application, without actually recreating the interactions, the help desk professional can see what happened without interacting with the web server application and potentially duplicating customer transactions.
The help desk professional then selects a “next” option, by selecting a button (not shown) on his or her display screen. The HTTP packets from session data 170 are then used, as described above with reference to
The help desk professional continues to traverse the session, and, in this example, a third replay representation is shown in the bottom depiction of
PCI bus 714 provides an interface for a variety of devices that are shared by host processor(s) 700 and Service Processor 716 including, for example, flash memory 718. PCI-to-ISA bridge 735 provides bus control to handle transfers between PCI bus 714 and ISA bus 740, universal serial bus (USB) functionality 745, power management functionality 755, and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support. Nonvolatile RAM 720 is attached to ISA Bus 740. Service Processor 716 includes JTAG and I2C busses 722 for communication with processor(s) 700 during initialization steps. JTAG/I2C busses 722 are also coupled to L2 cache 704, Host-to-PCI bridge 706, and main memory 708 providing a communications path between the processor, the Service Processor, the L2 cache, the Host-to-PCI bridge, and the main memory. Service Processor 716 also has access to system power resources for powering down information handling device 701.
Peripheral devices and input/output (I/O) devices can be attached to various interfaces (e.g., parallel interface 762, serial interface 764, keyboard interface 768, and mouse interface 770 coupled to ISA bus 740. Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus 740.
In order to attach computer system 701 to another computer system to copy files over a network, LAN card 730 is coupled to PCI bus 710. Similarly, to connect computer system 701 to an ISP to connect to the Internet using a telephone line connection, modem 775 is connected to serial port 764 and PCI-to-ISA Bridge 735.
While the computer system described in
While the information handling system described in
One of the preferred implementations of the invention is an application, namely, a set of instructions (program code) or other functional descriptive material in a code module that may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps. Functional descriptive material is information that imparts functionality to a machine. Functional descriptive material includes, but is not limited to, computer programs, instructions, rules, facts, definitions of computable functions, objects, and data structures.
While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, that changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.