Entradas

Detalles finales

Duración:  dos horas y quince minutos (11:45 A.M. a 14:00 P.M.) Descripción: Se trabajó en los últimos detalles del proyecto, los cuales consistieron en unas pequeñas modificaciones a dos SP y la creación de las últimas entradas al blog. En el caso del código, se le agregó la parte de TRANSACTION a los dos archivos que ingresan información a la base de datos. Es decir, a los SP para ingresar un empleado y para ingresar un movimiento. Finalmente, se creó el documento de análisis de resultados con las características y métricas principales del proyecto. Problemas encontrados: No se tuvieron problemas en esta etapa del desarrollo del proyecto.

Conexiones con backend y pantallas de listar y crear movimiento

Duración: once horas   (19:00 P.M. a 02:00 A.M. - 09:00 A.M. a 12:00 M.D) Descripción:   En esta sesión de trabajo se trabajaron los aspectos finales de la interfaz y la conexión con el backend. Se desarrollaron los métodos necesarios en el backend Spring Boot para poder pasar la información entre las os partes utilizando los requests HTTP. Se desarrollaron los métodos de: iniciarSesion, logout, getListaEmpleados, getListaEmpleadosFiltro, getInfoEmpleado, borrarEmpleado, actualizarEmpleado, getListaMovimientos, insertarEmpleado y insertarMovimiento. Para hacer estos se usó el Mapping de Spring Boot para especificar cuál es el tipo de request que los accesa. La gran mayoría utilizan el POST ya que se necesita pasar información entre los dos lados. La clase ApiController es la que maneja esto. Se hizo la creación de dos pantallas: listaMovimientos e insertarMovimientos. Ambos tienen sus validaciones en capa lógica y también en bases de datos como una medida más de seguridad...

Comentarios e IP

Duración: tres horas (11:30 P.M. a 01:00 A.M. - 10:30 A.M. a 12:00 M.D.) Descripción: Esta sesión de trabajo fue larga en tiempo dado que las actividades eran laboriosas, pero realmente fue sencilla. Consistió más que todo en la documentación (comentarios) del código. La idea era que el código tuviera todos los comentarios necesarios para su compresión (por eso la cantidad de horas de trabajo). Durante esta etapa se documentaron todos los códigos de los SP y los de Java. Cada código incluye su debido encabezado, descripción del código general, división del código por etapas y la explicación de estas (ya sea de forma general y/o paso por paso). Aparte de esto también se procedió a implementar la lógica del IP en base de datos y capa lógica. Originalmente, se utilizaba la función HOST_NAME() de SQL Server para obtener el nombre de la computadora desde la que se accedía a la base de datos. Sin embargo, se necesitaba cambiar esto para recibir una dirección de IP válida.  Para real...

Conexión a BD desde Java

Duración:  cinco horas y media (17:00 P.M. a 22:30 P.M.) Descripción: Dado que ya se tienen los SP listos y ya han pasado por varias pruebas, se procedió a realizar la conexión entre la base de datos y la capa lógica. Para este proyecto se está utilizando Java como lenguaje de capa lógica. Se comenzó con un proyecto tipo Maven para poder agregar una dependencia desde el repositorio de dicha plataforma para poder conectar contra la base de datos. Una vez que se tuvo el área de trabajo, se procedió a comenzar con las clases y sus respectivos métodos. Previo a esta etapa de trabajo se había realizado una conexión desde Java para poder acceder a la aplicación y hacer el listado de los empleados. En vista de esto, se utilizó parte de ese código para establecer la conexión. Esta conexión se realizó en una clase general llamada Repository. De esta heredan las demás clases que se encarga de la lectura de o la escritura en la base de datos. Para definir la cantidad de clases tipo repositori...

Quinta parte de los SP

Imagen
Duración:  tres horas (11:40 A.M. a 14:40 P.M.) Descripción: Se continuó con el desarrollo de los SP para el proyecto. Durante esta etapa se corrigió la carga de los movimientos desde el archivo XML y se trabajó en los SP relacionados con esta información. Respecto al primer tema, se tuvo que corregir la carga porque, originalmente, se ingresaban los movimientos y se mapeaban sus llaves foráneas, pero no se actualizaba el saldo del empleado correspondiente. Además, tampoco se actualizaba el nuevo saldo que aparece como parte de la información del movimiento. Por esto, se cambió la lógica de la carga. Se decidió utilizar una tabla variable para almacenar temporalmente la información del archivo y luego mapearla y actualizarla utilizando un SP creado específicamente para esto. Respecto al segundo tema, se trabajó en el SP para la consulta de movimientos (el listado) y el ingreso de nuevos movimientos para los empleados. En la sección de "Apoyos" se incluye un enlace a la versió...

Cuarta parte de los SP

Duración: dos horas y media (20:00 P.M. a 22:30 P.M.) Descripción: Primeramente, se trabajó en la nueva carga de datos. En la sesión previa en la que se trabajó con el XML, se ingresaron los datos de la primera versión del archivo que habían facilitado los compañeros. En esta, se borraron los datos anteriores, se volvieron a crear las tablas (con un cambio en el tamaño de la descripción de los eventos en la bitácora) y se cargó nuevamente la información. Seguidamente, se realizaron algunos cambios en códigos anteriores y se desarrollaron algunos SP nuevos. Estos últimos, se centraron en el CRUD de los empleados. Por tanto, se creó el procedimiento para la actualización de información, para el borrado lógico de un empleado y para la consulta detallada de un empleado en específico. Problemas encontrados: No se tuvieron problemas en esta etapa del desarrollo del proyecto. Apoyos: A continuación, se incluye un enlace hacia el último commit de los sp mencionados anteriormente al momento...

Creación de las pantallas

Imagen
Duración:  siete horas (16:00 P.M. a 23:00 P.M.) Descripción: Al igual que el proyecto anterior, el front-end de este proyecto se realizará por medio de Svelte y Spring Boot en Java. La comunicación de estas capas se realizará por medio de métodos HTTP entre las dos (POST, GET, PUT, DELETE). La estructura de las pantallas será la siguiente: Estarán las siguientes rutas: /actualizarEmpleado?empleado=xxx /borrarEmpleado?empleado=xxx /consultarEmpleado?empleado=xxx /insertarEmpleado /listaEmpleados En las rutas de actualizar, borrar y consultar, habrá un query en el URL que tendrá la id del empleado en el que se realizarán estas operaciones. En la ruta de insertarEmpleado, no es necesario pasar ningún id, ya que no se ocupa saber algún empleado. La pantalla principal después de hacer el Login correctamente será la de listaEmpleados. Problemas encontrados: No se tuvieron problemas en esta etapa del desarrollo del proyecto. Apoyos: Se utilizó como apoyo el proyecto anterior del curso de...

Tercera parte de los SP

Duración: una hora y quince minutos (17:15 P.M. a 18:30 P.M.) Descripción: Esta sesión de trabajo fue relativamente corta. Consistió más que todo en revisar los SP que ya se habían creado para corregir algunos detalles y arreglar comentarios. Aparte de eso, también se creo el SP para insertar un empleado nuevo, el cual sí tiene cierto detalle en su implementación. Problemas encontrados: Realmente no es un problema, pero se decidió agregar un tipo de error más a la tabla Error. Esto para hacer la validación de filtros aun más eficiente en el SP correspondiente. Existía un error para varias de las validaciones, pero no para cuando, por alguna razón, el filtro no tiene alguno de los errores previos ni es correcto. No se ha llegado a utilizar el error, pero se decidió ampliar para evitar sorpresas. El código que se añadió fue 50013 con la descripción "filtro inválido." Apoyos: A continuación, se incluye un enlace hacia el último commit de los sp mencionados anteriormente al momen...

Segunda parte de los SP

Imagen
Duración:  dos horas (14:30 P.M. a 16:30 P.M.) Descripción: Se continuó con el desarrollo de los SP para el proyecto. En esta etapa se trabajó en cuatro SP en específico: validación de acceso, ingresar eventos a la bitácora, listado de empleados y aplicación de filtros a la lista. En el caso del procedimiento para el acceso, se le realizaron algunas correcciones por como el procedimiento de la bitácora recibía el parámetro del usuario. Originalmente se le pasaba el nombre del usuario y el SP de la bitácora determinaba el ID que le correspondía para guardar el dato en la tabla. Sin embargo, trabajando con otros códigos, se notó que, si se mantenía de esta forma, había uno en el que se ocupaba pedirle el ID a la bitácora, después mapearlo para encontrar el nombre y luego darle este último valor a la bitácora (nuevamente) para que este terminara haciendo el mismo proceso inverso. En vista de esto, los procedimientos que llaman a la bitácora se deben encargar de determinar el ID del us...

Primera parte de los SP

Duración:  tres horas y quince minutos (10:30 A.M. a 13:45 P.M.) Descripción: Se comenzó formalmente con los stored procedures del proyecto. Durante esta sesión de trabajo se crearon los procedimientos relacionados con la validación del acceso a la aplicación, con el registro de las acciones del usuario en la bitácora de eventos y con la consulta del significado de los errores que pueden producir los procedimientos en general. Cabe notar que, para el sp relacionado con el acceso, para esta primera parte, aun no se le ha implementado la opción de deshabilitar el login si se realizan cinco o más intentos fallidos de entrada. Por otro lado, para el de eventos en la bitácora, falta corregir el IP (actualmente registra el nombre de la computadora). Se hicieron varias pruebas para comprobar que todos estuvieron funcionando de la manera en que deben. Además, se comprobó que capturaran todos los errores posibles en las situaciones correspondientes. Por tanto, hubo un cierto periodo de prue...

