ALCS_AID v4.0, 2016-03-18

Application Information Document

Document Id: MT-04

ALCS(Automated Location Control System)

Version 4.0, Effective Mar 18, 2016

ALCSApplication Information Document: MT-04 Version 4.0

Document Control Section

Version Number: 4.0

AuthorsRole NameApplication Delivery Manager – IBM US

Long Truong

Application Delivery Manager – IBM RDC

Raja Narayanan

IBM US SME Randy LoefflerRDC Developer Abdul Ashik Khan M

ReviewersRole NameApplication Delivery Manager Raja NarayananApplication Delivery Manager Long TruongIBM US SME Randy Loeffler

Migration Management Team OwnerRole NameMigration Coordinator

IBM Global Services Page 2 of 25


Revision History

Version # Description of Changes Issue Date1.0 Initial Document 05/26/20082.0 Changed as per the reviewed Comments 11/17/20082.1 Reviewed, but no changes 04/24/20092.2 Sec: 4.2 – Client software requirements are strikethrough.

Sec: 5.3 – Application Modules: Source code location update.

09/02/2009

2.3 First quarter review updates 03/09/20102.4 Release History ALCS DCoE Release information

updated.03/12/2010

2.5 Updated as per Review comments 03/22/20102.6 First quarter review updates 04/21/20112.7 ALCS 232351 Release information updated. 11/23/20112.8 Quarterly Updates 12/13/20112.9 Quarterly Updates 07/24/20123.0 ALCS 204340g Release information updated 11/07/20123.1 Sec. 4.3 – New Production Database Server details updated

Sec 4.4 – New Development and Test Server Details updatedSec 4.5 – Unused server details are strikethrough

3.2 Quarterly Updates 06/02/20144.0 Updated RDC manager details, Updated team member

details. Project 278163a Release information updated03/18/2016



Table of Contents

1. OBJECTIVES............................................................................................................................................. 5

2. TERMINOLOGY AND ACRONYMS.......................................................................................................6

3. APPLICATION OVERVIEW.................................................................................................................... 7

4. APPLICATION PLATFORM.................................................................................................................... 8

5. APPLICATION STRUCTURE................................................................................................................10

5.1 DATA FLOW............................................................................................................................................ 105.1 FLOW EXPLAINED................................................................................................................................... 125.2 APPLICATION MODULES.......................................................................................................................... 13

6. DATABASES AND FILES....................................................................................................................... 14

6.1 TABLES USED......................................................................................................................................... 146.2 INTERNAL FILES...................................................................................................................................... 146.3 EXTERNAL SYSTEM INTERFACES.............................................................................................................. 146.4 VISAN DATA FLOW................................................................................................................................ 156.5 USER INTERFACES................................................................................................................................... 19

7. APPLICATION HISTORY...................................................................................................................... 21

7.1 TYPICAL PROBLEMS................................................................................................................................ 217.2 RELEASE HISTORY.................................................................................................................................. 217.3 MAINTENANCE HISTORY......................................................................................................................... 23

8. REFERENCE DOCUMENTS.................................................................................................................. 24

APPENDIX A: JOINT SYSTEM TEST (JST).................................................................................................25



1. OBJECTIVES

The objective of the Application Information Document (AID) is to provide members of the delivery team with an overview of the ALCS application. The AID describes the function of the application, the structure of the applications, the application configuration and the technical environment. This document will refer to any existing related documentation.

The AID will be used in conjunction with the Application Support Control Plan (ASCP) to support the application.

The delivery team will keep the AID current throughout the life of the ALCS application.



2. TERMINOLOGY AND ACRONYMS

Acronyms and terminology specifically used in this document are described below. Other acronyms commonly used can be found in the ASCP.

No.

Terminology / Acronyms

Definition

1 ALCS Automated Location Control System

2 AID Application Information Document

3 ASCP Application Support Control Plan

4 ADM Application Development and Maintenance

5 PLR Plant Location Record

6 DA Distribution Area

7 VISAN Visual Analysis of Network

8 EGIS Extended Geographic Information System

9 WFA Work Force Automation

10 WCC Wire center code

11 Lat Latitude

12 Long Longitude

13 GIS Geographic Information System

14 OCC One call center



3. APPLICATION OVERVIEW

