REGISTER  |  SIGN IN
United States Patent6701514
Haswell , ; et al.March 2, 2004
Title
System, method, and article of manufacture for test maintenance in an automated scripting framework
Abstract
A system, method and article of manufacture are provided for affording test maintenance in an automated scripting framework. First, a plurality of test scripts are developed. Then, the plurality of test scripts are stored in a centrally located database. A user is then allowed to edit a specific test script located on the centrally located database. Finally, the user edits to the specific test script are propagated to each of the plurality of test scripts.
Inventors:Haswell; John Jeffrey (Herndon, VA), Young; Robert J.  (Charlestown, MA), Schramm; Kevin  (Rose Valley, PA)
Assignee:Accenture LLP (Palo Alto, CA)
Appl. No.:536264
Filed:March 27, 2000
Current U.S. Class:717/115 717/124 707/102 
Field of Search:717/124,126,127,128,140,149,115 707/102
U.S. Patent Documents
5119307June 1992Blaha et al.
5627886May 1997Bowman
5754760May 1998Warfield
5781720July 1998Parker et al.
5805891September 1998Bizuneh et al.
5870719February 1999Maritzen et al.
5905856May 1999Ottensooser
5954829September 1999McLain, Jr. et al.
5960196September 1999Carrier, III et al.
5983001November 1999Boughner et al.
6002869December 1999Hinckley
6002871December 1999Duggan et al.
6006230December 1999Ludwig et al.
6014760January 2000Silva et al.
6031990February 2000Sivakumar et al.
6058492May 2000Sample et al.
6064381May 2000Harel
6067639May 2000Rodrigues et al.
6069873May 2000Pugaczewski et al.
6094531July 2000Allison et al.
6175845January 2001Smith et al.
6189116February 2001Mongan et al.
6249882June 2001Testardi
6259911July 2001Bims et al.
6272673August 2001Dale et al.
6385594May 2002Lebda et al.
6405364June 2002Bowman-Amuah
6408335June 2002Schwaller et al.
6408403June 2002Rodrigues et al.
6421793July 2002Lester et al.
6424978July 2002Liu et al.
6442748August 2002Bowman-Amuah
6480469November 2002Moore et al.
6502102December 2002Haswell et al.
Other References
Test Director (TM) 5: Integrated Test Management:; 1998 Mercury Interactive Corporation; p. 1-4. .
Press Release, "Mt. Arlington, New Jersey, USA--Mar. 15, 1999"; p. 1-2. .
Kasik et al., "Toward Automatic Generation of Novice User Test Scripts", ACM Press, 1996, p. 244-251. .
Chays et al., "A Framework for Testing Database Applications", ACM, 2000, pp. 147-157. .
Balcer et al.; Automatic Generation of Test Scripts from Formal Test Specifications:; ACM Press, IEEE-CS, SIGSOFT; 1989, pp. 210-218. .
Memon et al., "Coverage Criteria for GUI Testing", ACM, 2001, pp. 256-267. .
"LoadRunner (R) 6: The Enterprise Load Testing Tool"; 1999 Mercury Interactive Corporation. .
Banick et al.: "Web Management with Microsoft Visual SourceSafe 5.0"; Que Corporation; 1997. .
Nolan, C; " A look at e-Test Suite 3.1 by RSW"; Internet Citation, Jul. 1999, XP002155308..~
Primary Examiner: Nguyen-Ba; Antony
Attorney, Agent or Firm:Oppenheimer Wolff & Donnelly LLP
Claims

What is claimed is:
1. A method for providing test maintenance in an automated scripting framework comprising the steps of: (a) developing a plurality of test scripts; (b) storing the plurality of test scripts in a centrally located database; (c) allowing a user to edit a specific test script located on the centrally located database; and (d) propagating user edits to the specific test script to each of the plurality of test scripts.

2. A method as recited in claim 1, wherein the user edits to the specific test script are propagated to each of the plurality of test scripts simultaneously.

3. A method as recited in claim 1, wherein the plurality of test scripts are utilized to develop test scenarios.

4. A method as recited in claim 3, wherein the test scenarios are developed using an English-based interface.

5. A method as recited in claim 4, wherein the interface is accessed utilizing a network.

6. A method as recited in claim 1, wherein the framework utilizes a two-tier architecture.

7. A computer program embodied on a computer readable medium for providing test maintenance in an automated scripting framework comprising: (a) a code segment for developing a plurality of test scripts; (b) a code segment for storing the plurality of test scripts in a centrally located database; (c) a code segment for allowing a user to edit a specific test script located on the centrally located database; and (d) a code segment for propagating user edits to the specific test script to each of the plurality of test scripts.

8. A computer program as recited in claim 7, wherein the user edits to the specific test script are propagated to each of the plurality of test scripts simultaneously.

9. A computer program as recited in claim 7, wherein the plurality of test scripts are utilized to develop test scenarios.

10. A computer program as recited in claim 9, wherein the test scenarios are developed using an English-based interface.

11. A computer program as recited in claim 10, wherein the interface is accessed utilizing a network.

12. A computer program as recited in claim 7, wherein the framework utilizes a two-tier architecture.

13. A system for providing test maintenance in an automated scripting framework comprising: (a) logic for developing a plurality of test scripts; (b) logic for storing the plurality of test scripts in a centrally located database; (c) logic for allowing a user to edit a specific test script located on the centrally located database; and (d) logic for propagating user edits to the specific test script to each of the plurality of test scripts.

14. A system as recited in claim 13, wherein the user edits to the specific test script are propagated to each of the plurality of test scripts simultaneously.

15. A system as recited in claim 13, wherein the plurality of test scripts are utilized to develop test scenarios.

16. A system as recited in claim 15, wherein the test scenarios are developed using an English-based interface.

17. A system as recited in claim 16, wherein the interface is accessed utilizing a network.

18. A system as recited in claim 13, wherein the framework utilizes a two-tier architecture.
Description
FIELD OF THE INVENTION

The present invention relates to scripting and more particularly to automated scripting solutions.

BACKGROUND OF THE INVENTION

Newly developed software programs must be thoroughly tested in order to eliminate as many "bugs" or errors as possible before the software is released for widespread public use. Accordingly, development of software is largely a trial and error process. Several different methods for testing software programs have been developed. One conventional approach, generally referred to as beta testing, involves distributing the program, typically under a non-disclosure agreement, to a group of users who use the program for a period of time and report any errors which are encountered to the software developer. Although this type of testing is commonly used in the software industry, it is often found to be very time consuming, adversely affecting the scheduled release of products incorporating the software program. In addition, beta testing can be extremely difficult to control, particularly when a large number of users are provided the beta version of the software. Furthermore, due to the non-systematic use of the program, there is no guarantee that every error, or even most errors, will be identified with this approach, even under circumstances where a large number of users are using the software.

As software is developed on and runs on computers, it is not surprising to find that many of the techniques for automating the testing of software have been implemented in digital computers. A common approach for testing software is the use of test suites. Test suites compare "known good" outputs of a program (for a given set of input) against the current output. Tests that check program file output are easy to implement and can be automated with shell scripts (e.g., Expect available on the Internet). For programs with user interfaces that communicate to standard input/output devices (stdin/stdout), a similar method may be employed. Capture/playback tools are available for recording keyboard input and program output as a person tests a program.

Much of the code written today is for software products with a graphical user interface (GUI), such as Microsoft.RTM. Windows.TM.. In fact, much of software development itself is done within a graphical user interface, with software tool vendors providing products which allow software developers to develop GUI software using visual programming techniques. The Quality Assurance (QA) engineer faces more complex problems when testing GUI software. In particular, GUI programs must behave correctly regardless of which video mode or operating environment is being employed.

Intuitively, testing user interfaces should not be as difficult as testing a complex internal engine, such as a compiler or a real-time, multi-user operating system. In practice, however, user interface (UI) testing is the most challenging part of the QA process. This problem stems largely from the difficulty in automating UI tests. Tests for complex engines, in contrast, are often command-line programs whose testing can easily be automated using simple batch execution. Thus despite the plethora of present day tools for automating program testing, the task of developing, maintaining and analyzing the results of UI tests remains an arduous task.

