HEDONIC PATH FINDER SYSTEM (HPFS)

INTRODUCTION
Purpose
The Hedonic Path Finder System (HPFS) is designed to address the information needs of the Prohibition and Excise Department (P &E Dept), Government of Andhra Pradesh. Specifically, it is designed to provide storm data in a variety of ways, in relationship to the departments P&E Dept. GOAP, Distiller, Depot and the Vendor network and operational boundaries and with respect to governmental bounds and customer-centric views. HPFS will contain mainly the following modules

Distiller:
Has to get unique serial number to be assigned for bottles /cans from Excise Department and store them. Has to identify Batch number and serializing them for Barcode data for bottles Has to check the order entry in inventory. Has to create delivery order. Has to get the 2D Barcode/ ID Linear Barcode scan numbers for storing following details to avoiding manual counting of loaded cases. 1. Counting number of cases loaded 2. Case quantity 3. Reduce count of stock in godown Has to generate a n order of creation permit which has to dispatch for every truck and Depot. Has to store the exit time of truck. Has to generate an alert automatically by system to Distiller/Depot.

Supervisor:
Has to store the details of Date of receipt of Order, Order Number, Depot Name and Address, Liquor type, grade and quantity. Has to get Confirmation from distiller to create delivery order for truck to load. Has to verify the information that is fed automatically in to the system.

Depot Supervisor:
Has to verify the documents given by driver and the system has to check with the document notice generated by Distiller. Than after delivery in the warehouse again do the scan of 2D Barcode/ID Linear Barcode to get confirmation of the cases received ( To cross check whether the cases delivered in Distiller are equal to the cases received in warehouse). If any discrepancy happens he has to separate it. Has to generate the cancellation of permit after completing the shipment and send notification to Deopt.

TECHNOLOGY ARCHITECTURE

Servers
Server Systems: Servers: O/S: 2 X Intel 4 x 3.8 GHz CPU, 4 GB Ram, 420 GB disk each Windows Server 2003, Standard Edition

WebSphere Application Server: Model: 7248/43P 4 x 375 MHz CPU, 4 GB RAM , 120 GB Disk

DEVELOPMENT TOOLS
The application will be developed as a web application that will be deployed to WebSphere Application Servers.

Java development will occur utilizing the IBM WebSphere Studio Application Developer v 5.1.2 The application will use Struts as the MVC framework for the web application. JavaScript for client side validation Jsp, HTML, XSLT, DHTML for client tier purpose Hibernate and JDBC for connectivity to database Stored Procedures using Oracle 10g PL/SQL development will occur utilizing the Oracle DBMS data server 9i (or higher) ETL development will occur utilizing Informatica Powercenter 7.x (or higher) Cognos ReportNet 7 MR3 for Report authoring. Framework Manager for Metadata modeling.

APPLICATION LOGICAL DESIGN

HPFS is based on three-tier architecture.

The logical design is a matrix of managers, modules and components within the architectural tiers of HPFS. The application logical design section of the high level design document for HPFS will be separated out by tiers. A manager is the end to end functionality that implements a section of the HPFS portal. Within a manager, the document will describe standards and relationships of each module and their components for a given tier. A module is a logical grouping of components for a given manager. Components are a grouping of functions that interact with the application's state, parameters, business logic, services, data structure and presentation logic for a given module.

Managers include: Event Manager ETR Manager Spatial Viewer Manager Administration Manager Configuration Manager Report Manager

Client Tier
The HPFS portal will need to utilize client tier web technologies to provide rich web client functionality as well as help reduce the number of transactions that are sent back to the application server for information. Some AJAX type framework may be necessary to provide this functionality. Web technologies include but are not limited to; JSP, JavaScript, XSLT, XML, HTML and DHTML. The client-side managers, modules, and components are responsible for the general control and interaction of the HPFS Portal. The client tier will be designed in such a way that it will not force the entire page to refresh when a piece of functionality is executed. At the client tier, modules and components will take into consideration: Validation of the user input before it is sent to the server Dynamically making calls to the server in the background and update the application Keep track of state information Session Timeout tracking Automatic log out Keep track of client-side response times (This will help determine how the system is performing at the client level)

