ADR  - BACK - FAULT-TOLERANCE - 000001

Estado

 

Partes interesadas

AREA GOBIERNO TECNOLOGICO DESARROLLO SOFTWARE RRHH-WEB (AYESA) DESARROLLO SOFTWARE ECONOMICO-FINANCIERO (NTTDATA) DESARROLLO SOFTWARE ASISTENCIAL (NTTDATA) 

TAGS


Tomada el

28/12/2023

Responsable

CARLOS GONZALEZ SANTIAGO 

Solución Afectada

Todas las implementaciones basadas en microservicios


Responsable

Aprobado por

Consultados

Informados

CARLOS GONZALEZ SANTIAGO

LUIS MARTINEZ FONTIVEROS  

LUIS MARTINEZ FONTIVEROS

FRANCISCO JAVIER PEREZ FERRER DESARROLLO SOFTWARE ASISTENCIAL (NTTDATA) DESARROLLO SOFTWARE RRHH-WEB (AYESA) DESARROLLO SOFTWARE ECONOMICO-FINANCIERO (NTTDATA) 

Asunto a Decidir

Se requiere una decisión sobre la estrategia general de la gestión de las excepciones que llegan a la capa rest de un microservicio.

Identificación de la decisión

Con respecto a este asunto se toman dos decisiones

  • Se utilizarán interceptores para dar una respuesta común a todas las excepciones del mismo tipo dentro de un microservicio
  • Se utilizará la especialización del ExceptionMapper para la implementación de los interceptores de excepciones. (Ejemplo de implementación)
  • Los códigos de errores deben estar alineados con:
    • El contrato de la OTI cuando este defina el servicio
    • El estándar de códigos HTTP cuando el servicio sea definido por el proveedor
  • Las excepciones especializadas en la validación de los parámetros de la request deberán extender de ParameterException (proporcionado por el  módulo kernel del framework)
  • Las excepciones especializadas emitidas desde la capa de negocio, deben extender de BusinessException (proporcionado por el  módulo kernel del framework)
  • Se debe proporcionar una solución reutilizable y que evite la duplicación de código entre microservicios
  • Los interceptores NO son thread safe, por lo que no será posible el uso de variables compartidas. Se debe hacer un uso local de las mismas

Asunto a Decidir

Se requiere una decisión sobre la estrategia general de la gestión de las excepciones que llegan a la capa rest de un microservicio.

Identificación de la decisión

Con respecto a este asunto se toman dos decisiones

  • Se utilizarán interceptores para dar una respuesta común a todas las excepciones del mismo tipo dentro de un microservicio
  • Se utilizará la especialización del ExceptionMapper para la implementación de los interceptores de excepciones. (Ejemplo de implementación)
  • Los códigos de errores deben estar alineados con:
    • El contrato de la OTI cuando este defina el servicio
    • El estándar de códigos HTTP cuando el servicio sea definido por el proveedor
  • Las excepciones especializadas en la validación de los parámetros de la request deberán extender de ParameterException (proporcionado por el  módulo kernel del framework)
  • Las excepciones especializadas emitidas desde la capa de negocio, deben extender de BusinessException (proporcionado por el  módulo kernel del framework)
  • Se debe proporcionar una solución reutilizable y que evite la duplicación de código entre microservicios
  • Los interceptores NO son thread safe, por lo que no será posible el uso de variables compartidas. Se debe hacer un uso local de las mismas

Contexto




Se consideró el uso de try catch dentro del código de endpoint. Se descarto por :

  • Aumento de la dificultad de la legibilidad del código
  • Duplicación de código, para el mismo tipo de excepción en los diferentes endpoints del microservicio.

Uso de interceptores

  • Se debe proporcionar una solución reutilizable y horizontal
  • Hay que tener un control minucioso de las excepciones
  • Hay que personalizar las excepciones de negocio para tener un mejor control

Inicial