The basic steps traditionally employed to test user interfaces may be summarized as follows. First, the application being tested is controlled by placing it into a specific state using either pre-recorded keyboard or mouse device actions, or entering input through a test script. Next, the then-current state of the application is recorded by taking a screenshot (e.g., capturing a screen bitmap). Finally, the captured screenshot is compared with a baseline screenshot that is known to be valid.

The approach is far from ideal, however. Consider, for instance, the determination of whether the state of a check box is valid within a specific dialog box. Here, the QA engineer must take a screenshot of that check box and compare it with the expected image. Thus, testing of even the simplest component is laborious. Moreover, the approach itself is prone to error. A change of just a few pixels across all windows--a common occurrence in GUI software development--causes all tests to fail. Consequently, as software becomes more and more complex, it becomes less and less feasible to test user interface tasks with present-day screen comparison methodology.

The software testing phase is a critical phase in the software development process. During the software development process, the software testing phase occurs after the software has been designed, implemented in a programming language, and tested to a limited degree. During the testing phase, software testers test the software extensively to ensure that the software meets all of the requirements it is intended to meet. In order to accommodate simultaneous testing of several different software packages by several testers, multiple test machines are often implemented. Different types of software packages may need to be tested on different types of test machines, such as, for example, test machines with different hardware configurations and/or different operating systems. When a large number of software testers are required to share common resources for software testing, provisions must be made for scheduling the tests in order to efficiently manage these shared resources. The efficient management of these shared resources may also require that tests and the results of the tests be recorded so that the tests can be used repeatedly if needed and so that the results of the tests can be analyzed and subsequently used for comparison with the results of tests performed at a later time.

In an effort to maximize efficiency in the handling of test scheduling and test execution, attempts have been made to automate software testing by using a server to manage test machines and to allocate test packages among the test machines in accordance with a schedule. Generally, these types of systems pre-allocate tasks to test machines by calculating the current and scheduled loads on the test machines and scheduling the tasks so that they are performed in a tine-efficient manner. For example, Sun Microsystems, Inc. has proposed an automated task-based scheduler for use with UNIX platform systems which allows users operating "client" machines to schedule tests to be executed on "target" machines. A central server receives a request from a client machine to perform a task. The server maintains information relating to all currently scheduled tasks on all target machines in a "status" database. The server maintains information relating to the expected duration of each test package and other test package attributes in a "packages" database.

When the server receives a request to perform a task from a client machine, the server determines the loads on each of the target machines which are suitable for performing the task. The loads are determined based on the expected duration of each test package. The server then schedules the task on the target machine with the least current load. A task file created at the client machine and copied to the server includes priority information relating to the task requested by the client machine. Once the server has selected a target machine for the task, the task file is copied to the selected target machine. The target machine selects a task to be performed based on this priority information contained in the task file copied to the target machine. Once a task is completed, the results are copied back to the server which compares them to a set of "golden results" and creates a comparison report which is mailed back to the user that requested the test.

SUMMARY OF THE INVENTION

A system, method and article of manufacture are provided for affording test maintenance in an automated scripting framework. First, a plurality of test scripts are developed. Then, the plurality of test scripts are stored in a centrally located database. A user is then allowed to edit a specific test script located on the centrally located database. Finally, the user edits to the specific test script are propagated to each of the plurality of test scripts.

In one aspect of the present invention, the user edits to the specific test script are propagated to each of the plurality of test scripts simultaneously. In another aspect, the plurality of test scripts are utilized to develop test scenarios.

In an embodiment of the present invention, the test scenarios are developed using an English-based interface. In another embodiment, the interface is accessed utilizing a network. In a further embodiment, the framework utilizes a two-tier architecture.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be better understood when consideration is given to the following detailed description thereof. Such description makes reference to the annexed drawings wherein:

FIG. 1 is a flowchart illustrating a method for affording an automated scripting solution for enterprise testing in accordance with one embodiment of the present invention;

FIG. 2 is a schematic diagram illustrating one exemplary system architecture of the present invention, in accordance with one embodiment of the present invention;

FIG. 3 is a representative hardware environment illustrating a hardware configuration of a client computer in accordance with a preferred embodiment;

FIG. 4 is a flowchart illustrating a method for affording a table-driven automated scripting architecture in accordance with one embodiment of the present invention;

FIG. 5 is a flowchart illustrating a method for affording improved accuracy in an automated scripting framework in accordance with one embodiment of the present invention;

FIG. 6 is a flowchart illustrating a method for affording application independence in an automated scripting framework, in accordance with one aspect of the present invention;

FIG. 7 is a flowchart illustrating a method for affording test development in an automated scripting framework, in accordance with an embodiment of the present invention;

FIG. 8 is a flowchart illustrating a method for affording synchronization in an automated scripting framework, in accordance with an aspect of the present invention;

FIG. 9 is a flowchart illustrating a method for affording test maintenance in an automated scripting framework in accordance with an embodiment of the present invention; and

FIG. 10 is a flowchart illustrating a method for affording metrics in an automated scripting framework, in accordance with an embodiment of the present invention.

FIG. 11 illustrates the creating of Container "Roles" according to an embodiment of the present invention;

FIG. 12 is an illustration of a graphic display at a point where a user has right-clicked on the Schema folder and selected New--Attribute according to an embodiment of the present invention;

FIG. 13 illustrates the adding of different Roles according to an embodiment of the present invention;

FIG. 14 illustrates an example of the graphic display showing the attributes of member "Joe Bloggs" according to an embodiment of the present invention;

FIG. 15 is a flowchart that illustrates a method for handling events in a system;

FIG. 15.1 illustrates a ReTA Event Handler framework that manages the informational, warning and error events that an application raises according to an embodiment of the present invention;

FIG. 16 is a flowchart depicting a method for managing user information;

FIG. 16.1 illustrates a User framework which enables two approaches to maintaining user information according to an embodiment of the present invention;

FIG. 17 is a flowchart that illustrates a method for managing business objects in a system that includes a plurality of sub-activities which each include sub-activity logic adapted to generate an output based on an input received from a user upon execution, and a plurality of activities which each execute the sub-activities in a unique manner upon being selected for accomplishing a goal associated with the activity;

FIG. 17.1 shows a SubActivity component using the Persistence framework to retrieve a Customer Object from the Database according to an embodiment of the present invention;

FIG. 18 is a flow chart depicting a method for persisting information during a user session;

FIG. 18.1 illustrates a Session Flow Diagram--On Session Start according to an embodiment of the present invention;

FIG. 19 illustrates a Session Flow Diagram--On Start ASP Page according to an embodiment of the present invention;

FIG. 20 is a flow chart illustrating a method for generating a graphical user interface;

FIG. 20.1 is an illustration showing the steps for generating a HTML page consisting of a form with a TextBox, a DropDown list and a PushButton according to an embodiment of the present invention;

FIG. 21 is a flow chart depicting a method for software configuration management

FIG. 21.1 is an illustration of an IDEA framework on which the ReTA Development Architecture Design is based according to an embodiment of the present invention;

FIG. 22 illustrates the Configuration Management Life Cycle according to an embodiment of the present invention;

FIG. 23 illustrates the change control `pipeline` and each phase within the pipeline according to an embodiment of the present invention;

FIG. 24 depicts the application of Roles within the Microsoft Transaction Server (MTS) management console according to an embodiment of the present invention;

FIG. 25 illustrates an environment migration process that guides development within ReTA engagement environments according to an embodiment of the present invention;

FIG. 26 is an illustration of a Development/Unit test for existing applications according to an embodiment of the present invention;

FIG. 27 illustrates an assembly test for existing applications according to an embodiment of the present invention;

FIG. 28 illustrates a system test for existing applications according to an embodiment of the present invention;

FIG. 29 is a flowchart for production of existing applications according to an embodiment of the present invention;

FIG. 30 illustrates a graphic display of Visual Source Safe according to an embodiment of the present invention;

FIG. 31 illustrates a frame of PVCS Version Manager I-Net Client according to an embodiment of the present invention;

FIG. 32 is an illustration of a Build Source Control Model according to an embodiment of the present invention;

FIG. 33 illustrates an Assembly Test phase control mode according to an embodiment of the present invention;

FIG. 34 illustrates a Microsoft Visual SourceSafe `Labels` dialog box according to an embodiment of the present invention;

FIG. 35 illustrates a Database Diagram within Visual Studio according to an embodiment of the present invention;

FIG. 36 illustrates Object Modeling within Rational Rose according to an embodiment of the present invention;

FIG. 37 illustrates directly calling a wrapped CICS component according to an embodiment of the present invention;

FIG. 38 illustrates indirectly calling a wrapped CICS component according to an embodiment of the present invention;

FIG. 39 illustrates RSW eTest Automated Testing Tool according to an embodiment of the present invention;

FIG. 40 is an illustration which describes the physical configuration necessary for ReTA development according to an embodiment of the present invention;

FIG. 41 illustrates the application & architecture configuration for a typical ReTA Build environment according to an embodiment of the present invention;

FIG. 42 illustrates the application & architecture configuration for a typical ReTA Build environment according to an embodiment of the present invention;

FIG. 43 illustrates an IDEA Framework with components in scope ReTA Phase 1 according to an embodiment of the present invention;

FIG. 44 illustrates a NCAF Framework with the shaded components in scope for Phase 1 according to an embodiment of the present invention;

FIG. 45 illustrates a MODEnc Framework according to an embodiment of the present invention;

FIG. 46 illustrates a NCAF Framework according to an embodiment of the present invention;

FIG. 47 illustrates the components that comprise the ReTA execution architecture and their physical location according to an embodiment of the present invention;

FIG. 48 illustrates a MODEnc Framework for Operations Architecture according to an embodiment of the present invention;

FIG. 49 is an illustrative representation of a solicited event resulting from the direct (synchronous) polling of a network component by a network management station according to an embodiment of the present invention;

FIG. 50 is an illustrative representation of when an unsolicited event occurs when a network component sends (asynchronously) data to the network management station according to an embodiment of the present invention;

FIG. 51 illustrates event management in a net-centric environment according to an embodiment of the present invention;

FIG. 52 illustrates event management in an Intranet-based net-centric model according to an embodiment of the present invention;

FIG. 53 illustrates event management when using an Extranet-based net-centric model according to an embodiment of the present invention;

FIG. 54 illustrates the tables and relationships required for the ReTA Phase 1 Architecture Frameworks according to an embodiment of the present invention;

FIG. 55 illustrates tables and relationships required for the ReTA Phase 1 validation application according to an embodiment of the present invention;

FIG. 56 illustrates the physical configuration of a possible ReTA-engagement development environment according to an embodiment of the present invention;

FIG. 57 illustrates the physical configuration of possible ReTA-based Assembly, Product and Performance testing environments according to an embodiment of the present invention;

FIG. 58 illustrates Separate Web and Application Servers according to an embodiment of the present invention;

FIG. 59 illustrates a Single Web and Application Server according to an embodiment of the present invention;

FIG. 60 illustrates a Commerce Membership Server [Membership Authentication] properties view according to an embodiment of the present invention;

FIG. 61 illustrates a Membership Directory Manager Properties Dialog according to an embodiment of the present invention;

FIG. 62 is an illustration of a Membership Server Mapping Property according to an embodiment of the present invention;

FIG. 63 is an illustration of a Create New Site Foundation Wizard according to an embodiment of the present invention;

FIG. 64 illustrates the web application being placed under the "Member" directory of "cm" in Windows Explorer according to an embodiment of the present invention;

FIG. 65 depicts a typical ReTA engagement development environment according to an embodiment of the present invention;

FIG. 66 illustrates the development environment configuration for a ReTA Phase 1 engagement according to an embodiment of the present invention;

FIG. 67 illustrates an interface associated with the ability of inserting or removing statements within a block without worrying about adding or removing braces according to an embodiment of the present invention;

FIG. 68 shows a Visual J++ Build Environment according to an embodiment of the present invention;

FIG. 69 shows an interface for attaching to the MTS Process for debugging according to an embodiment of the present invention;

FIG. 70 shows an interface for debugging an Active Server Page (example global.asa file) according to an embodiment of the present invention;

FIG. 71 illustrates an example of Rose generated java file and javadoc comments according to an embodiment of the present invention;

FIG. 72 is a flowchart illustrating a method for testing a technical architecture;

FIG. 72.1 illustrates the application & architecture configuration for a typical ReTA Build environment according to an embodiment of the present invention;

FIG. 73 illustrates that the code for technology architecture assembly test may be migrated from the technology architecture component test environment as defined in the migration procedures according to an embodiment of the present invention;

FIG. 74 illustrates the application & architecture configuration for a typical ReTA Build environment according to an embodiment of the present invention; and

FIG. 75 illustrates the physical characteristics of the testing environment to be utilized during the Performance Testing Phases according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a flowchart illustrating a method 100 for affording an automated scripting solution for enterprise testing in accordance with one embodiment of the present invention. First, in operation 102, a table-driven automated scripting architecture is provided. Then, in operation 104, a test script is developed using the table-driven automated scripting architecture. A synchronized execution of the test script is then performed as indicated in operation 106. In operation 108, metrics of the synchronized execution of the test script are outputted.

The present invention has been developed and implemented to automate regression testing of host applications. Among other roles, the present invention can be used in an Integration Test (IT) phase to develop a more robust and systematic process for executing test scripts during certification testing. The present invention is a two-tier application, consisting of a database (Microsoft Access 97 or SQL Server) and an automation tool (Mercury Interactive WinRunner). The present invention reduces testing time and allows the testing team to detect and log more application issues, ensuring quality software delivery.

The present invention provides data-driven test scripts with an English-based, form-driven user interface. The present invention data architecture divides and stores test script information (steps, actions, application widgets, etc.) into separate, reusable components. The table relationships between these components provide the capability to develop easily maintained, data-driven test scenarios.

Traditional testing tools are manual and require long hours of slow and tedious testing. The few automated tools that do exist have limited flexibility and hard coded scripts.

In contrast, the present invention's unique and innovative features yield exceptional benefits in both scope and time. Organizational benefits include: increased development productivity, higher issue counts and shorter development cycles.

FIG. 2 is a schematic diagram illustrating one exemplary system architecture 200 of the present invention, in accordance with one embodiment of the present invention. The system architecture 200 includes a client script system 202 and a server script system 204. The client script system 202 includes a client computer 206, ASA modules 208, test script automator 210, and test script documentation 212. The server script system 204 includes a database 214, on-line help documentation 216, and metrics statistical reports 218.

In use, the client computer 206 updates test script data located on the database 214 utilizing an ODBC connection. The test script data is further passed to the ASA modules 208 via an SQL query. The ASA modules 208 then process the test script data and pass the processed data to the test script automator 210. Automated execution of the processed test script data is then performed by the test script automator 210, which is connected to a host application executing on the client computer 206.

In addition, the client computer 206 may be utilized to obtain the on-line help documentation 216 located on the server system 204. The server system also stores the metrics statistical reports 218 after execution of each test cycle. Finally, test script data is dynamically converted into English-based, test script documentation 212.

A preferred embodiment of a client computer system 206 in accordance with the present invention is preferably practiced in the context of a personal computer such as an IBM compatible personal computer, Apple Macintosh computer or UNIX based workstation. A representative hardware environment is depicted in FIG. 3, which illustrates a typical hardware configuration of a client computer 206 in accordance with a preferred embodiment having a central processing unit 310, such as a microprocessor, and a number of other units interconnected via a system bus 312. The workstation shown in FIG. 3 includes a Random Access Memory (RAM) 314, Read Only Memory (ROM) 316, an I/O adapter 318 for connecting peripheral devices such as disk storage units 320 to the bus 312, a user interface adapter 322 for connecting a keyboard 324, a mouse 326, a speaker 328, a microphone 332, and/or other user interface devices such as a touch screen (not shown) to the bus 312, communication adapter 334
for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 336 for connecting the bus 312 to a display device 338. The workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those skilled in the art will appreciate that the present invention may also be implemented on platforms and operating systems other than those mentioned.

A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided.

OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.

In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed.

OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.

OOP also allows creation of an object that "depends from" another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance.

When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons. Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.

With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, one's logical perception of the reality is the only limit on determining the kinds of things that can become objects in object-oriented software. Some typical categories are as follows:

Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system.

Objects can represent elements of the computer-user environment such as windows, menus or graphics objects.

An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities.

An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane.

With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.

If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built objects.

This process closely resembles complex machinery being built out of assemblies and sub-assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development.

Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.

