Portal Municipalidad v.2.0

Descripción: Para esta segunda entrega del Portal Municipalidad se trabajó sobre la v.1.0 en la cual se realizaron una serie de modificaciones a las tablas pre existentes y se modificaron ciertos CRUDS para aumentar la funcionalidad del Portal web. Asimismo se incorporaron una serie de nuevas tablas y  nuevos SP (de mayor complejidad). La página continúa simulando un portal web amigable con el usuario para una municipalidad (gobierno local en Costa Rica). Desde él se pueden consultar propiedades registradas, propietarios (incluyendo de tipo jurídico), usuarios registrados en el portal y conceptos de cobro sobre los servicios municipales. Para esta nueva versión se pueden gestionar las transacciones de consumo de agua, se habilita la generación de recibos recurrentes (de manera mensual), se pone a disposición las generación de ordenes de corta y reconexión de agua y el pago de recibos (este incluye el manejo de  intereses moratorios). Finalmente, una bitácora de cambios (tipo historial) realizados en una serie de tablas.

Para esta nueva versión 2.0 se habilita la diferenciación de perfiles en el portal web. Si se utiliza el modo administrador es posible alterar las diversas relaciones entre los objetos del portal, por ejemplo: Añadir propiedades, propietarios, usuarios y conceptos de cobro; modificar los diferentes propietarios de cierta propiedad, los usuarios que tienen derecho consultar la propiedad y los conceptos de cobro que van a ser asociados a los diferentes bienes inmuebles. Además, consultar los recibos (pagados, pendientes), comprobantes de pago y las transacciones en el consumo de agua asociados a una determinada propiedad. Adicionalmente, es posible consultar un historial de cambios en un rango de fechas establecido. Para lo que corresponde al modo cliente se habilita la posibilidad de manejar solamente las propiedades registradas a su nombre, o bien, que gocen de permisos para ser vistas por un determinado cliente. El cliente puede consultar recibos de sus propiedades, pagarlos, revisar las personas inscritas como propietarios del inmueble, revisar el historial de facturas o comprobantes de pago y ademas, consultar los diferentes tipos de conceptos de cobro a los cuales está suscrita la propiedad.

Características:

1. Utilización de CRUD's para realizar las diferentes acciones de la página web. 
2. Scripts para carga desde archivos XML tipo simulación.
3. Manejo de errores por medio de códigos personalizados.
4. Validaciones en capa de datos y en capa lógica para evitar al máximo los bugs.
5. Versionamiento de la página por medio de la plataforma Github.
6. Base de datos con respaldo en servidor de AWS.
7. La página web posee una UI amigable. 
8. Creación de INSERTS masivos desde el XML.
9. Validación de tipos de usuarios en página web y base de datos.
10. Procesamiento de transacciones de consumo y manejo diferenciado por tipos.
11. Reconstrucción del acumulado total de m3 de agua en las propiedades.
12. Generación de recibos de manera recurrentes y en caso extraordinarios.
13. Utilización de tipos de datos personalizados en SQL para el manejo de parámetros tabla.
14. Procesamiento de pagos de forma retroactiva, con validación de recibos pendientes y manejo de intereses moratorios.
15. Generación de órdenes de corta y reconexión de agua.
16. Utilización de trigger para manejo de cambios en las tabla de Propiedades.
17. Deshabilitación y habilitación de triggers por medio de comandos de tipo varchar.
18. Utilización de ip's y nombres de usuario para generar trazabilidad de los cambios registrado en la bitácora.
19. Modificación de los CRUDS originales en las principales tablas para el registro de los cambios en la bitácora.
20. Parseo de formato JSON para mostrar los cambios en las entidades de la base de datos.
21. Consultas a un historial de cambios por rango de fechas de forma intuitiva y amigable con el usuario.

Anotaciones: La lectura de los archivos XML requiere subir el archivo .xml en el mismo servidor donde sea hospedada la base de datos. Por motivos de AWS (solo permite .json y .csv) no se permitía la carga de tipo BULK del archivo XML a la base de datos SQL. Es por esa razón que creamos una copia de la base de datos y la corrimos en un servidor local. Para esta segunda entrega fue importante el aprendizaje en el manejo de triggers. Cuando se utilizan triggers masivos se ejecutan en batches de ocho elementos aproximadamente, por ese motivo vemos como valioso rescatar que si se desea aplicar un sp a los elementos que vienen, utilizar un medio de interación. Asimismo, mencionar que para poder pasar una tabla como parámetro en un sp, es necesario establecer un tipo definido de variables tabla con sus características principales.