The purpose of the ALCS or Automated Location Control System is to develop a permanent process for Cable Locate that is to be implemented and supported across the SBC enterprise. The application deals with locating buried facilities at a specified location identified by the customer / excavator. Such requests are received by the One Call Centers and are called as tickets. The One Call Centers pass the ticket information to various utility companies, of which SBC is one. The tickets thus received are scrutinized with the aid of various ALCS application components. ALCS mainly comprises of the following three components which further comprise of various sub-components:

1. Ticket receipt/storage/archive tool.

2. Buried Facility locator/identifier tool.

3. Management reporting tool.

Business Overview:The SBC’s network being laid underground or aerial is the costly assets that need to be protected from damage. Any damage to the network assets like Copper cables/Fiber cables/Conduits/Aerial cables will cause a huge loss to the network infrastructure of SBC. In order to prevent the assets from damages that can be caused due to some digging by some other service providers, the ALCS application was developed. This application receives the tickets from the One Call Centers and checks the spatial database to locate the assets that are being deployed in that particular dig site. If an asset is being found in that particular dig site, then it will be marked by the Out Side Plant engineers, so that the digging contractors can dig carefully to avoid damage of the assets. As lot of tickets will come from the One Call Center, the application has an automated process of identifying the dig site and clearing the tickets based on the parameters that was set.

Business Context ALCS is an application in which user can interact with many sub applications. It looks like a table with the ability to sort and arrange data within the columns. The tickets from OCC are processed and stored in the database by the ALCS background processes before manual screening by screeners in ALCS Facility Viewer. As lot of tickets will come from the One Call Center, the application has an automated process of identifying the dig site and clearing the tickets based on the parameters that are set.

Type of Function: Damage Prevention – Construction & Engineering

Type of Service: Damage Prevention for AT&T - SBC

Type of customer: Damage prevention managers, NDC - Screeners.

Users of Application: West and Southwest NDC and Damage Prevention Managers



4. APPLICATION PLATFORM

Software detailsSl. No

Software Details (Name, Version)

Type (IDE/DB/CM/Debu

g /Middleware etc)

License and Vendor contract

details

Comments (Known issues, product registration id)

External Community/Forum

Links

1 Oracle Database 11g Enterprise

Edition

DB Oracle Corporation

2 Oracle Java 6.x Programming Lang Oracle

3 PERL 5.x Programming Lang GNU.

4 Artix Programming Lang Iona Artix

5 Redhat Enterprise Linux

Operating system RedHat

6 Websphere Application

server

Application server IBM

7 IBM HTTP Server

Web server IBM

8 Struts 2.x Framework Apache

9 SFTP Network Software Microsoft Corporation

Hardware Details on different environments

Production Environment

Sl. No. Machine Name IP OS

details

Web server/App Server

List of soft wares in the Machine (with Version Info)

1 tlpd146.dadc.sbc.com 155.179.137.86 Linux Websphere JDK 1.6,Struts,Oracle,Websphere

2 slpd238.sddc.sbc.com 135.161.166.148 Linux Websphere JDK 1.6,Struts,Oracle,Websphere

Production Database server


details



1 tlpi135.dadc.sbc.com 135.31.225.95 Linux DB server Oracle2 slpi208.sddc.sbc.com 135.165.72.137 Linux DB server Oracle



System Testing


details



1hldv0216.hydc.sbc.com 130.4.148.163 Linux Websphere

JDK 1.6,Struts,Oracle,Websphere

2hldv0215.hydc.sbc.com 130.4.148.160 Linux Websphere

JDK 1.6,Struts,Oracle,Websphere

VISAN Production Server

Sl. No. Machine Name IP OS details Web server/App Server


1 zlpv9427.vci.att.com 130.6.37.178 Linux ArcGIS ESRI ArcGIS

2 zlpv9426.vci.att.com 130.6.37.179 Linux ArcGIS ESRI ArcGIS

3 zlpv0131.vci.att.com 130.6.36.120 Linux Database Oracle

VISAN Development Server


details



1 zltv9446.vci.att.com 130.6.38.86 Linux ArcGIS ESRI ArcGIS



5. APPLICATION STRUCTURE

5.1 Data Flow





5.2 Flow Explained

The CleClient will read the ALCS-KANA mailbox and insert the ticket into UNPARSEDDATA table.

The ClParser is be responsible for parsing the OCC ticket information into a format understandable by the ALCS database. ClParser will access the UNPARSEDDATA table and retrieve the oldest row whose PARSED column is equal to 'N'. ClParser will format the raw data and write to the specific fields in the TICKET table and other LSAT data tables. ClParser will set the parsed column to 'Y' and continue.

There are 8 parsers in ALCS – One for each one call center.1. ClParserAR – Arkansas Ticket Parser 2. ClParserCH - Chicago3. ClParserUSAS – USA South4. ClParserUSAN – USA North5. ClParserTexas - Texas6. ClParserMO - Missouri7. ClParserKS - Kansas8. ClParserOK – Oklahoma

The ClCoder program will be responsible for geo-coding the dig locations provided on the OCC ticket. ClCoder will access the TICKET table directly to get the OCC dig site info and will retrieve the pertinent information (e.g. dig address and/or intersection) one record at a time. The information is sent to the VISAN Geo Coder application and the dig-site lat/long is determined. ClCoder will then populate the TKT_AUTO_SCREEN_INFO table with the geo-coded lat/long and success/failure statuses.

The ClWCidentifier program will be responsible to determine the probable wire center that the dig-site may fall under. ClWCidentifier program will send the geo-coded lat/long for each ticket (from the TKT_AUTO_SCREEN_INFO table) to the VisAN databases and will retrieve the possible wire center NPANNX. This info is then stored in the TKT_AUTO_SCREEN_INFO table.

The SplProcessor program is responsible for checking if the locate request satisfies the preset special processing conditions and processes them accordingly.

The FacIdentifier program is responsible for checking if any aerial/buried/high profile facilities are present within the buffer radius and updates the HIPR_STATUS table with the facility details.

Auto-Screener updates LSAT ALCS database after processing and sets TKT_AUTO_SCREENED_STATUS to 'AERIAL ONLY' or 'CONFLICT' or 'NO CONFLICT' depending upon the facilities found in the buffer region.

Auto-Assigner Tickets which are SCREENED will be processed further by Auto-Assign feature and decides on whom the ticket has to be assigned.

CommSystem decides on the communication mechanism and decides whether the ticket has to be sent to EDGE (DispatchOutManager) or Vendor (VendorDispatch)



DispatchOutManager picks up tickets for EDGE converted wire centers and assigns the tickets to EGDE/FORCE.

VendorDispatch picks up tickets and assigns the tickets to UTI.

The ConflictNotifier program sends mail notification to the Excavator via e-mail when a locate request is within the area of a Central Office and / or a high profile facility.

5.3 Application Modules

ALCS has a number of modules to perform its complete functionality. They have been listed with their names below.

Program Name Functional Description Execution Frequency

Location of Source Code

ALCS Batch Processing Ticket processing modules that process One call center tickets and send them to vendors – EDGE, USIC, UTI and ArkUPS

Daily – 24x7

ALCS Client ALCS Front End where the processed tickets will be visible in the GUI

Daily – 24x7

Facility Viewer The digsite of the one call center ticket will be displayed in map form in ALCS

Daily – 24x7

ALCS Reports The Reporting functionality of ALCS where Audit reports of one call centers will be used by the client

Daily – 24x7



6. DATABASES AND FILES

6.1 Tables Used

ALCS uses 5 important tables for each and every batch processing of one call center tickets.

Tables DescriptionUNPARSEDDATA Raw ticket is stored here

TICKETParsed tickets are stored here - it contains all information of the ticket

TKT_AUTO_SCREEN_INFO

Latitude, longitude, NPANNX, DA information of ticket

HIPR_STATUS High Profile Information of the ticket

MESSAGEThe vendor to whom the ticket has to be sent

6.2 Internal Files

ALCS using several type of files from the configuring the application components to exchange the data between the various components of the application. The file types used across the application are listed below.

File Name Purpose/Description.properties Configuration property files.sql Contain extraction query scripts for audit scripts.sh Shell scripts for audit scripts, processing.ear Front End business logic files.jar Source code for handling business logic

6.3 External System Interfaces

Description of the external interfaces.

Application File Name Functional Description

EDGE ALCS sends ticket processing outputs for some regions to EDGE and it flows through FORCE and GCAS

VISAN ALCS queries VisAN to get spatial information about the digsite. ALCS also gets facility information of the digsite.



EGIS ALCS queries EGIS for Land base information for displaying on the map in front End

CENET Employees.sh ALCS Connects to CENET DB and loads all the user information into ALCS.EMPLOYEES tables. This data is refreshed once very month

UTI/USIC /ArkUPS ALCS sends ticket processing information to external vendors outside AT&T

6.4 VisAN Data flow

CLCODER:

CLWCIDENTIFIER:



FACIDENTIFIER:

ALCS MAP SERVICE:



ALCS FRONT END:





6.5 User Interfaces

The below document contains the list of user interfaces available in ALCS.

The ALCS GUI Landing page is as follows.

The below is the ALCS Facility Viewer,

The below is the ALCS Reports landing page,





7. APPLICATION HISTORY

7.1 Typical ProblemsALCS users cannot login GUIALCS Digsite is not plotted on the correct pointFacility Identifier does not process and throws errorClWCidentifier does not process and throws errorParsing of tickets failedALCS map does not show up in the front endCloseouts does not process correctly

7.2 Release History

VERSION NUMBER

CHANGE REQUEST NUMBER

REVISION DATE

AUTHOR SUMMARY OF CHANGE

0.01 40006877 02/25/2005 Srikanth Pedagandham Michelle Skaggs

Subbalakshmy Ramasubramanian

Initial version

1.00 03/10/2005 Sri Pedagandham IT Peer review complete. Submitted for Client review and

approval.

2.00 3/17/2005 Sri Pedagandham Baselined with Client approval.

2.01 40006877 06/30/2005 Subbalakshmy Ramasubramanian

Included Reports and Updated all the modules with respect to the

CR's


Updated Phase 1 changes and Phase 2 requirements.


Approved and Baselined for phase 2

3.01 40006877 05/09/2006 Karthik Murugesan Enhancements after phase 2 period



4.0 40006877 05/24/2006 Karthik Murugesan Baselined and Approved

ALCS LSR12 Release: (Released on Feb 20 th 2010)

Following enhancements were made to ALCS.

1. Create interface to support a transition to EDGE/FORCE from WFA/DO to build, update and cancel dispatch requests and return completion status.ALCS will create an interface utilizing web services to support the transfer of data from ALCS to EDGE that is required to build, update and cancel dispatch requests in FORCE.

2. ALCS will receive ticket status data from EDGE each hour via FTP as required to complete locate ticket status in ALCS

3. Add a new table in ALCS to tie OCC ticket numbers to FORCE work request ID.

ALCS 232351a Release: (Released on Jan-2- 2011)


1. TX parser code was enhanced to parse USAS and USAN tickets. Pattern to parse USAS and USAN tickets was changed to accommodate the new data that was provided by these OCCs.

ALCS 232351 Release: (Released on Sep-09- 2011)


1. New notification process added to notify the Excavator via e-mail when a locate request is within the area of a Central Office and / or a high profile facility.

2. Active Positive Response is provided back to the One Call Center for completion of locate request in accordance with California and Nevada legal requirements.

3. Universal parser (ClParser) created to handle all State ticket formats. CH, MO, USAN, USAS, TX, KS are supported. Version number included along with OCC ticket number for USAN and NV tickets.

4. After hour locate request created in ALCS from other utilities without going through the One Call Center and mechanically replying back to the originator if “no conflict”.

5. LSAT thick client converted to web based client and called ALCS.6. Digital pictures are displayed for each ticket sent by UTI in Ticket Detail Screen.7. Redesign of redistribution mapping screen8. Find/filter screens in LSAT enhanced to include search and display by wire center9. New report called Ticket Info added to ALCS Reporting tool

ALCS 204340g Release: (Released on Oct-20- 2012)


1. ALCS will support the identified Force 10.4 web service as they relate to the following four updated EDGE Client Web Services:

ForceCreateGenericMaintenanceAckForceUpdateGenericMaintenanceAckForceCancelCompleteGenericMaintenanceAckRetrieveEdgeRoutingData



2. ALCS will support multiple versions of EDGE WSDLs by passing the Web Services Version Number to EDGE for each of the four EDGE web services utilized by ALCS.

ALCS – 278163a (Jan-2016)Following enhancements were made as a part of this release

1. DA_PSA layers in VisAN was split into DA layer and PSA layer separately2. ClWCidentifier was modified to read DA, PSA, NPANNX, WFA_WCCODE from VisAN using

SOE (Server Object Extension)3. ALCS front end was migrated from ArcIMS to ArcGIS and hosted on VisAN server.4. ALCS geo coding was migrated from Address broker to VisAN geo coder

7.3 Maintenance History



8. REFERENCE DOCUMENTS

The Project Library consists of documents that can be provided further information about the application. Documents related to the ALCS application includes:

Document Name Document Location Version Number

Last Update(YY/MM/DD)

ALCS ASCP

ALCS SCM Plan



APPENDIX A: JOINT SYSTEM TEST (JST)

Not Applicable