The benefits of object classes can be summarized, as follows:

Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems.

Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other.

Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures.

Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch.

Polymorphism and multiple inheritance make it possible for different programmers to mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways.

Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them.

Libraries of reusable classes are useful in many situations, but they also have some limitations. For example: Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes. Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects. Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should.

Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers.

Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.

The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of" the system.

Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.

Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).

A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.

Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.

There are three main differences between frameworks and class libraries:

Behavior versus protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides.

Call versus override. With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together.

Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems.

Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language-2.0" (November 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J. C. Mogul, "Hypertext Transfer Protocol--HTTP/1.1: HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).

To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas:

Poor performance;

Restricted user interface capabilities;

Can only produce static Web pages;

Lack of interoperability with existing applications and data; and

Inability to scale.

Sun Microsystem's Java language solves many of the client-side problems by:

Improving performance on the client side;

Enabling the creation of dynamic, real-time Web applications; and

Providing the ability to create a wide variety of user interface components.

With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.

Sun's Java language has emerged as an industry-recognized language for "programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g., simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically, "C++ with extensions from Objective C for more dynamic method resolution."

Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta." ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention.

FIG. 4 is a flowchart illustrating a method 400 for affording a table-driven automated scripting architecture in accordance with one embodiment of the present invention. First, in operation 402, test script information is divided into a plurality of components. Then, in operation 404 the components are stored into a database. A relationship between the components is identified using a table, as indicated in operation 406. Test scenarios involving the components are then developed based on the relationship. See operation 408.

In one aspect of the present invention, the test script information relates to at least one of either steps and/or actions. The test scenarios are typically data-driven. In addition, the test scenarios may be developed using an English-based interface. As an option, the interface may be accessed utilizing a network. Also optionally, the architecture is a two-tier architecture.

The table-driven architecture inherent within the present invention is what makes it such a unique innovation. This feature provides benefits such as simplified test script development and maintenance, inherent GUI testing Best Practices, and reduced training time via English-based GUI interface. The table-driven architecture further allows the capability to quickly load data, flexible test cycle planning, real-time and statistical test status reporting, and essentially 100% test script execution accuracy.

FIG. 5 is a flowchart illustrating a method 500 for affording improved accuracy in an automated scripting framework in accordance with one embodiment of the present invention. First, in operation 502, a relationship is identified between test script components. Next, in operation 504, test scenarios involving the components are developed based on the identified relationship. A plurality of predefined actions are then provided as indicated in operation 506. The test scenarios are then uniformly executed utilizing the predefined actions. See operation 508. In one aspect of the present invention, the cause of errors raised while executing the test scenarios is analyzed. In another aspect, the test scenarios are data-driven. Optionally, the test scenarios may be developed using an English-based interface. Also optionally, the interface may be accessed utilizing a network. Execution of scripts by hand is plagued by error (skipped steps, misread script, etc.) Script automation has the inherent advantage of consistency. Uniform execution provides value to the testing effort. To that end, the present invention's predefined suite of standard actions ensures that every user-widget interaction is executed consistently. Other advantages of this consistency include issue identification/cause analysis and issue recreation.

FIG. 6 is a flowchart illustrating a method 600 for affording application independence in an automated scripting framework, in accordance with one aspect of the present invention. In an initial operation 602, a database including test criteria is provided. Then, in operation 604, a relationship between test script components is identified based on the test criteria. Test scenarios for an application involving the components are then developed independent of the application based on the identified relationship as indicated in operation 606.

In one embodiment of the present invention the test criteria is business rules. Optionally, the test criteria may be test conditions.

In another embodiment of the present invention, the test scenarios are stored for delayed execution. The test scenarios may be data-driven. In addition, the test scenarios may be developed using an English-based interface. Further, the framework may utilize a two-tier architecture.

Conventional automated testing software requires the host application to be running while the user is creating each test script. In the instance where the host application is malfunctioning or has not yet been developed, test scripts may still be developed in the present invention, without the application, in accordance with system requirements. The scripts may be executed at a later date when the host application has been completed and/or is functioning normally.

The present invention scripts can be executed with minimal knowledge of application functionality, testing experience and supervision. The tool itself is English-driven and the business rules and test conditions for the application are retained in the present invention, not the user.

FIG. 7 is a flowchart illustrating a method 700 for affording test development in an automated scripting framework, in accordance with an embodiment of the present invention. First, in operation 702, a database including business rules is accessed. Next, in operation 704, a relationship between test script components is identified based on the business rules. As shown in operation 706, test scenarios involving the test script components are then developed based on the identified relationship. The test scenarios are accessed utilizing an English-driven interface via a network. See operation 708.

In one aspect of the present invention, the test scenarios are data-driven. Optionally, the test scenarios may be developed using the English-driven interface. Also optionally, the interface is accessed utilizing a network. Further, the framework may utilize a two-tier architecture.

With the present invention, the creation of automated test scripts no longer requires recording or coding. Using the form-driven, english-based interface is intuitive, providing ease of use, simplified training, reduced learning curve and increased productivity.

FIG. 8 is a flowchart illustrating a method 800 for affording synchronization in an automated scripting framework, in accordance with an aspect of the present invention. First, in operation 802, script data is received utilizing a language-driven interface. Then, in operation 804, reports having user readable sentences are created based on the received script data. The received script data is then translated into automation code as indicated in operation 806. In operation 808, automated testing is provided utilizing the automation code.

In one embodiment of the present invention, the reports are created as hard copies. Optionally, the received script data is translated into automation code using relational table values. In another embodiment, the script data may be divided into a plurality of components stored in a database. Further, the database may reside on a remote server.

The present invention scripts have the distinct advantage of simultaneously being both paper-based and automation-ready at all times. Once script data is entered in the tool, pre-defined reports present the data as readable sentences while relational table values translate the data into automation code.

FIG. 9 is a flowchart illustrating a method 900 for affording test maintenance in an automated scripting framework in accordance with an embodiment of the present invention. In an initial operation 902, a plurality of test scripts are developed. Next, in operation 904, the plurality of test scripts are stored in a centrally located database. A user is then allowed to edit a specific test script located on the centrally located database as indicated in operation 906. The user edits the specific test script are then propagated to each of the plurality of test scripts, in operation 908.

In one aspect of the present invention, the user edits to the specific test script are propagated to each of the plurality of test scripts simultaneously. In another aspect, the plurality of test scripts are utilized to develop test scenarios.

In an embodiment of the present invention, the test scenarios are developed using an English-based interface. In another embodiment, the interface is accessed utilizing a network. In a further embodiment, the framework utilizes a two-tier architecture.

The present invention's relational database architecture significantly simplifies and reduces script maintenance. Edits are propagated instantly to all scripts. Also, all data is centrally located and easily created/edited.

FIG. 10 is a flowchart illustrating a method 1000 for affording metrics in an automated scripting framework, in accordance with an embodiment of the present invention. First, in operation 1002, a user is allowed to plan a test cycle for later execution. Next, in operation 1004, ownership of the test cycle is assigned. The test cycle is then executed to produce an execution performance of the test cycle, as shown in operation 1006. A statistical report of the execution performance of the test cycle is generated. See operation 1008.

In one aspect of the present invention, the statistical report is generated after the test cycle is executed. In another aspect, the statistical report is generated real-time during execution of the test cycle.

In one embodiment of the present invention, the statistical report is generated as a word processor document. Optionally, the statistical report may be generated as an HTML file. Also optionally, the statistical report is displayed on a computer display device.

The Resources eCommerce Technology Architecture (ReTA) is a solution that allows the use of packaged components to be integrated into a client based eCommerce solution. Before the present invention, the Resources architecture offerings provided services that supported the construction, execution and operation of very large custom built solutions. In the last few years, client needs have shifted towards requirements for solutions that continually integrate well with third party applications (i.e., data warehouse and portion of the present description management systems). Previous engagements have proven that it is difficult to integrate these applications into a new solution. As application vendors continue to produce new releases that incorporate technical advancements, it is even more difficult to ensure that these integrated applications continue to work with a given solution.

The ReTA approach to constructing, executing and operating a solution emphasizes the ability to change solution components with minimal impact on the solution as a whole. From this approach, ReTA views third party applications as another component in the overall solution. ReTA is component based, which means the engagement can choose to take only the pieces it needs to meet its specific business requirements. ReTA is especially suited to building small applications, implementing tools and packages, integrating applications and web enabling applications.