Application Server Tier

The Application Server Tier consists of three application servers: Web Applications Server (WebSphere) Report Net Server (Cognos.)

Event Manager
Event Manager is expected to provide the following functions Create, Update and Delete Events Display Events Create, Update and Remove Affected Network Display Affected Network Update Ticket Type Create, update and remove Workbase

The Event Manager will have the following modules:

Event Core Module

This module will contain the following components: Event Creation Component Event Update Component Event Delete Component Here are details of each component:

Event Creation Component

This component will create an empty event page where the user can enter the event details. The component will validate the data and create a new event in the database. It will notify the user of the successful event creation.

Event Update Component

This component will display an event details page. The user will be able to update the event page and save it. The component will validate the user input and save it to the database. The user will notified of the successful update.

Event Delete Component

This component will display an event details page. The user will be able to delete the page and save it. The component will validate the delete operation and save it to the database. The user will be notified of the successful event deletion.

Event Summary Display Module

This module displays the details for the event, Affected Network and Workbases. Since there are no business or technical requirements on the level of security for viewing the data, and because OCS is to be hosted inside the firewall, all OCS users will be able to view the data. This module in turn will call individual display services to get the required data for display to the user. This module will have the following components: Event Details Display: This component calls the database and gets all the event details such as event name, event status, event description Affected Network Display: This component calls the database and gets all the Affected Network details Workbases Display: This component will call the database and get the all active Workbases and prepares the presentation to the user Ticket Types Display: This component calls the database and gets all ticket types. It prepares the necessary view code for the browser for display. Subcounty Display: This component gets the Subcounty polygons defined for the event and displays them to the user (NOTE: this is a description of the Subcounty information and not the graphics of the Subcounty)

Affected Network Module

This module will contain the following components to create, update, delete affected network and update the ticket types:

Affected Network Creation Component:

This component calls the database and creates an Affected Network. Default workbases will be created based on the affected network.

Affected Network Update Component:

This component calls the database and updates the Affected Network details. Related workbases will be created/modified based on the existing and affected network.

Affected Network removal Component:

This component calls the database and removes the Affected Network from the event. Related workbases will be created/updated/closed based on the existing and affected network.

Update Ticket Type Component

This component sets the criteria for capturing or tagging the tickets for an event. This provides the following services: This displays the Ticket types and their start and end times to the user. The user will be able to update the dates The component will validate the data The user will be able to save the update The user will be notified of the update

Workbase Module
This module will contain the following components: Workbase Creation Component Workbase Update Component Workbase Closing Component

Workbase Creation Component

This component will provide the following functions: o Display the list of feeders and substations affected by a specific event. o The user will be able to select a subset of feeders and substations from the above list and create a Workbase. o The component will validate the data o The user will be notified of successful Workbase creation.

Workbase Update Component

This component provides the following services/functions: o This component will display the list of feeders and substations that is managed by a specific Workbase. o The user will be able to add a set of feeders and substations to the Workbase from the list of feeders and substations impacted by an event. o Similarly, they will be able to remove a set of feeders and substations from the Workbase. The removed feeders will be added to an unassigned list where they can be assigned to another Workbase o The user will be notified of successful Workbase update.

Workbase Closing Component

o o o o This component will display the list of feeders and substations that is managed by a specific Workbase. The user should be able to remove a set of feeders and substations from the Workbase. The removed feeders will be added to an unassigned list where they can be assigned to another Workbase or to the regular service center. Once all feeders and substations are removed, the user will be able to close the Workbase The user will be notified of successful closing of the Workbase.

Database Tier
The database tier consists of two parts - Oracle objects (such as tables, views, and, materialized views) and a set of procedures and ETL to load data into these objects. The development of the database tier will utilize

Oracle 10g using PL/SQL, Java for Stored Procedures Informatica Powercenter 7.x (or higher) for ETL development

A logical data model for HPFS database with entities, attributes, relationships and other metadata is maintained in ERwin model mart. Complete set of attributes and physical implementation will be done during detailed design. The data model consists of three parts. The current transactional data related to event definitions, ETR management and near real-time outage information is represented in relational form. The changes in events, affected network, ETRs are modeled in dimensional form to provide (short term) historical querying. Spatial Data Engine (SDE) is installed in the OCS database to enable spatial processing. Entities such as FPL assets have spatial attributes, which will be implemented through SDE procedures. A number of views are defined to support queries for thematic display, summary tables, and interfaces. Data is loaded into Oracle objects based on their source. TCMS real time data processed using Informatica ETL in RDM cycle is further updated into the OCS schema using PL/SQL procedures. Reference tables from data warehouse (such as customer, premise, device, device hierarchy, and service area) are updated using combination of Informatica ETL for tabular data and SDE procedures for spatial data. Procedures are provided for updating tables for Event and ETR management as well as accessing data from interfaces, themes and summary tables. A high level entity relationship diagram for the below modules will be included in the Data Model Design section. The detailed logical data model will be provided in the appendix. Database tier will consist of the following managers;

Event Manager
The event and ETR management functions include the ability to: - Define events - Define affected areas for an event based on static and dynamic boundaries using attributes of devices and premises - Define outage criteria in terms of ticket types in the affected area - Define Workbases based on substation and feeders - Define estimated times to restore based on boundaries using attributes of devices and premises, - Associate defined custom polygon to event - Approve defined estimated time to restore for further processing - Administer the application by defining users, roles and privileges, system parameters and profiles.

Event

Affected Network

Outage Criteria

Workbase

Feeder

Custom Polygon

Areas Estimated Restore Time

Area Definition

Users

Roles

Event Core Module

The event core module is responsible for providing database services to the application server tier. The following components/services will be provided but not limited to: Add event Update event List event Add affected network Update affected network List feeders by attributes(County, management area etc) List feeders in the affected network List overlapping affected network (feeders in multiple affected area for same event) List ticket types Update start and end times for ticket types List feeders affected by event Add Workbase Update Workbase

ETR Manager ETR Core Module

The ETR Core Module is responsible for providing database services to the application server tier. The following components/services will be provided but not limited to: Add event ETR Update event ETR Add county ETR Update county ETR Add Subcounty ETR Update Subcounty ETR

Spatial Viewer Manager

The database Spatial Viewer Manager will contain the following modules:

Summary Module
The Summary Module is responsible for providing database services to the application server tier. The following components/services will be provided but not limited to: Boundary summary information based on event, boundary hierarchy and page Thematic summary information based on event, boundary hierarchy and page

Query Module
The Query Module is responsible for providing database services to the application server tier. The following components/services will be provided but not limited to: Detail ticket summary information based on search criteria (ticket id, device id, etc.) Detail customer summary information based on search criteria (phone number, device id, address, etc.)

Spatial Layer Module

The Spatial Layer Module is not a set of services rather a place holder of where the spatial server module (ArcIMS) will access spatial information for mapping purposes. The following spatial components will construct the maps based on the Spatial Viewer Configuration Module. The following components (layers) will be provided but not limited to: Spatial views o Thematics points o Event boundaries o Workbase boundaries o ETR boundaries Landbase layers

Administration Manager
The database Administration Manager will contain the following modules:

Administration Core Module

The Administration Core Module is responsible for providing database services to the application server tier. The following components/services will be provided but not limited to: Add role Modify role Remove role List roles Add user Modify user (roles) List users Create audit history (for a user and session id) List custom polygon (Subcounty) Associate custom polygon to event Convert custom polygon SDE data to device list

Configure ETR strata Configure Length of outage ranges

Configuration Manager
Spatial Viewer Control Component
Details around this component having the capabilities of being dynamically updated and refreshed will be determined in detail design

Report Manager
This section describes data model to support thematic views, summary tables, reports and interface queries. To produce a consistent view of data during an update cycle, a master control table is created. The data being updated during the cycle will be flagged and queries referencing the master control table will get data consistent with a completed cycle. The outage information will be made available in the form of reports. A Cognos Report Net data model needs to be built for creating reports and ad-hoc queries. There are about fifteen medium complexity reports to be developed during this phase as listed in requirement. This will be further developed in detailed design. A set of high performance queries related to specific premise to be used by interfaces will be developed during detailed design.