ࡱ > q 2 bjbjt+t+ A A ! ] D D D D 4 h p $ c3 , ( 0 0 0 0 4 0 4 1 4 *3 $ 4 6 N3 3 N3 $ D D ? $ $ $ D 0 D D D D 0 $ , $ ) . l 0 L pA " b0 * EXPLOITING WEB PUBLISHING TECHNOLOGY TO ENHANCE PERFORMANCE REPORTING Claude Aron Chevron Information Technology Company San Ramon, CA email: jaro@chevron.com The use of corporate intranets for publishing reports of all kinds is now a well-established standard. However, merely throwing a bunch of files onto a web server isn't a very satisfactory solution. This paper attempts to document some techniques we have employed at Chevron to present performance data in an efficient and easily navigable format that exploit the unique strengths of web publishing technology. INTRODUCTION The use of corporate intranets for publishing reports of all kinds is now a well-established standard. However, merely throwing a bunch of files onto a web server isn't a very satisfactory solution. This paper attempts to document some techniques we have employed at Chevron to present performance data in an efficient and easily navigable format that exploit the unique strengths of web publishing technology. Moving from paper-based reporting to web-based reporting, even if you do nothing to exploit specific features of web publishing technology, does offer some significant advantages, such as: It's timely - information can be made available virtually instantaneously from the time it is generated. It's universally accessible - anyone who needs to get to the data can; there's no need to pre-define a specific group of report recipients. It's dynamic - unlike paper reports, additions and corrections can be made at any time. It provides interactive, random access to data - much more data than could practically fit into a paper report can be provided, with each user getting to select only the portion they want to view. It's environment-friendly - recycling is great, but not using paper at all is even better! This is all well and good, but if all you do is transfer your existing reports from paper to the web, you're missing out on some great opportunities (as well as running the risk that your reports will largely go unread and ignored). By leveraging some of the inherent strengths of web publishing technology, you can enhance the value of the data you present and create a more positive experience for the user. The techniques presented in this paper don't require sophisticated web development tools or the services of a dedicated web application developer. All of the examples that follow are browser independent; they will run on current versions of Netscape and Microsoft browsers. The server scripts, though written using Active Server Pages (hereinafter referred to as ASP) running under Microsoft Internet Information Server, should be relatively easy to adapt to other server scripting technologies. The techniques I will be presenting, roughly in order of increasing complexity, are: 1. Using frame-base pages for report retrieval 2. Exception reporting with embedded hyperlinks 3. Server health reporting using color-coded table cells 4. Server configuration reporting with query capability ENVIRONMENT A little background on our environment: Our performance data repository (I'll refer to it as PDR from here on in) is SAS IT Service Vision running on an HP Unix K430 server with 4 processors and 768 MB of memory. Our NT data collector is NTSMF (Demand Technology) and our Unix data collector is Measureware (Hewlett-Packard). We're currently monitoring about 400 NT servers that we've divided into the following groups (numbers in parenthesis are the number of servers in each group): File servers (54) Print servers (46) Domain Control servers (61) SMS servers (41) Exchange servers (80) Shared Application servers (47) Remote Access servers (16) Lotus Notes servers (14) SAP servers (17) Misc Application servers* (24) * Servers that don't fall into any other categories In the Unix area, we're currently monitoring 22 HP servers and 14 Sun servers. The disk storage requirements for our PDR is about 13 GB (that includes program code, raw data files, temporary storage of report files, etc.). The web site we use for report publishing uses another 2 GB of disk storage. ASSUMPTIONS A couple of basic assumptions I'll be making: 1. That the volume of data in the PDR and the current capabilities of hardware and software are such that dynamic reporting directly from the PDR is not feasible; reports must be pre-generated. There certainly may be situations where this is not true (particularly if detailed application and process level data is not required); in those cases, other techniques that exploit dynamic report generation functionality would likely be substituted for some of the techniques I'm presenting. However, most of the examples presented could still be used effectively. 2. That the reader has a basic understanding of programming principles in general, basic SAS programming skills in particular, and, to a lesser extent, VBScript programming (for the ASP examples only). I will assume a minimal level of expertise in each, and will attempt to explain concepts and terminology that may not be common knowledge. 1. USING FRAME-BASED PAGES FOR REPORT RETRIEVAL When frames were first introduced into html syntax, they spawned a great debate; one side felt they were a great and liberating innovation, and the other side felt they would destroy the "purity" of the web surfing experience. Many zealots even proudly posted "Frame-free web site" banners on their home pages. Over time, frames have gained general acceptance and are now widely used. Whether or not you feel that they are overused and a nuisance, I'd like to suggest that frames are ideally suited for a simple report retrieval application - where one frame can be used to make report selections and a second frame can be used to view report output. A frameset is an html construct that divides a web page into two or more components (frames). In its simplest form, visualize a page split in two (either horizontally (into rows) or vertically (into columns)), with each half containing different content. A frameset statement defines how the page is divided and frame src statements define what content fills each frame. Here's some sample code that defines a frameset: