Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 2001


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997 |  
Sessions

A tangled web of pure opportunity

Directions for data

Forging the future

How they did it - and what's next

Integrating work management

Mobile solutions- taking it to the streets

Operations support

People make the difference

Systems architecture

The local government perspective

Tying IT all together

Vertical applications


GITA 2001


A Tangled Web of Pure Opportunity

OMS for the Masses - A Web-based Approach


Project Background
Project initiation came about from a convergence of events. As stated previously, GPU had a need for new remote OMS functionality for the people in the district offices. BC Hydro, an electric utility in British Columbia, Canada, had the same need and had developed a web-based application to satisfy some of their remote OMS needs. With some negotiation, GPU was able to procure the application and use it as a starting point for their OMS development. Without this head start, the application would never have been implemented on time.

GPU had a very aggressive schedule for project implementation. Eight weeks from conception to going live - including a week for training. Program requirements needed to be determined, final functionality worked out, a team formed, and a lot of arm-twisting in order to get the team “buy-in” on the schedule. Surprisingly, the schedule was met and the system was ready for implementation on time. This would not have happened without a lot of hard work and dedication from the entire team.

GPU required a tool for remote users to monitor, update and close-out OMS projects. The tool needed to be both simple, yet provide functionality as a work management tool for local storm management. Also, the tool design and ultimate integration was to be consistent with GPUs organizational philosophy of local accountability for performance.

Smallworld was selected to co-develop the software in conjunction with GPUs IT staff. The tools needed to be “supported technology” rather than developed and supported in-house. Following development, the software would be piloted to insure performance prior to full rollout in the 59 operating districts.

Project Description

Technology & Architecture
As we already had a working application as our starting point and the schedule was very aggressive, the technologies to be used for the web application, now called PowerOn Remote, were essentially pre-selected for us.

The application is written as an Active Server Pages (ASP) application. ASP is a Microsoft server-side technology that allows web pages to be created dynamically by running a script (usually VBScript).

The traditional interaction between client browser and web server is:
  1. A request is made from the client browser (i.e. Internet Explorer or Netscape) for a new web page (i.e. by following a link).
  2. The client browser locates the web server (i.e. gita.org).
  3. The web server locates the page requested and sends it to the browser.
  4. The browser renders the HTML for viewing and interaction.
An ASP application follows the same steps, except that instead of requesting an HTML page, the client requests an ASP page. Step three is different in that the web server identifies the file as an ASP file, processes the scripting in the file, and generates the HTML which is sent to the client. ASP is a relatively easy way to produce dynamic, data-driven content for web pages. ASP also provides straightforward access to external databases via its ActiveX Data Objects (ADO) component. ADO is used within ASP scripting to connect to the Oracle OMS database, retrieve the required information, and close the connection. It uses the underlying ODBC connection for its database access. All of the server-side scripting in the ASP code was written in VBScript. Client side data validation and reformatting routines were written in JavaScript.

The previous paragraph described the technologies used to deliver OMS data via web browsers. However, this is only one-half of the story. The real value of the application is the remote updating capability. Updating the OMS database using dispatching and restoration functions required a different set of tools. The OMS itself does not directly update its database tables via ODBC; it uses the GIS environment to perform updates to the database. The decision was made to use the new Smallworld Internet Application Server (SIAS) application as to mechanism to apply updates to the OMS database. This allowed us to call the same functions with the same data as the full-featured OMS.

The following diagram illustrates the technical architecture of the OMS system at GPU. The bottom area illustrates the standard OMS setup and its interaction with the OMS databases. The top area shows the new web-based application and its database interaction.


Page 2 of 7
| Previous | Next |

Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book