Herramienta web para la gestión de comandos en las centrales telefónicas
Autor: Gómez Alzate, Eric Addison
Asesor: Branch Bedoya, John William (Thesis advisor)
Fecha: 2007
Programa: Bogotá - Medicina -Fisioterapia
Facultad: Facultad de Medicina

Resumen: REMA es una aplicación Web diseñada para administrar todos los movimientos en la configuración de los abonados de servicio telefónico pertenecientes a la red de UNE EPM Telecomunicaciones.  En la actualidad UNE cuenta con tres tipos de centrales telefónicas digitales (FETEX-150, AXE-10, NEAX-61S), cada una de estas centrales telefónicas maneja lenguajes diferentes y la forma de extracción de reportes es a través de comandos, para los usuarios que requieren la información no es fácil interpretar los comandos y para traducirlos al lenguaje común deben realizar un requerimiento al operador de cada central, éste trámite puede llegar a tardar hasta 15 días, dado que los operadores de las centrales tienen otras actividades prioritarias dentro de su labor.  Con el fin de dar solución a éste problema nace el sistema REMA, el cual administra todos los comandos de abonados de los 3 tipos de central, proporcionando al usuario final la información en un lenguaje unificado y amigable. Con éste desarrollo se optimiza el tiempo, debido a que los usuarios interesados en la información pueden obtener respuesta inmediata al consultar la Web, ésta información es de fácil comprensión para cualquier usuario y por lo tanto no requiere la intervención de los operadores de la central para la comprensión de comandos.

Informe Final de Práctica
Herramienta Web Para la Gestión de Comandos en las Centrales
Telefónicas
Eric Addison Gómez Alzate
Trabajo presentado como requisito parcial para optar al título de
Ingeniero de Sistemas e Informática.
Director
John William Branch
Escuela de Sistemas
Facultad de Minas
Universidad Nacional de Colombia
Sede Medellín
2007TABLA DE CONTENIDO
1. INTRODUCCIÓN 3
1.1 HISTORIA DEL SERVICIO DE TELEFONÍA 3
1.1.1 Central Telefónica manual 3
1.1.2 Central telefónica automática 4
1.1.3 Centrales Digitales 5
1.2 HISTORIA DEL SERVICIO DE TELEFONÍA EN UNE EPM TELECOMUNICACIONES 5
1.2.1 Centrales manuales 5
1.2.2 Centrales Digitales 6
2. MARCO TEÓRICO REFERENCIAL 7
2.1 OBJETIVO GENERAL 7
2.2 OBJETIVOS ESPECÍFICOS 7
2.3 DESCRIPCIÓN DEL PROBLEMA 7
2.4 CENTRALES DE CONMUTACIÓN MANUAL 7
2.5 CENTRALES DE CONMUTACIÓN DIGITAL 8
2.6 CENTRALES DIGITALES 8
2.7 CENTROS DE OPERACIÓN Y MANTENIMIENTO 9
2.8 TIPOS DE CENTRALES TELEFÓNICAS EN UNE EPM TELECOMUNICACIONES 9
3. SOLUCIÓN PROPUESTA 11
3.1 ANÁLISIS 11
3.1.1 Actores y sus roles 11
3.1.1.1 Operador 11
3.1.1.2 Solicitante 11
3.1.1.3 Administrador 11
3.1.2 Problemas y sus causas 12
3.1.3 Procesos del área 12
3.1.3.1 Tabla explicativa de los procesos 13
3.2 DISEÑO 13
3.2.1 Introducción 13
3.2.2 Tecnología 13
3.2.3 Carta de navegación de interfaces 14
3.3 IMPLEMENTACIÓN 15
3.3.1 Módulo seguridad 15
3.3.1.1 Esquema del sistema de autentificación 15
3.3.1.2 Página inicial con el formulario de autentificación 15
3.3.1.3 Control de los datos de autentificación 16
3.3.1.4 Capa de seguridad 17
3.3.1.5 Archivos de la aplicación con acceso restringido 18
3.3.1.6 Salir de la aplicación segura 18
3.3.2 Estructura de la date base REMA 20
13.3.3 Requerimientos para el óptimo funcionamiento de REMA 21
4. MANUAL DE USUARIO 25
4.1 INTRODUCCIÓN 25
4.2 PÁGINAS DEL SISTEMA 25
4.2.1 Página inicial del sitio 25
4.2.2 Página de acceso 26
4.2.3 Páginas usuarios 27
4.2.3.1 Página de consulta 27
4.2.4 Páginas administrador 28
4.2.4.1 Página eliminar registros 28
4.2.4.2 Página cargar manual 29
4.2.4.3 Página ingresar usuarios 30
4.2.4.4 Página eliminar usuarios 31
CONCLUSIONES 32
Trabajo Futuro 33
BIBLIOGRAFÍA 34
21. INTRODUCCIÓN
1.1 HISTORIA DEL SERVICIO DE TELEFONÍA
En el momento que la telefonía empieza a desarrollarse y utilizarse como un servicio
urbano para comunicar varia personas entre sí, se hace necesario establecer algún tipo
de sistema de regulación de las llamadas. Es en ese instante que nacen las centrales
telefónicas de conmutación manual. La primera central se inaugura en 1878 en la
población de New Haven (Estados Unidos).
En esta época la transmisión de la palabra era tan incompleta, que el abonado tenía que
referir al operador de la central el mensaje que había de ser repetido al otro abonado.
En la actualidad, el par de hilos que sale de nuestro teléfono van sobre postes, al aire
libre o subterráneos, recubiertos de aislante, a un edificio donde cientos de hilos
semejantes concurren para la interconexión.
1.1.1 Central Telefónica manual
Las centrales telefónicas manuales eran operadas por telefonistas. Una de estas
telefonistas estaba provista de un receptor y un transmisor, sostenido en su posición
mediante una lámina, quedando así las manos libres. El frente del cuadro estaba
perforado por un gran número de agujeros pequeños llamados "jacks" y al lado de cada
agujero estaba colocada una diminuta lámpara eléctrica. Cada uno de estos agujeros
representaba el final de una línea telefónica. Entre el operador y la cara vertical del
cuadro había un estante estrecho, de donde sobresalían cientos de terminales con la
extremidad de latón. Estos se llamaban "clavijas", e iban unidas a los cabos de cordones
flexibles, de longitud conveniente. Ver figura 1.
3Figura 1. Reverso de un cuadro de distribución telefónica en uso hacia los años 20 [Betancur, 2000]
Cuando un abonado descolgaba su receptor del gancho, brillaba una de las diminutas
lámparas del cuadro, y la telefonista más próxima tomaba una de las clavijas y la
insertaba en el jack adyacente a la lámpara encendida. La lámpara se apagaba, pero al
mismo tiempo se encendía otra en el banco al lado del flexible. La telefonista entonces
cerraba un conmutador situado en el banco o estante que conectaba su teléfono con el
del abonado y decía: "¡Central!" Al recibir el número que se deseaba, la telefonista
tomaba otra clavija, la conectaba bajo el banco a la primera, la insertaba en el jack que
pertenecía al número pedido y apretaba un botón, que hacía sonar el timbre del teléfono
de la persona a quien se llamaba.
1.1.2 Central telefónica automática
El otro tipo de central, cuyo empleo se incrementó luego a medida que los
automatismos fueron reemplazando progresivamente a las operadoras, fue aquella en
que las conexiones que se hacían por medio una máquina automática, que era dirigida
por la persona que hacía la llamada. En lugar de esperar a que la telefonista pregunte el
número que se desea, el abonado, de un modo automático, conectaba su teléfono con el
de cualquier otro abonado haciendo girar una esfera numerada con las cifras sucesivas
del número del teléfono deseado. La máquina automática (ver figura 2) conecta los dos
teléfonos, y el abonado que llama puede entonces hacer sonar directamente el timbre del
teléfono del otro abonado.
Figura 2. Las primeras centrales eléctricas automáticas en uso a comienzos del siglo XX [Betancur, 2000]
41.1.3 Centrales Digitales
A mediados de los años setenta, los ordenadores, un medio que en aquellos años
únicamente era utilizado por el ejército, las universidades y las grandes empresas y
corporaciones multinacionales, empiezan a ser introducidos en las centrales telefónicas
con la misión de regular y controlar su funcionamiento.
Con el surgimiento de las centrales telefónicas de conmutación digital 1 se puedo ganar
rapidez de conexión y asegurarnos la confidencialidad de las llamadas.
1.2 HISTORIA DEL SERVICIO DE TELEFONÍA EN UNE EPM
TELECOMUNICACIONES
1.2.1 Centrales manuales
Las primeras centrales telefónicas que se instalaron en el valle de Aburrá fueron plantas
manuales. Durante las horas diurnas un número creciente de diestras operarias de las
plantas manuales se encargaba de establecer el puente entre los usuarios; en las noches,
cuando la demanda descendía, unos pocos varones las relevaban. A finales de 1923
había 2.237 abonados pertenecientes a los municipios de Medellín y Envigado; se decía
entonces que, con su densidad de tres teléfonos por cada 100 habitantes, la ciudad
estaba a la altura de grandes metrópolis. Al finalizar el decenio, el número de abonados
superaba los cuatro mil, y unas pocas redes ya llegaban a otros municipios vecinos. El
uso del teléfono trajo, para los pocos que podían disponer de él en su residencia,
cambios significativos en las formas de sociabilidad: desaparecieron las tradicionales
tarjetas de visita y los mensajes a través de mandaderos. Y fácilmente se pueden deducir
las ventajas que esta innovación tecnológica reporto al comercio, la industria, la banca y
la industrialización pública.
La extensión del servicio telefónico durante el primer lustro de los años cuarenta se
limitó a copar las 10.000 líneas, capacidad de la primera planta automática. En los diez
años siguientes se le agregaron 19.500 líneas nuevas, la mayoría en la planta central,
aunque se instaló en el occidente, en el barrio La América, a la que siguieron las del
Bosque de la Independencia al norte, y la del Poblado al sur, en los años cincuenta. El
que en el barrio la América se hubiera instalado la segunda central de la cuidad, indica
la rápida urbanización de la otra banda del río, la que se acentuaría cada vez más en los
años siguientes. Así, al momento de su incorporación a las Empresas Públicas de
Medellín, la empresa tenía instaladas 29.500 líneas y atendía a 25.813 suscriptores, con
lo cual alcanzaba una densidad cercana a cinco teléfonos por cada cien habitantes.
En el año de 1960 se extendió este servicio a otros municipios del valle de Aburrá.
Entre 1955 y1969 se había cuadruplicado el número de usuarios de teléfono y se
disponía de 2.400 teléfonos públicos, un permanente de la empresa. La instalación
telefónica ha tenido una demanda muy dinámica en la ciudad y con el transcurrir del
tiempo se ha convertida en un servicio corriente, al que tienen acceso amplios sectores
de la población.
1
Se entiende por conmutación digital la posibilidad de establecer una comunicación entre dos usuarios de
una red telefónica, sin la mediación de una telefonista.
5El interés por la ampliación y modernización de las telecomunicaciones, factor decisivo
para el desarrollo económico y social del mundo actual, es motivo de permanente
preocupación por parte de las Empresas Publicas. En el aspecto cuantitativo, la densidad
telefónica, esto es, el número de teléfono por cada 100 habitantes, coloca a Medellín
entre las ciudades más avanzadas en ese aspecto en América Latina.
1.2.2 Centrales Digitales
En el año de 1977 se instaló la primera central semielectrónica, Villa Hermosa, y tres
años mas tarde la primera central digital de tecnología FETEX. Para mejorar la calidad
del servicio se dio al servicio el centro de control y mantenimiento (COM) que recibe la
señal de alarma cuando se presenta un daño, la analiza, diagnostica la falla y envía el
personal técnico para repararla. A esto se agrega el sistema de monitoreo automático de
la red telefónica presurizada, el cual permite prevenir daños. Se introdujeron, además
nuevos servicios como el discado directo internacional, la facturación automática de las
llamadas nacionales e internacionales, del despertador automático, la transferencia de
llamada, la marcación abreviada y el código secreto para controlar llamadas de larga
distancia.
Dada el dinamismo de este servicio y los numerosos y rápidos cambios, las empresas
deben hacer esfuerzos especiales para responder a las demandas de sus usuarios. Con
ese fin, desde mediados de los ochentas se instalaron cables de fibra óptica para la
interconexión entre las centrales, principalmente las más alejadas del centro de
Medellín, y así garantizar la más alta calidad del servicio telefónico.
62. MARCO TEÓRICO REFERENCIAL
2.1 OBJETIVO GENERAL
Prestar un servicio de consulta automática de los movimientos exitosos referentes a los
abonados que posee en la actualidad UNE EPM telecomunicaciones.
2.2 OBJETIVOS ESPECÍFICOS
• Visualizar, ingresar y generar reportes de la información dinámica
correspondiente a los movimientos de abonado.
• La auditoria del sistema y registros de transacciones diarios.
• Definir la administración de usuarios (Perfiles: usuarios, roles).
• Establecer políticas de seguridad de la aplicación.
• Capacitar el personal que interactúa con el sistema.
2.3 DESCRIPCIÓN DEL PROBLEMA
Los operarios de los COM generan diariamente unos Log’s que contienen toda la
información de los comandos lanzados con el propósito de realizar algún tipo de
movimiento en las cuentas de los abonados.
Estos comandos pueden ser lanzados desde aplicaciones (FENIX), los mismos COM y
centrales telefónicas.
Estos Log’s son almacenados históricamente en carpetas referentes a cada uno de los
años anteriores y hasta la fecha.
Cuando resulta algún tipo de reclamo por parte de los abonados o algún tipo de
anomalía en cuentas. La persona encargada de estos reclamos solicita a algún operador
extraer de los Log’s toda la información correspondiente al abonado en un rango de
fechas en la que se cree que se presento el problema.
El operador para realizar la consulta debe buscar manualmente en el historial de Log’s
toda la información referente a los cambios exitosos realizados al abonado en el rango
de fechas; tarea que puede tardar hasta 8 días en realizarse y puede convertirse en
tediosa por realizarse manualmente.
Posteriormente el operador le envía a la persona que solicito la verificación una especie
de resumen que contiene los movimientos realizador al abonado en el rango de fecha
definido.
2.4 CENTRALES DE CONMUTACIÓN MANUAL
El sistema de funcionamiento de las centralitas es relativamente sencillo. Un dispositivo
llamado conmutador suizo2, muy parecido al utilizado en las centrales telegráficas, es el
que permite interconectar las diversas líneas que están relacionadas; tras solicitar un
abonado a la central, mediante un avisador acústico accionado desde el propio
domicilio, su deseo de realizar una comunicación, la telefonista introducía una clavija
2
Dispositivo que se utilizaba en las instalaciones telegráficas para interconectar las diversas líneas y los
aparatos de operación para cursar el tráfico de telegramas.
7metálica en los orificios de cruce, conectando a las dos personas para que pudieran
hablar.
2.5 CENTRALES DE CONMUTACIÓN DIGITAL
Para establecer un sistema de comunicación telefónica, hay que partir del tráfico que
generan los abonados, de la probabilidad de coincidencia de las llamadas y de la
duración de las comunicaciones. Cuando un abonado descuelga el teléfono, el gancho
cierra el circuito de línea que pone en marcha a aquellos de los catorce buscadores
primeros de su grupo que están libres; en el momento en que uno de estos identifica al
abonado que ha descolgado, se detiene en él y pone en marcha los buscadores segundos
y los del registrador. Al encontrar un registrador libre, le retiene y envía tono de marcar
al abonado.
Cuando marcamos las cifras, éstas transmiten un impulso que queda almacenado en el
registrador. Cada impulso de cada cifra ocupa un relés3 de una cadena de II por cifra. Al
completarse las cadenas, cuyo número dependerá de la cantidad de cifras que tenga el
teléfono al que llamamos, se ponen en marcha los selectores, y cada vez que avanza un
lugar, su elemento de selección envía hacia el registrador un impulso que ocupa uno de
los relés3 libres de la cadena. Una vez se ha seleccionado el objeto de la llamada, se
desconecta el registrador y se envía un tono de llamada o de ocupado, según sea el caso.
Una vez terminada la conversación, se desconectan las líneas y los buscadores y
selectores correspondientes quedan disponibles.
2.6 CENTRALES DIGITALES
Tras la vertiginosa evolución que han sufrido las telecomunicaciones en los últimos
años, ahora nos encontramos con que los ordenadores no sólo hacen la función de
cerebros, sino que regulan todos los órganos de la central telefónica que al mismo
tiempo han visto cómo se ha reducido su tamaño y su consumo energético. La creciente
necesidad de establecer diálogos entre los numerosos y distintos ordenadores que
utilizan los usuarios, llevó a la creación de redes públicas de transmisión de datos. En
este caso, los nodos de la red están regulados por ordenadores altamente especializados.
Actualmente es posible utilizar una sola red para voz y datos.
3 Dispositivo de conmutación activado por señales. En la mayoría de las veces, se utiliza una pequeña
tensión o corriente para conmutar tensiones o corrientes mayores; puede ser de tipo electromecánico o
totalmente electrónico, en cuyo caso carece de partes móviles.
8Figura 3. Central digital [Betancur, 2000]
2.7 CENTROS DE OPERACIÓN Y MANTENIMIENTO
Para la supervisión, operación y mantenimiento, se ubicaron dos terminales remotos de
todas las centrales llamados centros de operación y mantenimiento, COM, logrando una
mejor administración del sistema de telecomunicaciones.
Dentro de las ventajas principales del COM, tenemos: Organización eficiente de las
funciones de operación y mantenimiento, optimización de recursos humanos y técnicos,
almacenamiento y procesamiento de toda la información, atención de las funciones
administrativas.
2.8 TIPOS DE CENTRALES TELEFÓNICAS EN UNE EPM
TELECOMUNICACIONES
El sistema telefónico que actualmente posee UNE EPM Telecomunicaciones esta
conformado por centrales digitales SPC (Stored Program Control, o Control por
programa almacenado). Esto significa que los programas almacenados en un
computador controlan la operación de la central.
Debido a que muchos de los procesos que debe atender una central telefónica son
procesos que se cumplen en tiempo real (por ejemplo cuelgue y descuelgue de cada
aparato telefónico, tasación, etc.), además de muchas otras rutinas de gran complejidad
como son funciones de gestión operación y mantenimiento, se requiere una alta
capacidad de procesamiento y de manejo de grandes volúmenes de datos como
mediciones de trafico o manejo de recursos comunes. Por lo anterior, los procesos de
estas centrales deben ser de gran rendimiento, pero aun así hay casos en los que solo un
procesador no evacua de forma efectiva todas las tareas y procesos que de el dependen.
Por tal razón estas centrales son diseñadas bajo el principio de procesamiento
distribuido; es decir, que pueden soportar varios procesos trabajando al tiempo. Por eso
se llaman centrales multi-proceso. De acuerdo con la configuración de dichas centrales,
cada procesador puede tener las siguientes funciones: señalización, operación y
9mantenimiento, procesamiento de llamadas y control central. Como dato importante
cabe destacar que en estas centrales los equipos de control y de conmutación se
encuentran duplicados como medida de seguridad para que el tráfico cursado no se vea
afectado por posibles fallas.
Las características mencionadas le dan una alta confiabilidad a todo el sistema.
Adicional a lo anterior; las centrales permiten la prestación de una gran diversidad de
servicios de valor agregado, los cuales UNE EPM telecomunicaciones los identifica con
expresiones asociadas a la función que cumple: llamada en espera, despertador
automático, transferencia de llamadas, conferencia tripartita y servicios CLASS como
los son el identificador de llamadas, repique distintivo, memorizador de última llamada
entrante, entre otros. El sistema telecomunicaciones de UNE EPM Telecomunicaciones
cuenta también con la infraestructura necesaria para soportar la Red Digital de Servicios
Integrados (RDSI).
Los tipos de centrales que hoy en día se tienen en el sistema de telecomunicaciones de
UNE son:
Centrales FETEX 150: Fabricadas por la compañía Japonesa Fujitsu, instaladas desde
1982
Centrales AXE 10: Fabricada por la compañía Sueca Ericcson, instaladas desde 1997.
Centrales NEAX 61 Sigma: Fabricada por la compañía Japonesa NEC, instaladas desde
1999.
103. SOLUCIÓN PROPUESTA
Una vez se adquiere un conocimiento claro de la terminología empleada y la forma en
que opera la organización, el siguiente paso es entrar en la fase de análisis, en esta fase
se identifican los usuarios finales de la aplicación y sus respectivas funciones, los
problemas y sus respectivas causas, además de la forma en que se desarrollan los
procesos dentro de la organización; a partir de la información adquirida en la fase de
análisis se pasa luego a la fase de diseño.
En la fase de diseño se identifica los recursos (hardware, software) necesarios para el
desarrollo efectivo del sistema informático.
La última fase que se desarrolla es la fase de implementación, en esta se describe el
esquema de seguridad empleado, la estructura de la base de datos, y los requerimientos
para la puesta en marcha exitosa del sistema informático.
En la última parte de este capitulo, esta el manual de usuario, este manual sirve de guía
para que el usuario final aprenda a utilizar rápidamente el sistema informático y por
ende lo pueda aprovechar al máximo para desarrollar su trabajo.
3.1 ANÁLISIS
3.1.1 Actores y sus roles
3.1.1.1 Operador
Es la persona encargada de generar los log’s de comandos y de mantener un
historial de estos; además en caso de anomalías en las cuentas de los abonados,
es quien se encarga de la extracción manual de la información contenida en los
log’s referentes algún abonado. Además, una vez el sistema entre en
funcionamiento, es el encargado de colocar los log´s en el directorio por defecto
de la aplicación para ser posteriormente cargados en la base de datos de REMA
por el administrador.
3.1.1.2 Solicitante
Es la persona que se encarga de administrar todos los tipos de reclamos
referentes a los abonados que se puedan presentar, y a la vez es quien solicita al
operador la información correspondiente contenida en los log’s.
3.1.1.3 Administrador
Es la persona encargada de la administración del sistema REMA, es decir, es
quien tendrá la labor de realizar la tarea de carga de archivos al sistema y la
administración de los usuarios finales de la aplicación.
113.1.2 Problemas y sus causas
Figura 4. Diagrama que describe los problemas actuales de la organización
3.1.3 Procesos del área
Figura 5. Diagrama que describe la forma en que se hace el proceso actualmente
123.1.3.1 Tabla explicativa de los procesos
Código Descripción Tiempo Fuente
Duración
CR1 El operador busca todos Promedio 8 días Víctor Giraldo
los movimientos del
abonado, en los log’s que
están comprendidos entre
el intervalo del tiempo
definido por el solicitante.
CR2 El operador realiza un 1 día Víctor Giraldo
informe donde le explica al
solicitante en palabras más
formales los comandos
tirados al abonado en ese
rango de fechas.
CR3 El solicitante ya sea por 1 día Luís Fernando Baena
medio telefónico o correo
electrónico, le solicita al
operador buscar todos los
movimientos que haya
tenido un abonado en un
rango de fechas.
CR4 El solicitante almacena los 1 día Gloria Soraida
informes enviados por el
operador en una carpeta de
su equipo personal.
CR5 A partir de la información (3 días) POR DEFINIR Luís Fernando Baena
contenida en el informe, el
solicitante toma la decisión
pertinente.
3.2 DISEÑO
3.2.1 Introducción
Para aliviar el problema de tiempo requerido en la labor de búsqueda de información
sobre el movimiento en las cuentas de los abonados, se hace necesaria la creación del
sistema de consulta REMA, que proporcione la información detallada (fecha, hora,
operador, sistema, comando) en tiempo real, de esta manera se reduce enormemente la
labor de toma de decisiones sobre las cuentas de los abonados.
Además con la creación del sistema, el operador dejaría de realizar la labor de búsqueda
manual, y se evitaría los problemas de información incompleta y errores humanos de
búsqueda.
Para el diseño del sistema de consulta REMA, en este capitulo se menciona todo lo
referente a la tecnología requerida y el árbol de navegación de todas las páginas del
sitio.
3.2.2 Tecnología
REMA es un aplicativo Web, que una vez este en línea suministrará toda la información
referente a los movimientos de abonados; es por ello que se hace necesario para su
13desarrollo un sistema gestor de base de datos y una herramienta para la creación de
paginas Web, a continuación se mencionan estas herramientas de desarrollo.
• SQL SERVER: propiedad de Microsoft (sistema gestor de base de datos)
• FRONTPAGE: propiedad de Microsoft (herramienta para la creación de páginas
Web).
Lenguajes de programación utilizados
• ASP: Active Server Pages
• SQL: Lenguaje de Consulta Estructurado
• HTML: lenguaje de marcación de hipertexto
• JAVASCRIPT: Es un lenguaje interpretado orientado a las páginas Web, con
una sintaxis semejante a la del lenguaje Java.
3.2.3 Carta de navegación de interfaces
143.3 IMPLEMENTACIÓN
3.3.1 Módulo seguridad
3.3.1.1 Esquema del sistema de autentificación
Un sistema de autentificación es un módulo de seguridad para asegurarnos de que el
usuario que visita las páginas es quien dice ser. Por supuesto, sabiendo que ese usuario
es conocido, podremos darle acceso a más aspectos de la página que si fuese un usuario
desconocido.
En la imagen anterior podemos ver el diagrama, que empieza por la página donde se
pide un usuario y contraseña para acceder a la aplicación de acceso restringido.
Los datos de autentificación (usuario y contraseña escritos en la página inicial) se
envían a la página dibujada con línea de puntos, que se encarga de hacer una
comprobación de dichos datos del usuario. Según los datos de autentificación, se
redirecciona al navegador a la página de la aplicación restringida, en caso de que sean
correctos, o a la página donde volver a escribir el usuario/contraseña, en caso de que
sean incorrectos. Esta página la he dibujado con línea de puntos porque no es una
página donde se pare el navegador para nada, sino que sólo es una página de paso que
redirecciona a un sitio u otro dependiendo de los datos que reciba.
La aplicación de acceso restringido, aparte de mostrar las funcionalidades que
queríamos proteger con usuario contraseña, debe de realizar unas comprobaciones de
seguridad para saber si se ha pasado con éxito el proceso de autentificación o si se está
intentando acceder de manera no permitida a esa página. Esta comprobación se ha
dibujado como una capa con color verde más oscuro sobre la página de la aplicación. Si
no se satisface dicha comprobación (el usuario no se ha autentificado correctamente) se
vuelve a la página donde escribir el usuario y la contraseña.
3.3.1.2 Página inicial con el formulario de autentificación
Esta página tiene el formulario de autentificación en el que el visitante debería rellenar
con su usuario y contraseña. Como es la página inicial, la llamaremos index.asp.
15Para pasar a la página inicial el mensaje de que el usuario/contraseña introducidos no
son válidos utilizaremos una variable pasada a través de la URL. La llamaremos
errorusuario, y si contiene la cadena "si" es que estamos recibiendo un error.
El código sería el siguiente:
<%
if request.querystring("errorusuario")<>"si" then
%>
<td colspan="2" align="center" bgcolor=#cccccc>Introduce tu clave de acceso</td>
<%
else
%>
<td colspan="2" align="center" bgcolor=#ff0000><span style="color:ffffff"><b>Datos
incorrectos</b></span></td>
<%
end if
%>
3.3.1.3 Control de los datos de autentificación
Esta página será encargada de decidir si los datos de autentificación son correctos y
actuar en consecuencia.
En la base de datos SION tenemos una lista de usuarios con sus contraseñas
almacenados en la tabla DATOS_PERSONAL. Entonces, en este archivo de control
deberíamos hacer una búsqueda para ver si existe una correspondencia en la base de
datos de ese usuario con esa contraseña
Después de la comprobación podrán pasar dos cosas:
• Si los datos son correctos, definirá una variable de sesión que servirá para saber
que ese visitante ha sido validado correctamente y tiene permiso para acceder a
la aplicación. Además redireccionará al visitante a la página de la aplicación
restringida.
• Si el usuario/contraseña no era correcto, se envía al navegador a la página de
inicio pasando la variable errorusuario=si, que indica que ha habido un error en
la autentificación.
El código se puede ver a continuación:
<%
' miro a ver si la autentificacione es correcta
<%
' miro a ver si la autentificacione es correcta
'creo una sentencia SQL con los datos recibidos
ssql = "select tipo as tip from DATOS_PERSONAL where login='" & request.form("usuario") & "' and
Contraseña='" & request.form("contrasena") & "'"
'conecto y extraigo de la base de datos
set conn = Server.createobject("Adodb.connection")
connString = "DRIVER={SQL Server};SERVER=SION1;Database=SION; uid=; pwd="
conn.open connString
set rs = conn.Execute(ssql)
if (not rs.eof) then
'Como se ha localizado un registro es que ese usuario existe y su contraseña es correcta
'coloco las variables de sesion
16tipo1=rs("tip")
if tipo1=1 or tipo1=2 then
session("autentificado") = "si"
'redirecciono a la página de la aplicación
response.redirect "../consulta.asp"
else
if tipo1=0 then
session("autentificado") = "si"
response.redirect "../Administrar.asp"
else
response.redirect "index.asp?errorusuario=si"
end if
end if
else
response.redirect "index.asp?errorusuario=si"
end if
'cierro la conexion con base de datos
Conn.Close
%>
3.3.1.4 Capa de seguridad
Este archivo, en nuestro caso llamado seguridad.asp, se encargará de dotar seguridad a
toda la aplicación de acceso restringido. La técnica que vamos a utilizar es incluirlo al
principio de todas las páginas que queramos que permitan un acceso restringido.
El módulo de seguridad, incluido al principio de cada archivo, realizará las
comprobaciones oportunas y actuará permitiendo ver el archivo o denegando su
visualización, dependiendo de dichas comprobaciones.
Lo único que hará será comprobar que se ha creado la variable de sesión y contiene el
dato adecuado, lo que significará que el usuario se había autentificado correctamente.
Si no se había autentificado, se redirecciona el navegador a la página que tiene el
formulario de autentificación. Además, salgo del script ASP, con lo que la página deja
de ejecutarse y el resto no se verá. Sólo se mandará al navegador la redirección con lo
que el navegador se moverá al formulario y será imposible ver algo de la página segura.
Si se había autentificado, no se hace nada, de modo que se seguiría ejecutando la página
con el contenido que correspondiese. No hay que olvidar que este archivo de seguridad
se va a ejecutar como un include al principio de todos los archivos de la aplicación
restringida, lo que significa que, si no se hace nada, se seguiría mostrando la página
donde este archivo está incluido.
El código se puede ver a continuación:
<%
Response.Buffer = true
' compruebo que tengo la variable de sesion creada y con el dato correcto
if session("autentificado") <> "si" then
response.redirect "index.asp"
response.end
end if
%>
La sentencia response.buffer = true indica que la salida generada por la página ASP se
guardará en el buffer de IIS mientras que no haya sido procesada toda la página. Nos
17asegura que no se mandará nada al navegador del usuario hasta que se ha decidido si el
contexto en el que se solicita es seguro o no.
response.end detiene el procesamiento de la página. Además devuelve al navegador del
usuario la salida generada hasta ese momento. Si hay código debajo de un response.end
no se ejecuta, pues la página se dio por finalizada.
3.3.1.5 Archivos de la aplicación con acceso restringido
La aplicación con acceso restringido se realizará como cualquier otra aplicación de
ASP, con la salvedad de que, a todos los archivos que queramos proteger, habrá que
incluirles al principio la capa de seguridad, representada por el archivo seguridad.asp.
Como decía, todo en el archivo de la aplicación se realizará como cualquier otro archivo
de ASP, es decir, con sólo incluir el módulo de seguridad, el archivo ya tendrá el acceso
restringido y todo lo demás lo haremos de manera transparente a este estado de
seguridad.
El código de una página segura sería el siguiente:
<!--#include file="seguridad.asp"-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
3.3.1.6 Salir de la aplicación segura
La seguridad de la aplicación se basa en la definición de unas variables de sesión que se
consultan en cada página segura. Puede ocurrir que el usuario entre en la aplicación e
inicie una sesión y que se marche de la aplicación segura sin cerrar la sesión, con lo que
quedaría abierta para que cualquier otra persona pueda acceder a la aplicación volviendo
por el historial de páginas del navegador.
Las sesiones se finalizan solas cuando pasa un determinado tiempo sin recibir nuevas
peticiones, pero no deseamos que antes de que se finalicen se pueda acceder con ese
ordenador a nuestra aplicación restringida.
Parece interesante, pues, ofrecer al visitante la opción de acabar la sesión en cualquier
momento, para asegurarnos en ese caso que la sesión se ha terminado y no se podrá
acceder si no es introduciendo nuevamente el usuario y contraseña correctos.
El archivo en concreto lo único que hace es terminar la sesión asociada a su acceso.
Podemos ver el código a continuación.
<%
session.abandon
%>
<html>
<head>
<title>
Saliendo de la aplicación
</title>
<link rel="STYLESHEET" type="text/css" href="estilo.css">
</head>
<body>
18Gracias por su trabajo en nuestra aplicación segura
<br>
<br>
<a href=index.asp>Volver al formulario de acceso</a>
</body>
</html>
193.3.2 Estructura de la date base REMA4
4 La parte enmarcada en color rojo son las tablas que pertenecen al sistema REMA, las demás hacen parte de un sistema anterior llamado SION
20Las tablas que aparecen en el diagrama anterior encerradas en un cuadro rojo fueron las
que se le agregaron a la base de datos SION existe, estas eran necesarias para el
funcionamiento de REMA ya que son las encargadas de almacenar toda la información
de los comandos de abonados, además la tabla PBX_NEC será la encargada de
almacenar toda la información referente a los pbx’s de la tecnología NEC ya que existen
comandos que se le tiran directamente al equipo del pbx y no al numero de la señal
llamada, es por ello que se hace necesario manejar la información de cada uno de los
pbx’s con su respectivo equipo de línea y central a la cual pertenece.
Además se aprovecharon las tablas:
DATOS_PERSONAL, la cual permite almacenar la información referente a las cuentas
de los usuarios y fue necesario por cuestiones de seguridad agregar una columna de
nombre tipo para diferenciar los usuarios comunes de los administradores, ver tabla:
Valor Significado
0 Administrador
1 Usuario Común1
2 Usuario Común2
Usuario Común1: Este usuario tiene los permisos suficientes para ingresar tanto al
aplicativo SION como al sistema REMA.
Usuario Común2: Este usuario tiene solo el permiso para ingresar al sistema REMA.
SERIES_NUMERACIÓN Esta tabla es importante para el sistema FETEX-150 ya que
por la forma en que esta distribuida la información en el log es necesario consultarla
siempre antes de ingresar un registro en la base de datos, es por ello es de gran
importancia tener las series de numeración actualizadas.
3.3.3 Requerimientos para el óptimo funcionamiento de REMA
• La tabla SERIES_NUMERACION debe mantenerse actualizada.
• Para el sistema FETEX-150 el orden de los archivos es fundamental, los log’s se
deben procesar en orden cronológico; es por ello que se hace necesario para su
buen funcionamiento agregar un índice al inicio del nombre de cada archivo log.
La tabla siguiente ilustra el índice correspondiente para cada uno de los meses
del año:
ÍNDICE MES
01 Enero
02 Febrero
03 Marzo
04 Abril
05 Mayo
06 Junio
07 Julio
08 Agosto
09 Septiembre
10 Octubre
2111 Noviembre
12 Diciembre
Ejemplo: el archivo JA02198.log cambiaria por 1JA02198.log
Esto con el único propósito de que a la hora de cargar los archivos se procesen en orden
cronológico y no suceda lo siguiente:
Para este caso se cargarían primero los archivos de abril y luego los de marzo, y debido
a la estructura del contenido de los log’s de FETEX-150, si se procesas de esta manera,
la información que se almacena en la base de datos podria quedar errónea.
Por esa razón los archivos se deben procesar de la siguiente forma:
Además para diferenciar los log’s de sur y del norte es necesario colocar en el nombre
de estos archivos N:norte, S:SUR; por lo tanto el nombre que deben llevar los archivos
de FETEX-150 debe ser de la siguiente forma.
• Los cookies deben estar activos en el explorador del usuario, debido a que la
aplicación los utiliza para cierta tarea.
22• Es importante a la hora de cargar por primera vez un archivo de FETEX-150 en
la base de datos que exista un registro por defecto en la tabla COMADO,
además es necesario modificar la página validación_FETEX.asp; vemos una
ilustración de cómo se hace.
Registro ingresado por defecto
Luego en la página validación_FETEX.asp en el subproceso inserta registro se debe
apuntar al registro por defecto de la tabla COMANDO y se debe ingresar un número
de abonado por defecto.
sub subinsertar_registro(fech,hor,oper,cen)
'on error resume next
set conn = Server.createobject("Adodb.connection")
connString = "DRIVER={SQL Server};SERVER=SION1;Database=SION; uid=; pwd="
conn.open connString
Danio=mid(fech,1,4) '*
Dmes=mid(fech,6,2) '*--->para insertar la fecha en el formato estandar mes/dia/anio
Ddia=mid(fech,9,2) '*
'if err.Number <> 0 then
'response.write "ERROR: No se logró establecer conexión con la base de datos5"
'err=0
'else
strSQL="SELECT * FROM REGISTRO WHERE fecha='"&Dmes&"/"&Ddia&"/"&Danio&"' and
hora='"&hor&"' and usuario='"&oper&"' and abonado=1111111 and comando_fk=72"
set rs = conn.execute(strSQL)
if rs.EOF then
strSQL="INSERT INTO
REGISTRO(usuario,hora,fecha,accion,comando_fk,sistema,central,abonado)
VALUES('"&oper&"','"&hor&"','"&Dmes&"/"&Ddia&"/"&Danio&"','NULL',72,'FETEX-150','"&cen&"',1111111)"
'---->para poder insertar el registro en la bd debe haber
set rs = conn.execute(strSQL)
'previamente un registro por defecto en las tablas comando
end if
conn.Close
set rs=nothing
set conn=nothing
'end if
end sub
Este registró luego es actualizado por un número de abonado válido perteneciente a esa
central.
• Se recomienda para la tarea de carga de archivos a la base de datos de sistema,
en las tecnologías FETEX-150 y NEAX61-S un máximo de 20 archivos por día,
esto debido a que el tiempo de carga máximo del sistema es de 5 horas, es decir,
la variable Server.ScriptTimeout tiene un valor de 18000 segundos que equivale
a 5 horas; si el proceso de carga tarda mas de ese tiempo estimado no se
completará exitosamente.
• Cuando se inicie la tarea de carga de FETEX-150 por primera vez, se
recomienda no volver a cargar el primer archivo ya que por la forma en que
23están distribuidos los datos en el Log de comandos puede suceder que se
carguen registros no validos en la base de datos.
• Cuando se desee buscar información a cerca de la creación y borrado de líneas
de PBX es necesario realizar la búsqueda por el número de la señal llamada.
244. MANUAL DE USUARIO
4.1 INTRODUCCIÓN
REMA es un sistema de reporte de movimientos de abonados, brinda información de
los movimientos realizados a las cuentas de los abonados, permite exportar la
información consultada, además proporciona diferentes tipos de consulta que le
permiten al usuario depurar la información que se requiera.
Este manual pretende enseñar al usuario final el funcionamiento y la navegabilidad de
la herramienta, con el propósito de que pueda aprovecharla al máximo y le sirva de
gran ayuda en su labor diaria.
A continuación de explicarán cada una de las interfaces del usuario y la funcionalidad
que tiene cada una de estas.
4.2 PÁGINAS DEL SISTEMA
4.2.1 Página inicial del sitio
Esta es la página oficial de SION cuya ruta es http://sion1/; ahí esta ubicado el
hipervínculo (1) que lo dirección hacia la interfaz de acceso de la aplicación REMA.
254.2.2 Página de acceso
En esta página se debe ingresar el nombre de usuario y contraseña para validar que si
tiene el permiso suficiente para trabajar en REMA.
Los usuarios que tienen acceso a SION pueden ingresar de igual forma con el mismo
login y contraseña al sistema REMA.
264.2.3 Páginas usuarios
4.2.3.1 Página de consulta
5) La lista buscar tiene todas las siguiente opciones:
• Todo: Trae todos los registros que existen hasta la fecha en la base de
datos.
• Servicios: Como su nombre lo indica, solo se traen los registros
referentes a los servicios que se le halla colocado o quitado al abonado.
• Categorías: Trae solamente los registros referentes a los cambios de
categoría que halla sufrido el abonado hasta la fecha.
• Estados: Trae todo lo referente a los estados del abonado (ejm: poner en
vacante, en uso, etc.)
• Serv/Cat: Trae los registros tanto de los servicios como de los cambios
de categoría que halla sufrido el abonado hasta la fecha.
• Est/Cat: Trae los registros tanto de cambios de estado como cambio de
categoría que halla sufrido el abonado hasta la fecha
2) Este campo es opcional, es decir, puede realizar consultas del abonado sin
especificar un rango de fechas; pero si se desea consultar en un rango de fechas
debe especificar estrictamente una fecha de inicio y de fin.
1) Este campo es obligatorio, ya que es donde se especifica el número del abonado
a consultar.
273) Este mensaje indica la cantidad de registros del abonado traídos de la base de
datos y que cumplen con la consulta realizada previamente.
4) Este menú de navegación permite al usuario moverse a la siguiente o anterior
página para visualizar los registros del abonado.
6) Este vinculó permite exportar la información consultada a un archivo de Excel,
si el usuario esta interesado en guárdala ya sea en su equipo o en algún disco
extraíble.
7) Vinculo para cambio de contraseña del usuario.
4.2.4 Páginas administrador
4.2.4.1 Página eliminar registros
1) Esta lista indica que los registros que se van a eliminar pertenezcan a cierta
tecnología (FETEX-150, AXE-10, NEAX61-S).
Veamos todas las posibles selecciones:
• Todo: borra todos los registros referentes a las 3 tecnologías.
• AXE-10: Borrar los registros referentes a esta tecnología.
• FETEX-150: Borrar los registros referentes a esta tecnología.
• NEAX61-S: Borrar los registros referentes a esta tecnología.
282) El rango de fecha es opcional, es decir, si no se especifica entre que fechas quiere
borrar registros de la base de datos, el sistema borra todos los registros que cumplan la
condición de la opción seleccionada previamente en la lista sistema (1).
3) Este campo es opcional y es donde se especifica el número del abonado en caso de
que quiera solo borrar registros que correspondan a este.
4) Este menú de navegación permite ir a la página en la cual realizo cargas manuales de
archivos.
5) Menú de navegación que permite ir a la página ingresar usuarios.
4.2.4.2 Página cargar manual
Una carga manual se hace cuando algún archivo no se tuvo en cuenta o no se cargo
exitosamente (ya sea por que se presento un problema de conexión con la base de dato)
en el proceso de carga automático que se realiza diariamente.
1) Permite especificar a que tipo de sistema pertenece el archivo que se desea cargar.
2) Se debe especificar la ruta donde esta ubicado el archivo
3) En esta parte de la página se muestra información sobre el proceso de carga, como
fecha y hora de inicio de la carga del archivo, nombre del archivo que se esta cargando,
total de registros procesados, fecha y hora de terminación de la carga.
Toda esta información se visualiza con el fin de que el administrador se de cuenta si el
archivo se cargo exitosamente.
294) Menú de navegación que permite regresar a la página principal del administrador.
4.2.4.3 Página ingresar usuarios
1) Para ingresar un nuevo usuario al sistema es necesario llegar todos los campos del
formulario y definir de que tipo va a ser, si usuario administrativo o común de la
aplicación.
2) Esta es la información que se visualiza una vez sea exitoso el proceso de inserción
del usuario en la base de datos.
3) Menú de navegación que permite ir a la página eliminar usuarios donde están
listados todos los usuarios de REMA.
304.2.4.4 Página eliminar usuarios
En esta página se visualizan todos los usuarios existentes del sistema REMA, además
desde aquí se pueden borrar usuarios.
31CONCLUSIONES
El sistema REMA fue concebido para manejar todos los comandos exitosos referentes a
los movimientos en la cuentas de los abonados en cada una de las tres tecnologías, es
por ello que su funcionalidad es brindar información instantánea de los movimientos
históricos que un abonado haya tenido.
Con el desarrollo del aplicativo REMA el tiempo requerido para recopilar la
información de movimientos en cuentas de abonados disminuyó enormemente al pasar
de un proceso de búsqueda manual a uno automático.
A la hora de desarrollar aplicaciones para beneficio de la empresa, considero que si se
quiere obtener resultados favorables que soluciones los problemas de la organización se
hace necesario personal permanente, encargado de un constante mantenimiento y
mejoras de estos sistemas, ya que de la forma en que lo hace la organización en la
actualidad al contratar practicantes, es que una vez estos se vayan de la organización, lo
mas probable es que estos proyectos fracasen a mediado plazo.
Evitar la manipulación manual de los archivos con los LOG generados ya que esto
pueden generar errores a la hora de cargar la información en la base de datos de la
aplicación.
La información de los tres sistemas AXE, FETEX y NEC estará integrada.
La información presentada del movimiento de los abonados es de fácil comprensión.
32Trabajo Futuro
Tener en cuenta la inclusión en la búsqueda los comandos no exitosos.
Mantenimiento y Administración de la aplicación REMA.
Puesta en marcha de la aplicación en un sitio Web más confiable y seguro.
Realizar un análisis más profundo sobre aquellos comandos que no reportan éxito o
fracaso (para el caso de AXE-10 que no presenta respuesta de éxito o fracaso dentro del
log de comandos).
La información de los movimientos de abonados estará disponible para el usuario final
hasta el día anterior de la fecha actual.
Buscar una manera diferente de obtener la información de los movimientos de las
cuentas de abonados, ya que en el sistema REMA la información se obtiene de los log’s,
los cuales dependen en gran medida de los operadores quienes pueden cometer errores
en la manipulación del estos.
33BIBLIOGRAFÍA
[Betancur, 2000] Betancur, Mario. Elementos básicos de telecomunicaciones, unidad de
comunicaciones y relaciones corporativas, Vol. 1, 2000.
[Botero, 2000] Botero, Fernando. Una mirada al pasado una visión de futuro, unidad
de comunicaciones y relaciones corporativas, Vol. 1, 2000.
[González, 2001] González, Óscar. Active Server Pages (Asp 3.0). Iniciación y
referencia. 2001.
[González, 2001] González, Óscar. ASP 3: Programación en VBScript para IIS 5.O.
2001.
[Serrano, 2001] Serrano, Jorge. Desarrollo de componentes ASP. Editorial Anaya.
2001.
[Gondar, 2001] Gondar, José. A fondo Microsoft SQL Server 2000. Editorial McGraw-
Hill. 2001.
[Durnford, 1995] Durnford, Jonathan. A guide to systems modeling. Libro biblioteca
universidad EAFIT. Vol 1. 1995.
[Larman, 2002] Larman, Craig. Applying uml and patterns. Libro biblioteca
universidad EAFIT. Vol 1. 2002.
[Filman, 2005] Filman, R. E. Aspect oriented software development. Libro biblioteca
universidad EAFIT. Vol 1. 2005.
[Lora, 2002] Lora, Mónica. Construccion de sitios web e commerce a paritr de una
metodologia basada en el lenguaje uml. Revista biblioteca universidad EAFIT. 2002.
[Zelman, 2002] zeldman, Jeffrey. Principios del diseño Web. Libro biblioteca
universidad EAFIT. 2002.
[Gutiérrez, 2000] Gutiérrez, Abraham. Html dinamico, asp y javascript. Editorial
alfaomega. 2000.
[Stanek, 2001] Stanek, William. Microsoft SQL Server 2000: manual del
administrador. Editorial McGraw Hill. 2001.
[Utley, 2001] Utley, Craig. Desarrollo de aplicaciones web con SQL server TM 2000.
Editorial McGraw Hill. 2001.
34Internet
Historia de la red:
http://geneura.ugr.es/internet/section3_2.html
Museo de las telecomunicaciones:
http://www.fundacion.telefonica.com/MUSEO/educa/recur/cfade/lista.htm
Historia del teléfono:
http://www.saber.golwen.com.ar/htelefono.htm
Wikipedia (el teléfono):
http://es.wikipedia.org/wiki/Tel%C3%A9fono
Evolución de las centrales telefónicas:
http://neutron.ing.ucv.ve/revista-e/No3/Alvarez.html
Historia de la comunicación por alambres:
http://www.sapiensman.com/old_wires/telegrafo_y_telefono4.htm
Solo ASP:
http://www.soloasp.com.ar/ejemplos.asp
Desarrollo Web:
http://www.desarrolloweb.com
Manejo de errores en ASP:
http://groups.google.com.co/group/microsoft.public.es.asp/browse_thread/thread/a2366
4b37f51587/cdb614f6ede81523%23cdb614f6ede81523
35