The present invention provides the ability to generate statistical reports of past execution performance, plan and assign ownership of future test cycles, and conduct real-time status reporting during test execution. These reports can also be output as various media, including MS Word and HTML.

Automated execution of application tests using the present invention is much faster than manual execution. Additionally, manual script execution is tedious, labor-intensive and prone to error. With the present invention, clicking, typing, etc. are executed at a rate of approximately one second per step.

The present invention further provides the ability to generate statistical reports of past execution performance, plan and assign ownership of future test cycles, and conduct real-time status reporting during test execution.

In one embodiment, the present invention is application software, written in a programming language such as VBA 6.0, which works cooperatively with Mercury Interactive's WinRunner to perform its automated testing function.

Site Server Framework Execution Architecture

To connect to a Site Server, a COM component (UserSS) is used to make calls to Site Server's API. The ReTA UserSS component allows the developer to access Site Server's Personalization and Membership Services without any knowledge of Site Server's API.

In a Site Server framework architecture, the UserSS COM component connects to the Site Server. The UserSS component uses Site Server's Personalization and Membership; UserSS also performs security as well on a Commerce Site. The ReTA framework uses the UserSS layer to provide access to Site Server. The UserSS layer provides the following benefits:

It insulates the application developer from Site Server's API.

It provides functionality for using Site Server's Personalization and Membership Services.

Site Server Framework Development Architecture

UserSS Interface Methods

The UserSS component interfaces with the SiteServer personalization and membership services. This component uses SiteServer to handle the user security, role and preferences.

Methods

The IAFUser, IAFUserPreferences, and IAFUserRole interfaces define the access to the AFUserSS component. These interfaces support the following methods:

Method Description Init This method initializes the UserSS Component. GetUserID This method returns a string value representing the user id. SiteServer's API is used to obtain this value. GetUserName This method returns a string value representing the user's name. SiteServer's API is used to obtain this value. GetRealName This method returns a string value representing the user's real name SiteServer's API is used to obtain this value. GetPref This method takes as input a preference label and returns a string value representing the user's preference value. SiteServer's API is used to obtain this value. SetPref This method accepts two parameters (String the PrefLabel, String the PrefValue). The preference is set that matches the "thePrefLabel" passed in. GetRoleID This method returns the current users Role id. GetRoleName This method returns the current user's role name. GetRolePref This method takes as input a preference label returns the current user's role preference value. SetRolePRef This method sets the current user's role preference

Site Server Personalization and Membership/Directory Membership Manager

This portion of the description describes the required settings in Site Server Commerce Edition used by the ReTA frameworks. This portion of the description also describes the steps involved in creating the required settings.

ReTA Required Settings

The Membership Directory Manager is used to manage administration and access control for Membership Directory objects, including users and groups, and schema objects. The Membership Directory stores objects used by all Site Server features.

The ReTA UserSS framework requires schema objects to be created. The schema objects required by the ReTA Frameworks are: Roles container, RoleName attribute, username attribute, webUserId attribute, and a Role class.

Required Container, Class, and Attribute Setup Instructions

Users may have different roles within the system. In Site Server ReTA takes advantage of this by creating a Container "Roles" that contains different "Roles" or different objects of the class "Role". These "Roles" have attributes such as a default start page. Therefore different "Roles" (different objects of the class "Role") such as "Operator" or "Customer" may both have a default start page attribute that may point to different URL's.

The Site Server portion of the present description details how to setup a Container, Class, and Attributes. The following lists the steps involved to setup the required attributes for the ReTA Frameworks to integrate with Site Server.

Using the Site Server Console, right click on the Membership Directory Manager folder.

Select New--Container, then type in Roles for the Container name.

FIG. 11 illustrates the creating of Container "Roles". Right click on Membership Directory Manager 1100 and select New 1102--Container 1104. After creating the Container "Roles", create the attribute "DefaultStartPage", "username", webUserId", and "RoleName" in the Schema. To create these attributes expand the Admin Container under the Membership Directory Manager.

Right click on the Schema folder 1200 and select New 1202--Attribute 1204 (See FIG. 12)

Define the class "Role" the same way by right clicking on Schema and selecting New--Class.

Select the "common-name" as a required attribute, also select the "DefaultStartPage" as an attribute but do not make it required.

Create the Roles for our Application, "Operator" and "Customer".

See FIG. 13, which illustrates the adding of different Roles. Right click the Roles Container 1300 under the Membership Directory Manager folder 1302. Select New 1304--Object 1306, select "Role" for the class of object to create, type the name of the object i.e. "Operator", add the attribute "DefaultStartPage" by clicking Add Attribute button and enter the URL.

Once these have been created, a member of the system can be assigned to a "Role" and the ReTA Framework required attributes can be added to the user. FIG. 14 illustrates an example showing the attributes 1400 of member "Joe Bloggs" (Note RoleName).

EVENT HANDLER FRAMEWORK DESIGN

FIG. 15 illustrates a method 1500 for handling events in a system. In operation 1502, an event which includes metadata is recognized. Next, in operation 1504, the metadata of the event is read and, in operation 1506 a table look-up is performed for information relating to the event based on the metadata. The information includes a severity of the event and further information such as a type of the event, and a location where the event occurred. In operation 1508, a message is displayed either in-line in a currently depicted display or in a separate display based on the severity of the event.

Optionally, the event may additionally be indicated to components of the system other than the component in which the event occurred. The type of the event may be a database error, an architecture error, a security error, and/or an application error. Further the location of the event may be at least one of a method and an object where the event occurred. Also, the information may further relate to a code associated with the event.

The message may include the information relating to the event. In additionally, the message may also include a time during which the event occurred. Further, the message may include a string altered based on a user profile. The following material provides a more detailed description of the above-described method.

This portion of the present description details the ReTA Event Handler framework design from the perspective of the application developer. The role of this framework is to provide services to manage the informational, warning and error events that an application may raise. These services include:

Presenting the user with an understandable event explanation.

Informing other Components when errors happen (for example to restore transactional data to a consistent state) using a Publish/Subscribe mechanism.

Logging informational, warning and error event messages.

The Event Handler uses an Event Reference meta-data database table to maintain information about the types of events in an application and the policy for dealing with them. This gives a flexible approach and the event messages, the severity and other policies for the events can be changed during operations.

Phase 2--Event Handler Enhancements

For phase 2, Event Handler consists of the following enhancements:

The Event Handler framework is componentized. It no longer maintains references to any of the other framework components. Internally, the Event Handler continues to use the persistence light framework to log events to the database.

As in phase 1, it can be used as a Session level component. As an enhancement for phase 2, the Event Handler framework can be used as a stateless page level component. This means that a new instance of the component is created at the beginning of each ASP page and is released at the end of each page.

The Event Handler framework no longer requires Event Collection components as parameters to implement event handling, which only allowed handling events at the page level. In phase 2, the new method "processSingleEvent" takes the parameters of a single event as its input, which enables handling events at the occurrence of the event.

As in phase 1, The Event Handler can format error descriptions in HTML. As an enhancement for phase 2, the Event Handler can return the error message as a string and enables the application to implement client specific formatting (HTML or other).

The process event method no longer calls the ASP redirect method. Instead, it returns the severity level code. On return, the application logic determines whether to redirect to the error page or display the error in-line in the current page.

The Translator is no longer a separate component. Instead, it is a Java class inside the Event Handler component.

Event Handler Framework

Description

With reference to FIG. 15.1, the ReTA Event Handler Framework 1530 manages the informational, warning and error events that an application raises. The following describes the ReTA event handling sequence:

1) The event(s) occurs

When an event occurs the following event information is recorded: event type (defined in database Event Reference table), for example: database error security error architecture error application error event location: method and object name where the event occurred event code (sub-type): SQL error code, application error code--mapped to a unique description in the database architecture error code--mapped to a unique description in the database event context: Any relevant information about when the event occurred stored in a tagged name value pair format. Eg. [OrderNumber=1][Description="Repeat Order"]

If the event occurs within a Java class inside a COM object, use the Java exception mechanism by throwing an AFEventException. If the exception occurs elsewhere, call the add method on the Event Collection passing the event information.

Each method defining a COM component interface captures these event exceptions and either adds them to an Event Collection component or directly calls a method on the Event Handler component.