Consejos: La simulación creada a partir del XML toma muchísimo tiempo. Para aumentar la eficiencia se diseñó un método que rebaja el tiempo de ejecución un 97,67% (de 5 min a 7 seg). Este consiste en extraer los datos y colocarlos en tablas temporales, incluyendo en estas tablas la fecha para luego utilizar un 'WHERE' y sacar la información según la fecha. Por lo que en el while solamente se estará extrayendo información de las tablas con los datos precargados. 

     Esto evita que se extraigan los datos de las 3700 líneas del XML 121 veces para solo insertar las que cumplen con esa fecha. En la primera versión del archivo se brindaba la fecha en un nodo dentro de "Operacion_Dia" por lo que debíamos recorrer un nodo sacando por ejemplo los datos de un propietario y luego devolverse para poder sacar el nodo fecha lo cual ralentizaba aún más el proceso. 

    Entre los consejos de la segunda entrega del trabajo cabe destacar que tal y como nos recomendó el profesor, si bien SQL no está diseñado para trabajar de manera iterativa, en los últimos años está ganando tendencia el utilizarlo de esa manera. Esto porque es más fácil de debuggear, mantener y optimizar. Nosotros utilizamos este consejo para la transacción de consumo de agua, así como para la generación de recibos, pagos, cambios es propiedad e inclusive en el trigger. 

     

En la página web se pueden reutilizar métodos como por ejemplo el de mostrar propiedades ya que lo único diferente es el nombre del SP y  el de los parámetros pero siguen una línea muy similar. Además, al mostrar las propiedades los atributos a mostrar son los mismos por lo que el archivo .aspx que contiene el html y genera la misma tabla y mismo orden de botones y demás. En la cuestión de los errores se manejan en la base de datos ya que esta no puede permitir que se generen problemas, sin embargo no se puede enviar un dato que se supone que es int como varchar  porque  al sacarlo del textBox, este dará error entonces se debe previamente utilizar alguna estrategia para mitigar estos errores que pueden provocar que la página se caiga. En este caso nuestra solución fue usar expresiones regulares y al encontrar que un storing contiene letras convertir el valor de esa variable a -1 para que al recibirse en la base esta notara ese detalle y devuelva error. 

Recursos:

La página web fue creada utilizando ASP.NET con conexión a una base de datos creada en SQL Server. AWS (Debido a la emergencia de la cuarentena se logró trabajar de manera remota para que ambos integrantes pudiesen trabajar en conjunto)

Estado final: Luego de arduos días de trabajo la base finalmente se encuentra totalmente funcional. Cuenta con todos los requerimientos pedido por el profesor. Esto se traduce en la implementación del modelado hecho en clase, siguiendo exclusivamente los estándares del curso: utilización de índices por medio de llaves primarias, de tipo integer, identity, incremental de 1 en 1, con formato de nombre "ID". Además, la colocación del prefijo "in"(input) para parámetros de entrada de los diferentes stored procedures. La base posee manejo de errores por medio de Try and Catch y de la variable del sistema @TRANCOUNT, retornando números de error personalizados. La implementación de alias para las tablas en los inner join. De igual forma la implementación de las fórmulas para el cálculo de los recibos detalladas en el documento, mediantes el uso de CASE. Por último, la utilización de triggers para el registro de cambios es una determinada tabla. 

Adicionalmente, se implementaron CRUD's en la totalidad de la tablas para satisfacer las consultas requeridas por el portal, utilizando el estándar de stored procedure dado en clase. La página web también está también totalmente funcional y contiene elementos para optimizarla como por ejemplo:  no mostramos todos los objetos de una tabla para no sobrecargar la página. Además, se implementó un botón de volver para que el usuario pueda ir hacia atrás sin tener que darle click a los botones de arriba. Esto puede ser más funcional en el caso de que se desee agregar más elementos a la página y existan más botones. Y es bastante natural tener botón para ir hacia atrás en la UI de las páginas. Se utiliza un menú principal que permite navegar por las diferentes páginas; este se mantiene estático por lo que facilita la navegación por el portal y permite ir de una consulta a otra fácilmente. El tamaño de los botones y del texto fue considerado ya que, como no hay muchos elementos se puede ampliar el texto pero sin que sea masivo, tratando de mantener una interfaz limpia. En el caso de las propiedades donde el texto es muy extenso se amplía el ancho de las tablas para evitar la acumulación de texto en un espacio reducido y así mantener un buen diseño. Para esta segunda entrega el portal web cuenta con la completa implementación de generación de recibos, facturación, manejo en el consumo de agua, cortes y reconexión de agua e historial de cambios. Para la UI de la página web se implementa el uso de la bitácora de cambios de manera intuitiva para el usuario (por medio de animaciones de calendario) y el menú de opciones se expandió para abarcar las nuevas funcionalidades y muestra lo necesario dependiendo del tipo de usuario que haya accedido a la plataforma.