Segunda parte de la lectura del XML

Duración:  hora y media (19:30 P.M. a 21:00 P.M.) Descripción: Creación del script inicial para carga de datos desde un archivo XML a las tablas correspondientes en la base de datos. Una vez solucionados los problemas que se encontraron en la primera parte de este proceso, se procedió a escribir todo el script para poder cargar datos. Fue un proceso relativamente sencillo, sin embargo, como se puede notar, duró un poco. Esto se debe a la curva de aprendizaje para aprender a mapear los datos entre tablas correctamente. Una vez listo esto, se subieron los scripts de la creación de tablas y de la lectura del archivo XML al GitHub del proyecto. Dado que, recientemente, los compañeros compartieron otra edición de los datos para la carga hacia las tablas, probablemente se revise la información y los scripts una vez más. Problemas encontrados: No se tuvieron problemas en esta etapa del desarrollo del proyecto. Apoyos: A continuación, se incluye un enlace hacia el último commit de los scri...

Primera parte de la lectura del XML

Imagen
Duración: una hora (09:20 A.M. a 10:20 A.M.) Descripción: Se comenzó con el proceso de lectura del archivo XML. Durante esta sesión de trabajo se intentó algo básico: poder abrir el archivo para lectura, cargar un elemento específico en su tabla correspondiente (idelamente uno que tenga llaves foráneas) y revisar datos. Por esto, se comenzó con la información de los puestos de los empleados. Problemas encontrados: Intentar decifrar el código a utilizar para lograr la lectura del archivo XML fue relativamente fácil, pero acceder a este archivo no. Los problemas que se toparon al momento de leer el archivo fueron los siguientes: "You do not have permission to use the bulk load statement" Al principio, no se podía ejecutar la línea del BULK LOAD para poder cargar el archivo XML en el código.  La solución a esto fue darle privilegios de tipo ADMINISTER BULK OPERATIONS de los roles fijos del servidor en BULKADMIN. Para encontrar la solución a este problema, se utilizó la herramien...

Nueva base de datos

Imagen
Duración:  tres horas (21:00 P.M. a 00:00 A.M.) Descripción: Se instaló Hamachi para poder solucionar los problemas que se tenían con la lectura del archivo XML. Se creó una nueva red virtual privada para poder relacionar las computadoras y que ambas tengan acceso al servidor en el que va a estar la nueva base de datos. Problemas encontrados: Realmente el trabajo que se desarrolló en este tiempo fue pequeño, pero se toparon múltiples problemas al momento de realizarlo. A esto se debe la duración de esta etapa del proyecto. El primer problema que se topó es que, al momento de intentar realizar la conexión, resultaba un poco complicado tener que ponerse de acuerdo para poder ir haciendo todo paso a paso. En vista de esto, uno de los integrantes se encargó de probar la red que se creó por medio de Hamachi y comprobar que sirviera. Para esto, se utilizó la computadora propia de la persona y una segunda a la que se tenía acceso directo. En esta, se tuvo que proceder a instalar todos lo ...

Búsqueda de una nueva solución para la base de datos

Duración:  una hora (19:00 P.M. a 20:00 P.M.) Descripción: En la clase de hoy se leyó el documento con la rúbrica de evaluación de este proyecto. En este, se pudo observar que el valor del script de la lectura del archivo XML es de un 15%. En vista de que tiene un porcentaje tan alto, se decidió evitar continuar con el proyecto y buscar una solución final al problema que se tenía con la lectura de este tipo de archivos. Se intentó conseguir más información relacionada con la lectura de archivos XML para Azure. Sin embargo, toda estaba relacionada con el Data Factory o proveían soluciones muy similares a las que se intentaron previamente (y que se determinó que no eran factibles para las especificaciones de este proyecto). Entonces, se decidió optar por cambiar el servidor en el que se maneja la base de datos. Se decidió optar por Hamachi, así que se comenzó con la búsqueda de información para poder crear el servidor y realizar una base de datos de tal manera que ambos usuarios la p...

Búsqueda de una nueva solución para la carga de datos