Events are processed from the ASP page by calling the process method of the Event Handler. Events can also processed from the point where the event occurred by calling the "processSingleEvent" method of the Event Handler.

2) The Event Handler processes the event(s):

For each event, set the user id and current page

For each event, retrieve the event severity from the event handler's "translator" class. This class caches in memory all event descriptions and severity levels retrieved from the event reference database table.

Add the events to the Event Handler context.

Implement the persistence policy on the events--events are logged in a batch.

Return the severity of the most severe event to the caller. The caller is responsible for either redirecting to the error page or displaying the event in-line in the Current Page.

3) Display the event:

Use the Event Handler component to generate the error message. This message can contain context information describing when the event was created.

Create the HTML formatting and display the event message.

The Error Message is either displayed in-line in the current page or in a separate error page.

4) The Event Handler generates error display message:

Get the event with the highest severity level from its event context.

If the most severe event is "fatal", display the user description associated with the event. Broadcast a SESSION_ABORT message using the Publish/Subscribe mechanism. Any component that is interested in these events must implement the IAFEventListener interface and register with the Event Broadcaster component as interested. To do this they call the addListener method of the Event Handler component.

If the most severe event is "logical unit of work", display the user description associated with the event. Broadcast an ACTIVITY_ABORT message using the Publish/Subscribe mechanism.

If the most severe event is "warning", display the user description associated with the event.

Note: The user event descriptions are retrieved from the database either on session start or on demand and are cached by the Translator class. When generating the event description page, this description is requested from the Translator. Event descriptions can have embedded context parameters. When generating the event description page, the event handler replaces these parameters with their values specified when creating the event.

Database Tables

The Event Handler uses two database tables: The T_AF_EventReference 1534 is a static table that describes the Event meta-data, giving the policies for each event type. The policies include:

The message that is displayed to the user. These messages can contain data from the Context that is included when the event is generated.

The severity of the event. The severity can be Information, Warning, Error and Fatal.

Whether to persist the event in the database event log.

The T_AF_EventLog 1536 contains the log of the events that occurred. The following information is logged:

Event type and Code

The location where the event occurred. I.e. ASP, Object name and Method Name.

The user that raised the event.

The datestamp.

The context information giving other information about what caused the event.

Services

The Event Handler Framework provides the following services:

Service Detail Register event Create event Maintain event reference Process event Information Warning Logical Unit of Work Fatal Display events Translate event Inform user Persist event Log event to database

Components and Classes

The Event Handler Framework implements these services through the following COM and Class objects:

Service Component AFEventHandler Handle events generated by the system AFEventCollection Contains a collection of events (AFEventException) AFResult Defines the result returned by a method execution. Class AFEventException Contains single event information. AFEventReference Contains event reference information from database table T_AF_EventReference AFTranslator Returns event reference information based on the event type and event code. Note: multi-language translation functionality not implemented AFPersistableEvent This is the persistable class containing the information for a single event. It is a sub-class of the Persistence PersistableObj class. The persistance mechanism can insert, delete, select and update objects of this class in the database. This class persists event information the T_AF_EventLog table.

These components and classes are described in detailed in the following sub-portions of the description.

AFEventHandler

The AFEventHandler component 1538 handles the events generated by the system. Depending on the severity level, the event handler may redirect the user to another ASP page and may abort the activity or session. The event handler also determines whether and when to log an event.

Methods

The IAFEventHandler interface defines the access to the AFEventHandler component. This interface supports the following methods:

Method Description PersistAllEvents Persist all events stored by the event handler to the database. ProcessSingleEvent Gather associated event information. Call the add method to persist the events in the event log. Return the event severity to the caller. This method is called either from the ASP page or from a Java class where the Event was trapped. Process Examine the events and gather associated event information. Call the add method to persist the events in the event log. Return the event severity of the most severe event to the caller. The application developer calls this method from an ASP page to check the events generated during the scripting logic execution. Generate Return generated HTML which describes the severity of the error, gives the target URL (depending on the severity - previous page, activity start page or home page) and an error log. The Event Handler page calls this method. Initialize The application developer can invoke this method to load all event descriptions in memory (normally used to speed access during user session). GetErrorDescription Return error message as a string, which describes the security of the error. This allows the application to determine the HTML formatting used to display an error. HasFatalError If the event handler contains at least one fatal error, returns true.

AFEventCollection

The AFEventCollection component contains a collection of events.

Methods

The IAFEventCollection interface defines the access to the AFEventCollection component. This interface supports the following methods:

Method Description SpecifySubActivity Attach the sub-activity to all events contained in the event collection. GetSubActivity Return the sub-activity attached to all events contained in the event collection. Add Add an event to the event collection. Get Return the requested event. NumberOfEvents Return the number of events in the collection. Clear Clear all the events from the collection.

AFResult

The AFResult component defines the result return by a method execution.

Methods

The IAFResult interface defines the access to the AFResult component. This interface supports the following methods:

Method Description GetResult Return the result. AddResult Add a result. AddResultString Add the result as a string. GetResultString Return the result as a string.

AFTranslator

