">
" TITLE="Return to Exploration Air Benefits">
B A C K
V I E W S O U R C E
|
How The Employee Benefits Home Page Works
The Big PictureThis page retrieves the user's Windows NT user name and determines whether the user has used the Benefits application before. If the user has used Benefits before, his information is retrieved. The first time into Benefits, the user's records are initialized.Design GoalsThe goal of the Benefits application is to demonstrate Best Practices for creating sophisticated Web applications. It uses a combination of Active Server Pages (ASP) scripts and ActiveX components running under Microsoft® Transaction Server to interface with a Microsoft® SQL Server database. The Benefits application generally uses Microsoft® Visual Basic® Scripting Edition (VBScript) on the server, and JScript on the client. It is designed to work best with Microsoft® Internet Explorer 4.0 and later, but will also degrade gracefully to work with lower level browsers.The Benefits application is a multi-tier client/server application. The ASP pages present data to the user and accept changes, requesting as needed the services of the ActiveX components. The ActiveX components implement business logic and interface with the database. A Microsoft® SQL Server database provides data services. Microsoft® Transaction Server works at all three levels to ensure data integrity and efficient resource usage. Functional OverviewThis page is generated under two conditions. The first is by request to the page, as when the link to "Benefits" from the Exploration Air Home Page is clicked, or a bookmark is clicked or the URL entered in the browser's Address field. The second is when a user attempts to access another page in the Benefits application without having first visited the Default page during the current session. Each page in the Benefits application includes a file called libAuthenticate.inc. This file checks whether the user has a Session variable containing the EmployeeId. If not, then the request is redirected to this page to ensure that the application is properly initialized for the user. This page first checks to see if this is the first time the user has been at this page during the current session. It determines if this is the first time by checking whether the session variable "EmployeeId" has been set. Session variables are created by assigning a value to them. Session variables apply only to an individual user's session, and persist until the session is ended. A session is defined as the period between when a browser is opened and when it is closed. If more than one browser window is open, the session will continue until all browser windows are closed. If the session variable "EmployeeId" has not been set, the page will request the LOGON_USER from the browser. The value of LOGON_USER is the user's Windows NT account name, including domain name, in the format MYDOMAIN\myusername. This means that, in production, the Benefits application is only accessed from a valid Windows NT account, using a browser that is capable of passing Windows NT account information (currently possible only with Microsoft Internet Explorer 2.0 or later). The Directory Security on the server must be set to require "Windows NT Challenge/Response" for the Benefits directory. If the Directory Security is not set correctly, the server will not request the LOGON_USER, and the Benefits application will not be able to access the database, so it will not let the user move beyond this Default.asp page. In order to make the demonstration site more forgiving, an existing user name is defaulted into the logon user field if it is not received from the browser. This feature would not be used in a production system. The user name is used to retrieve the EmployeeId from the database, using an ActiveX component called by the subroutine LookupEmployee. If there is a problem
If there were no errors in looking up the employee record from the database, then the code checks to see if there is now an EmployeeId set for the session. The EmployeeId will be present if there was a record in the database for the user. If there is still not a session EmployeeId, then the user must be a new employee, so the code sets up a new employee in the database. This process is done by the subprocedure SetupEmployee. SetupEmployee calls the Employee.AddNew method of the Employee class of the ActiveX component Benefit. The Employee.AddNew method inserts a record in the Employee table for the employee. Employee.AddNew then calls the Employee.AddEmployeeDependent method to create records in the tables Dependent and EmployeeDependent. Each employee has a record in the Dependent table with DependentType of Employee. The dependent record is used to hold personal information, and also used to track benefit coverage. Employee.AddNew next calls Employee.NewBenefitsto create the benefit records for the employee. Every benefit that is active and applies to the current year will be added to the employee's records. If a minimum Plan is defined, the employee's benefit record will include that Plan. Last, Employee.AddNew calls Employee.AddQualifier to add a qualifier record to the EmployeeQualifier table, so that the Benefits application will allow the employee to change his benefit choices for a period of time defined in the BenefitQualifier table.
Data ModelYou can view a diagram of the database. The data used to set the Session's EmployeeId is from the Employee table. If a new employee record is created, records are added to tables Employee , Dependent , EmployeeDependent , and EmployeeQualifier .
Components UsedThis pages uses methods in the Employee class of the Benefit component. The Employee.LookupEmployee method is used to return the EmployeeId. If the user does not already have a record in the Benefits application, the Employee.AddNEW method is used to create the database records for the employee.
|
|
©1997 Microsoft Corporation. All rights reserved. Terms of Use.
|