Imagen
Duración:  dos horas (20:00 P.M. a 22:00 P.M.) Descripción: En vista de que no se ha logrado leer el archivo XML para poder subir la información a la base de datos en Azure, se optó por buscar algún otro medio de subir los datos. La opción que se encontró definitivamente no acata las instrucciones del proyecto, pero, al menos por ahora, funciona. La idea con esto no es reemplazar la carga de datos de la forma en que se espera sino, más bien, poder tener algunos datos con los que trabajar para poder continuar con las otras partes del proyecto. La "solución" que se encontró se basa en utilizar Python y algunso SPs. El primero, se utiliza para leer el archivo y clasificar la información. Los segundos, se encargan de recibir la información que genere el código de Python y lo mapean en las tablas correspondientes (encargándose de asignar las FK necesarias). Problemas encontrados: En esta etapa del proyecto realmente no se encontraron problemas. Más bien, se intentó "soluciona...

Creación de las tablas de la base de datos

Duración:  media hora (19:00 P.M. a 19:30 P.M.) Descripción: Se crearon las tablas necesarias para el desarrollo del proyecto por medio de un script. Una vez que estuvieron listas, se revisó que las FK estuvieran bien conectadas. Además, se creó un diagrama para facilitar la visualización de la información de las tablas. Problemas encontrados: No se tuvieron problemas en esta etapa del desarrollo del proyecto.

Lectura de XML usando Blob Storage

Imagen
Duración:  cuatro horas (13:00 P.M. a 17:00 P.M.) Descripción: Se comenzó la búsqueda sobre la transferencia de datos desde un XML. No se encontraron buenos resultados. La mayor parte de los resultados que aparecían para leer este tipo de archivos con Azure implicaban el uso de la Azure Data Factory. Esta, si bien parecía capaz de lograr el resultado que se esperaba, no permitía generar scripts. Por tanto, se tuvo que indagar mucho más para intentar encontrar un resultado favorable. Se encontraron dos opciones: utilizando un BULK INSERT y otra haciendo el código un SP. Sin embargo, ninguna de los dos métodos funcionó como se esperaba.  Problemas encontrados: En todos los casos solía pasar que "no tenía acceso al archivo". Sin embargo, en el Blob Storage (el servicio de Azure en el que se encontraba el archivo), todos los usuarios tenían acceso a este. Recursos utilizados: Video 01 - Transferencia de datos de XML a DB en Azure Video 02 - Transferencia de datos de XML a DB en A...

Creación del blog

Duración:  cuarenta minutos (21:00 P.M. a 21:40 P.M.) Descripción: Se creó el blog para llevar la bitácora del proyecto usando la herramienta de Google Blogger. En esta etapa del proyecto se realizó lo siguiente: Creación del nuevo blog. Configuración del diseño del blog y de algunos atributos predeterminados (fue la parte que más tiempo tomó). Creación de algunas entradas de prueba. División de las entradas por tipo según los temas: general, base de datos, capa lógica e interfaz. Problemas encontrados: No se tuvieron problemas en esta etapa del desarrollo del proyecto.

Reactivar cuenta de Azure

Duración: media hora (20:30 P.M. a 21:00 P.M.) Descripción: Se realizó el proceso de reactivación de la cuenta de Azure. El plazo de 30 días que ofrece Azure en la cuenta gratis ya había pasado para el momento en el que se decidió construir una nueva base de datos. Por tanto, se tuvo que reactivar la cuenta. Se recurrió a mejorar la cuenta a una de tipo "page según lo que utiliza". Esta, le permite al usuario pagar únicamente por lo que utiliza y, además, tiene la cualidad de que algunos servicios son gratis hasta cierto punto. El servicio que permite crear servidores y bases de datos forma parte de estos. Problemas encontrados: Realmente no es un problema, pero al principio se tenía cierta desconfianza sobre lo que realmente significaba esa mejora de la cuenta. No se sabía hasta que punto se podían utilizar los servicios de Azure sin que se tuvieran que realizar pagos. Ante esto, se recurrió a leer un poco de las condiciones de la mejora de cuenta. Recursos utilizados: Azure...

Definición de ambientes

Duración: entre 10 y 15 minutos (intercambio de mensajes) Descripción: Definición preliminar de los ambientes de trabajo que se van a utilizar para realizar el trabajo Se definen los siguientes: Azure para la base de datos. Java para la capa lógica. JavaScript para la interfaz. Se conecta a Java por medio de Spring Boot y se utiliza Svelte como framework. Nota: dado que es una definición preliminar, los ambientes se podrían cambiar a lo largo del proyecto según se considere necesario. Además, la elección de los ambientes anteriores se basó en la experiencia positiva que se tuvo con todos ellos para el desarrollo de la prueba de concepto. Problemas encontrados: No se tuvieron problemas en esta etapa del desarrollo del proyecto.