Implementación manejo de excepciones en serverless cargue masivo

Se requiere realizar el manejo de excepciones en cada función implementada en el microservicio cargue_archivo_mid_serverless de tal forma que los errores que actualmente se imprimen puedan ser retornados en el body de la respuesta.

Se puede complementar cada función retornando una tupla de valores (valor actual, error) y según cada tipo de excepción (critica que finaliza el proceso o error en cada fila que se debe agrupar para responder al final del proceso, por ejemplo, datos incompletos en la fila) se debe manejar para retornar dicha respuesta.

Definición respuesta Actualmente retorna, Se puede complementar con:

{
   "Success":"success",
   "Status":"status_code",
   "Message":"message",
   "Data":"data"
}

Ejemplos:

{
   "Success":true,
   "Status":201,
   "Message":"Documento procesado correctamente",
   "Data": null
}

{
   "Success":true,
   "Status":201,
   "Message":"Documento procesado con algunos registros por revisar",
   "Data":{
      "Correctos":[
         1,
         2,
         4,
         6,
         7,
         8,
         10
      ],
      "Erróneos":[
         {
            "Idx":3,
            "Error":"Error en conversión del campo FechaFinal"
         },
         {
            "Idx":5,
            "Error":"Falta campo FechaFinal"
         },
         {
            "Idx":9,
            "Error":"Id 180 no encontrado"
         }
      ]
   }
}

Sub Tareas

[x] Implementación retorno de errores de las funciones implementadas.
[x] Estructura de respuesta según excepción generada (criticas o individuales).
[x] Implementación campo adicional de referencia (para este caso el archivo no conoce a que plan se están cargando dichas auditorias, este campo se pasa en el JSON de parametrización).
[x] Implementar captura de errores en las funciones build_url (caso que falte service o endpoint o tipo erróneo) y parse_value (error de conversión).
[x] Captura de respuesta para peticiones con status_code diferente a 200 o 201, esa respuesta debe asociarse al registro de la petición dado que si falla es necesario retornar en la respuesta ese registro porque falló.
[x] Implementación función de mapeo de string por el Id respectivo (requerido para mapear los meses Enero, Febrero, ... a los respectivos Ids de parámetros CRUD).
[x] Pruebas funcionales.

Criterios de aceptación

[x] Documentación avances implementación y resultado pruebas funcionales.

Requerimientos

No aplica

Definition of Ready - DoR

[x] Está refinada y estimada en puntos de historia por el equipo.
[x] Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
[x] No tiene bloqueos que impidan su ejecución.
[x] Las dependencias están identificadas y resueltas.
[x] Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

[x] Desarrollo en local.
[x] Push en Feature.
[x] Pruebas locales (funcionales).
[ ] PR a Develop.
[x] Criterios de aceptación cumplidos.
[x] Documentación de issue realizada.
[x] Aprobada por SM/Líder técnico.

Manejo de excepciones

Se agrega el manejo de errores para la función build_url:

Captura de pantalla 2024-11-05 a la(s) 11 23 26 p m

Se agrega el manejo de errores para la función parse_value:

Captura de pantalla 2024-11-05 a la(s) 11 23 18 p m

Se inicia con la revision y prueba del manejo de los registros por fila y acumulandolos:

Captura de pantalla 2024-11-05 a la(s) 11 37 36 p m

Manejo de excepciones

Se realizan ajustes en el código para capturar los errores en cada función usando tuplas.

Captura de pantalla 2024-11-06 a la(s) 9 37 59 p m

Captura de pantalla 2024-11-06 a la(s) 9 35 08 p m

Captura de pantalla 2024-11-06 a la(s) 9 36 04 p m

Pruebas

Columnas faltantes en el archivo xlsx, se devuelve un error donde se indica la columna faltante:

Captura de pantalla 2024-11-06 a la(s) 5 50 56 p m

Error del archivo base 64 enviado:

Captura de pantalla 2024-11-06 a la(s) 5 56 44 p m

Error al intentar ajustar el tipo de dato en la función parse_value:

Captura de pantalla 2024-11-06 a la(s) 6 19 04 p m

Se envía un campo requerido vacío y se muestra la columna y el indice del dato:

Captura de pantalla 2024-11-06 a la(s) 7 46 10 p m

Se envía un registro sin errores para verificar la respuesta:

Captura de pantalla 2024-11-06 a la(s) 9 25 50 p m

Ejemplo para datos complementarios (subtarea 3):

{
   "service":"Usuario",
   "endpoint":"/periodos",
   "complement"; {
    "plan_auditoria_id": 18
   },
   "structure":{
      "FechaFin":{
         "posicion":0,
         "required":true
      },
      "FechaInicio":{
         "posicion":1
      },
      "Finalizado":{
         "posicion":2,
         "parse":"booleano",
         "required":true
      },
      "RolId.Id":{
         "posicion":3,
         "parse":"int"
      },
      "UsuarioId.Id":{
         "posicion":4,
         "parse":"int"
      }
   }
}

Estructura de mapeo:

"mapping": {
            "Admin": 1,
            "Auditor Experto": 2,
            "Auditor": 3
         }

Implementación mapping

Se agrega al código la funcionalidad de realizar el mapping cargado en la estructura para tomar los valores cuando se envíen para este caso los roles en texto desde el archivo

Captura de pantalla 2024-11-07 a la(s) 6 38 44 p m

Captura de pantalla 2024-11-07 a la(s) 6 38 54 p m

Se envía el archivo con los datos de prueba y se agrega a la estructura el rol en texto y su respectivo id, se obtiene la respuesta con los registros correctos:

Captura de pantalla 2024-11-07 a la(s) 6 34 02 p m

Captura de pantalla 2024-11-07 a la(s) 6 34 46 p m

Implementación complement

Se crea la función add_complement donde se realiza la actualización del payload:

Captura de pantalla 2024-11-07 a la(s) 8 22 22 p m

Se agrega a la estructura json el complement:

Captura de pantalla 2024-11-07 a la(s) 8 21 39 p m

Se muestra el payload inicial y la actualización con el complement:

Captura de pantalla 2024-11-07 a la(s) 8 20 55 p m

Array en payload

Se agrega la funcionalidad de tomar los encabezados de unas columnas especificas si las celdas no están vacías, estos datos se agregan a un array que adiciona al payload para ser enviado al endpoint posteriormente:

Captura de pantalla 2024-11-09 a la(s) 10 39 42 a m

Captura de pantalla 2024-11-09 a la(s) 10 39 48 a m

Se ajusta el código de validación de las columnas entre la estructura y el archivo para que tome en cuenta las columnas agrupadas en la estructura:

Captura de pantalla 2024-11-09 a la(s) 10 39 27 a m

Validación con datos de prueba:

Se envían campos vacíos y con diferentes valores para validar el funcionamiento:

Captura de pantalla 2024-11-09 a la(s) 10 35 22 a m

Se envía la estructura con los campos agrupados del cronograma:

Captura de pantalla 2024-11-09 a la(s) 10 40 04 a m

Se agrega correctamente al payload los datos necesarios según el archivo enviado:

Captura de pantalla 2024-11-09 a la(s) 10 35 07 a m

Se debe realizar un ajuste para las celdas que tienen un espacio ya que las toma como celdas no vacías. También falta ajustar los nombres de las variables y revisar logs del código.

Muy buen trabajo, dado que no se realizó el despliegue por reagendamiento se cubre la implementación del manejo de arrays adicionalmente al alcance inicial de la tarea. Se deben realizar ajustar para no contar con la key especifica de cronograma_ids. Y ajuste en el nombre de la key nombre_columnas. Para mantener formato similar en la estructura, y un mismo idioma en la parametrización.

udistrital / sisifo_documentacion