The AFTranslator class returns event reference information (based on the event type and event code.

Methods The AFTranslator class has the following methods:

Method Description GetEventTranslation Return the description for this event. GetEventSeverity Return the severity level for this event. GetEventPersist Return flag that defines whether to persist this event. GetUserDescription Return the user description for this event. This description is displayed to the user. GetDescription Return the description for this event. This description is user by the technical support team to analyze error. Start Initialize component.

AFEventException

The AFEventException class contains the event exception information and is added to the AFEventCollection component for processing by the AFEventHandler component.

Methods

The following AFEventException class methods are important for the application developer to understand:

Method Description AFEventException Create the event exception class and populate it with event type: database error Java error security error architecture error application error event location: method and object name where the event occurred event code (sub-type): SQL error code, Application error code - mapped to a unique description in the database Architecture error code - mapped to a unique description in the database event context: value of specific object AddToCollection Add the current event to an event collection.

AFEventReference

The AFEventReference component 1540 contains the event reference information that is defined by the application through database table T_AF_EventReference. The architecture reads the event reference data into memory on session start.

T_AF_EventReference:

Column name Description Id Unique id Type The event type Code The event code Severity Level The event severity level: 1: Information 2: Warning 3: Abort the activity 4: Fatal, close the session Persist 1: if the event should be persisted in the event log 0: if the event should not be persisted Description Event description showed to the operator User Description Event description shown to the user. This description can contain contextual information, which is specified by adding tag like [ParameterName] in the description. These tags are replaced by the event framework when displaying the event to the user. Language Language of the description. This may be used by the multi-language framework when developed. At this time, set to `English`. Context Event context default value.

AFPersistableEvent

The AFPersistableEvent 1542 contains the event information captured during the application execution that is persisted to the database table T_AF_EVENTLOG.

T_AF_EVENTLOG:

Column name Description Id Unique id Type The event type Code The event code SeverityLevel The event severity level: 1: Information 2: Warning 3: Abort the activity 4: Fatal, close the session SubActivityLevel Name of Sub Activity where event occurred. MethodName Name of class method where event occurred. ObjectName Name of class where event occurred. ASP Name of ASP page where event occurred. Context Event context default value. UserID ID of user logged in when event occurred. LastUpdate

USER FRAMEWORK DESIGN

FIG. 16 depicts a method 1600 for managing user information. A site server is provided in operation 1602. The side server has information stored on it including preferences, roles, and details relating to users. A database separate from the site server is provided in operation 1604. The database has information stored thereon including preferences, roles, and details relating to the users. In operation 1606, an identity of one of the users is authenticated. A single interface is displayed in operation 1608, which provides the user access to both the site server and the database upon authentication of the identity of the user. In operation 1610, the user is allowed to view and change the information that is stored on the site server and the database and that is associated with the user. The single interface is tailored in operation 1612 based on the information associated with the user.

The identity of the user may be authenticated by verifying a user name and a password, a secure sockets layer (SSL) certificate, and/or a log-in form. Further, the preferences relating to the users may include a currency in which monetary values are displayed and a language in which text is displayed. Also, the roles relating to the users may include a customer, a manager, and an employee. Additionally, the details of the users may include a user name and a legal name. The following material provides a more detailed description of the above-described method.

This portion of the present description details the ReTA User framework design from the perspective of the application developer. The primary role of this framework is to provide services that allow the application developer to maintain user preferences, roles and security.

In regards to security, the User framework provides User Authentication services through any of the standard Internet Information Server security methods:

Username/Password sent in clear text.

SSL Certificates

Windows NT Challenge/Response (Intranet only)

HTML Forms login (Site Server version only)

Once the user has been authenticated, the User framework provides services for accessing:

User information--NT username, Real Name.

User Preference information--For example Language, Currency (These are configurable)

User Role information (e.g. Customer, Manager, Employee)

User Role Preference information

There are two implementations of the User Component: One is database driven and the other interfaces with Site Server Personalization and Membership directory.

User Framework

Description

With reference to FIG. 16.1, the User framework 1630 enables two approaches to maintaining user information. The framework supports two approaches by exposing a single set of interfaces that can be used by either of the two user framework components. With the AFUserSS component 1632, the framework interfaces with the Microsoft Site Server products Personalization and Membership Directory. For this user component, SiteServer holds and manages user information. With the AFUserDB component 1634, the framework interfaces with database tables. For this user component, database tables define the user information.

Services

The User Framework provides the following services:

Service Detail User Information User Role Maintenance User RoleName User Preferences User Role Preferences User Id User Name User RealName

Components

The User Framework implements these services through the following COM objects:

Component Service AFUserDB User information maintained through the following database tables. T_AF_USERNAME, T_AF_USERPREFERENCES T_AF_USERROLES AFUserSS User information maintained through SiteServer.

These components are described in detailed in the following sub-portions of the description.

AFUserDB

The AFUserDB component holds the user role, preferences and details retrieved from the database. When created the user component retrieves the user NT login name, user details and constructs the user preference and user role objects.

Methods

The IAFUser, IAFUserPreferences and IAFUserRole interfaces define the access to the AFUserDB component. These interfaces support the following methods:

Method Description Init This method retrieves the user's NT name, user details from the database, constructs the preference object and constructs user's role object. GetUserID Returns the user id. GetUserName Returns the user's NT account name. GetRealName Returns the user's real name. GetPref Returns user's preference based on label passed to this method. SetPref This method sets the user's preference to the 2.sup.nd parameter passed in. GetRoleID Returns the user's role ID. GetRoleName Returns the user's role name. GetRolePref Returns role preference. SetRolePref This method sets the current user's role preference

AFUserSS

The UserSS component interfaces with the SiteServer personalization and membership services. This component uses SiteServer to handle the user security, role and preferences.

Methods

The IAFUser, IAFUserPreferences, and IAFUserRole interfaces define the access to the AFUserSS component. These interfaces support the following methods:

Method Description Init This method returns a zero integer. It is here for compatibility with the UserDB component. GetUserID The method returns a string value representing the user id. SiteServer's API is used to obtain this value. GetUserName This method returns a string value representing the user's name. SiteServer's API is used to obtain this value. GetRealName This method returns a string value representing the user's real name. SiteServer's API is used to obtain this value. GetPref This method returns a string value representing the user's preference. SiteServer's API is used to obtain this value. SetPref This method accepts two parameters (String the PrefLabel, String thePrefValue). The preference is set that matches the "thePrefLabel" passed in. GetRoleID This method returns the current user id. GetRoleName This method returns the current user's role name. GetRolePref This method returns the current user's role preference. SetRolePref This method sets the current user's role preference

PERSISTENCE FRAMEWORK DESIGN

FIG. 17 illustrates a method 1700 for managing business objects in a system that includes a plurality of sub-activities which each include sub-activity logic adapted to generate an output based on an input received from a user upon execution, and a plurality of activities which each execute the sub-activities in a unique manner upon being selected for accomplishing a goal associated with the activity. First, in operation 1702, an identifier and a reference to a business object are received from one of the sub-activities upon the execution thereof. In operation 1704, a database is accessed and data from the database is retrieved based on the identifier. The business object is created and populated with the data retrieved from the database in operation 1706.

The data may be stored on the database in tables. Further, the created business object may replace an existing business object. Additionally, the identifier may identify a customer and the business object may be a customer object. Also, a business object referenced by one of the sub-activities may be removed upon the execution thereof.

The business object may be a Visual Basic business object. In another aspect of the present invention, the business object may be a Java business object. The following material provides a more detailed description of the above-described method.

This portion of the present description details the ReTA Persistence framework design from the perspective of the application developer. The role of this framework is to provide services that interact with application database(s) to create, retrieve, update and delete business objects.

Persistence Framework

Description

The ReTA Persistence framework provides a transparent and flexible mapping of the business object attributes to relational database tables. To implement this "business object to database table" mapping, the framework is tightly integrated with all business objects. The framework exposes abstract methods that the application developer implements in the business objects. In contrast with the other ReTA frameworks, the Persistence framework is not implemented as a separate component. The Persistence framework is a set of local language classes available in Java or Visual Basic. FIG. 17.1 shows a SubActivity component 1730 using the Persistence framework 1732 to retrieve a Customer Object 1734 from the Database.

Services

The Persistence Framework provides the following services:

Service Detail Database Connection Uncouple database connection from application Database mapping Map an object to a database table Object query Trigger queries on objects Easily iterate through the results Record locking Optimistic locking Encryption Encode Database User Name and Password Note: Encoding implemented only once (as part of system set up). Decode Database User Name and Password Note: Used by persistence framework during all database accesses.

Classes

The Persistence Framework implements these services through the following Java or Visual Basic Classes:

Service Java Class AFPLPersistableObj This is the superclass of all Java Persistable Objects in the application. Application developers create a subclass for each Business Object and implement all the abstract methods that this class defines. AFPLExtent Provides the mapping between the business object and its associated database table and manages the database connection. Visual Basic Class VBPersistObj This is the interface class that all VB must implement. Application developers create a subclass for each Business Object implement all the methods that this class defines. VBExtent Provides the mapping between the business object and its associated database table and manages the database connection.

These classes are described in detailed in the following sub-portions of the description.

AFPLPersistableObj

The AFPLPersistableObj abstract class contains methods called by the application developer objects to manage attribute values common to all persistable business objects (user id and last update timestamp). In addition, the AFPLPersistableObj class represents the superclass of a persisted object. In order to persist a business class; the application developer extends AFPLPersistableObj and implements the AFPLPersistableObj abstract methods.

The AFPLPersistableObj defines the following methods:

Method Description addColumnNames Return the column names common to all persistable business objects (user id and last update timestamp). The application developer invokes this method from the constructor method of business object. addPersistedAttributes Return attributes common to all persistable business objects (user id and last update timestamp). The application developer invokes this method from the getPersistedAttributes method of a business object. isEqual Abstract method that all Business Objects must implement. If the passed in attribute is one of the attributes common to all persistable business objects (user id and last update timestamp), compare the passed in value to the currently held attribute value. The application developer should also invoke the superclass isEqual. newFrom Abstract method that all Business Objects must implement. Populate the Business Object using the result set passed as an attribute. The application developer should also invoke the superclass newFrom method to populate the UserId and lastUpdate attributes. attributeGet Abstract method that all Business Objects must implement. Return the value of the attribute passed as parameter attributeSet Abstract method that all Business Objects must implement. Set the value of the attribute passed as parameter setUserId Set the user id value getUserId Return the user id value setTimeStamp Set the last update timestamp value getTimeStamp Return the last update timestamp value setUserIdTimeStamptoObj Adds the last update timestamp value and user id to the passed in persistable business object. The application developer invokes this method from the setUserIdTimeStamptoObj method of a business object. getColumnNames Return the database table column names. getPersistedAttributes Return all the attributes to persist. The application developer invokes the addPersistedAttribute method of the super class to add user id and last update timestamp attributes. getKeyNames Return the primary key field name. getKeyValue Return all the primary key values. getKeyAttributeVector Return vector of all key attributes. getKeyAttributes Return the array of all key attributes. getTableName Return the name of the database table associated with this business object. columnList Returns a comma-separated list of all columns corresponding with this class. attributesForInsert Returns a comma separated list of attribute values for SQL insert command. attributesForUpdate Returns a comma separated list of attribute name = attribute value pairs for SQL update command. conditionForUpdateRemove Returns the `where` clause for SQL update or remove command (both are equal).

AFPLExtent

The AFPLExtent class provides the mapping between the business object and its associated database table. In addition, the AFPLExtent class represents the domain defined by the visible part of the database table for the specified user. This class holds the passed in database URL, username and password used during the access to the database. Lastly, the AFPLExtent class manages the database connection.

Methods

The AFPLExtent class implements the following methods used by the application developer from business factory objects:

Method Description Select Return all business objects matching the search criteria. Update Update all business objects matching the search criteria Delete Remove all business objects matching the specified criteria Insert Insert new business object(s)

VBPersistObj

The VBPersistObj interface class contains methods that need to be implemented on every VB Business Object.

The application developer implements the following methods from their business object:

Method Description newFrom Create a new instance of that class using the result set passed as parameter GetValue Returns the value for the attribute passed as parameter. SetValue Sets the value for the attribute passed as parameter. GetColumns Return the database table column names. GetTableName Return the Table Name where this class is stored in the database. attributesForInsert Returns a comma separated list of attribute values for SQL insert command. attributesForUpdate Returns a comma separated list of attribute name = attribute value pairs for SQL update command. conditionForUpdateRemove Returns the `where` clause for SQL update or remove command (both are equal).

VBExtent

The VBExtent class provides the mapping between the business object and its associated database table. In addition, the VBExtent class represents the domain defined by the visible part of the database table for the specified user. This class holds the passed in database URL, username and password used during the access to the database. Lastly, the VBExtent class manages the database connection.

Methods

The VBExtent class implements the following methods used by the application developer from business factory objects:

Method Description Select Return all business objects matching the search criteria. Update Update all business objects matching the search criteria Delete Remove all business objects matching the specified criteria Insert Insert new business object(s)

SESSION FRAMEWORK DESIGN

FIG. 18 illustrates a method 1800 for persisting information during a user session. First, in operation 1802, a session is initiated upon a user accessing a predetermined starting page. A current page accessed by the user is then tracked in operation 1804 while browsing a plurality of pages during the session. In operation 1806, a record is maintained of a page previously accessed by the user during the session. Information is persisted in operation 1808. This information is selected from a group of items such as user identifier, a time of a most recent user action during the session, activity components accessed during the session, and business components accessed during the session. During the session, the current page, previous page record, and information are provided to at least one activity component in operation 1810. Also in operation 1810, the activity component generates output based on input provided by the user via the plurality of pages.

In one embodiment of the present invention, the activity components to which the current page, previous page record, and information are provided may be selectively determined. In addition, the activity component may be provided an indication as to whether the user is permitted to access each of the pages. In such a case, the activity component may also be provided the indication as to whether the user is permitted to access each of the pages based on the previous page record.

In another embodiment of the present invention, the information may also include the user identifier. In such an embodiment, user preferences may be looked up based on the user identifier with the information including the user preferences. Also, in order to identify the persisted information, references to activity components, business components, a user component, a tracking manager component, a system preference component, and an event handler component may be employed. The following material provides a more detailed description of the above-described method.

This portion of the present description details the ReTA Session framework design from the perspective of the application developer. The primary role of this framework is to provide services to handle the stateless nature of Internet. By default, the Internet does not provide services for maintaining information between pages. Without these services, it would not be possible to implement most eCommerce functionality. For example, session level state is necessary to implement eCommerce functionality where a customer can select products on multiple product description pages and then submit a complete product order request from a confirm order page. The ReTA Session framework leverages the Internet Information Server/Active Server Page (IIS/ASP) session object, which is automatically created when a user who has no open IIS sessions requests a Web page.

Session Framework

Description

FIG. 18.1 illustrates a Session Flow Diagram--On Session Start. As shown, a Session framework 1830 operates in the MTS Runtime Environment 1832. FIG. 19 illustrates a Session Flow Diagram--On Start ASP Page. Again, the Session framework 1900
operates in the MTS Runtime Environment 1902. The ReTA Session framework provides services required throughout a user session. The user creates the Session framework at log on and removes the Session framework at log off. During the lifetime of the user session, application and architecture components require certain data to persist. This framework provides services to store and retrieve all information needed for a particular user session. This information may persist throughout the user session. The Session framework also provides services to uniquely identify the user and enforce access rights.

The user information that the Session framework persists, in memory, between Active Server Page requests includes:

User id Identifies session user

Last page Last page accessed by the session user.

Current page Current page accessed by the session user.

Last connection time: Session user's last connection time.

Current activity: Activity currently being executed by the session user (refer to activity framework design)

Activity Components All activity components accessed during user session

Business Components All business components accessed during user session required by multiple activity components.

Note:

This framework uses the Active Server Page's Session Object. Thus, the framework only works with browsers that accept cookies. For other browsers (or if cookies are disabled), a new ASP Session Object may start for each web page.

Services

The Session Framework provides the following services:

Service Detail Security User identification Page access authorization - Session scope Automatic abort - timeout Customized information Customized user interface delivery Customized application access Manage user session Inform user on session status Abort session Flow control Page to open on action Pages of activity Maintain context Activity Component context Business Component context - shared among activities Message Broacast Register listener Broadcast Message to registered listeners Encode Database User Name and Password Encryption Note: Encoding implemented only once (as part of system set up). Decode Database User Name and Password Note: Used by session framework during all database accesses.

Components

The Session Framework implements these services through the following COM objects:

Component Service AFSession Manages current user session AFSystemPreferences Contains System Preferences from database table T_AF_SYSTEMPREFERENCES AFTrackingManager Contains security and flow control info from database tables T_AF_PAGESOFACTIVITY, T_AF_AUTHDESTINATIONPAGE T_AF_AUTHSOURCEPAGE T_AF_DESTINATIONFORACTION AFBrowserInfo Contains current user's web browser information

These components are described in detailed in the following sub-portions of the description.

AFSession

The AFSession component maintains the user's session state information. To maintain the state information, this component holds references to activity components (logical units of work--application flow logic), business components (business logic required across activity components), user component (user information), tracking manager component (web page access security and web page flow control information), system preference component (system preference information) and event handler component (event handler) created during the user's session.

From the application developer's perspective, the state maintenance work performed by the AFSession component is transparent. The application developer leverages the session services through populating the database tables with the client specific information.

Methods

The IAFSession, IAFEventBroadcaster and IAFContext interfaces define the access to the AFSession component. These interfaces support the following methods:

Method Description AFSession Start Start session - Called by ASP (global.asa Session_OnStart). Stop Stop session - Called by ASP (global.asa Session_OnStop). StartPage This method is called by ASP script logic at the start of each page. It is used to broadcast a pageStart event to all the listeners (activity components) that have registered as interested in pageStart events. It also stores this page as the current page and moves the existing current page into the last page (information held by the session's "tracking" object). StopPage This method is called by ASP script logic at the end of each page. It is used to broadcast a pageEnd event to all the listeners (activity components) that have registered as interested in pageEnd events. Abort This method is called when the session is to be aborted. This method calls the abort method on all activity components known to session (held by the session's "activity context" object). SetCurrentPage Sets the current Active Server page (held by the session's "tracking" object). GetCurrentPage Returns the current Active Server Page (held in the session's "tracking" object). GetLastPage Returns the last Active Server Page accessed in the session (held in the session's "tracking" object). SetSessionId Update the sessionId attribute. GetSessionId Returns the current session Id. SetCurrentActivity Sets the current activity Page (held in the session's "tracking" object). GetCurrentActivity Returns the instance of the current activity (held in the session's "tracking" object). GetActivity Returns the instance of the requested activity (held by the session's "activity context" object). IsActivityInContext Ask session if it has a reference to the requested activity (held by the session's "activity context" object). If found, returns true, else returns false. AddActivity Add the requested activity (references held by the session's "activity context" object). Set the requested activity to the current activity (held in the session's "tracking" object). RemoveActivity Remove the current activity (held by the session's "activity context" object). GetNextPage Returns the next web page to access for the current activity (information held by the "tracking manager" component). GetAFUser Returns the "user" component (information associated with the current logged in user). SetAFUser Sets the user for the current session. Returns an integer indicating success or failure. GetTrackingManager Returns the "tracking manager" component. GetEventHandler Returns the "event handler" component. GetSystemPreferences Returns the "system preference" component. AddObject Add a business object (held by the session's "business object context" object). GetObject Returns the instance of the requested business object (held by the session's