Cuando queremos interoperar varios sistemas independientes hay un tema de vital importancia que puede ser un auténtico quebradero de cabeza si no se gestiona correctamente desde la propia definición de las comunicaciones, que es la gestión de errores.
Porque, aunque tengamos nuestra implementación muy bien hecha, es imprescindible que la definición de los servicios, llamadas, protocolos, … tenga soporte a errores para poder ser consistentes. Y, ¿por qué es tan crítico en este tipo de sistemas? Si en todo software tenemos gestión de errores, pruebas, validaciones, ¿qué tiene de especial cuando interoperamos?.
La diferencia es que en este caso estamos comunicando sistemas distintos, fabricados por empresas / personas distintas en distintos momentos, con distintas tecnologías y que pueden estar ubicados en sitios distintos con distintos tiempos de respuesta.
Vamos a poner un ejemplo del mundo físico y luego veremos cómo se puede trasladar a la hora de conectar distintas plataformas. Supongamos, por ejemplo, que queremos mandar una carta de la que esperamos respuesta. Es bastante fácil (posiblemente falten pasos): escribir la carta, indicar el destinatario, echarla al buzón, recogida del buzón, clasificación y transporte, reparto, recogida por parte del destinatario, lectura y los mismos pasos en sentido inverso para la respuesta. Este proceso puede fallar en muchos puntos: escribir mal el destinatario, que el buzón se queme, la carta se pierde: al recogerla, en el centro de proceso o al repartirla, el destinatario no escribe respuesta, y lo mismo para la carta de respuesta. ¿Parece improbable verdad? Pues no lo es tanto en el mundo digital porque en informática hablamos de millones y millones de transacciones y de comunicaciones donde puede pasar de todo. Porque los fallos, queramos o no, se van a producir y hay que estar preparados ante ellos y ante sus consecuencias: pérdida de información, peticiones replicadas, envíos incorrectos, ….
En informática hablamos de millones y millones de transacciones y de comunicaciones donde puede pasar de todo
Cada sistema tiene sus necesidades y sus requerimientos, y una petición duplicada, por ejemplo, puede no ser relevante en una petición de información, pero si estamos haciendo un pago sí que tenemos consecuencias y aumenta la complejidad de las comunicaciones.
Ya tenemos claro que vamos a tener errores y que tenemos que estar cubiertos. Afortunadamente, hace bastante que existen los protocolos de comunicaciones y casi todos los sistemas se basan, más o menos, en los estándares básicos (TCP, UPD, FTP, …) para poder establecer la lógica de los mensajes a intercambiar: petición, respuesta, confirmación, disponibilidad, validación.
Basándonos en estos protocolos podemos definir y construir nuestros sistemas para minimizar las consecuencias de los errores ya que ésta debe ser la base de la arquitectura: la plataforma que tengamos debe ser resistente a errores sin duplicidades ni pérdidas de información.
El enfoque contrario (enfoque optimista) es incorrecto porque acarrea más trabajo y es mucho más difícil de cubrir todos los casos: si construimos una plataforma confiando en que va todo bien y los errores son las excepciones lo más probable es que no sea 100% fiable y costará mucho más fabricarla.
Por tanto, tenemos que el error se puede producir:
- En la fabricación del mensaje
- En el envío del mensaje (caída de la red, dirección incorrecta, …)
- En el proceso del mensaje por el destinatario: le llega, pero no lo entiende
- En la fabricación de la respuesta
- En el envío de la respuesta
- En la lectura de la respuesta
Y estos errores en un sistema con infinidad de llamadas, que no puede parar y que no puede perder o duplicar información.
Veamos una forma de enfocarlo, por supuesto no es la única y está descrita a muy alto nivel.
Hemos comentado que por defecto nuestros mensajes fallan, por tanto, de alguna manera tenemos que almacenar todo lo que enviamos o ser capaces de poder reconstruir el mensaje a partir de la información de que disponemos. Normalmente, lo guardamos hasta que estamos seguros de que el mensaje ha sido procesado por el destinatario, o también podemos guardar todo lo que se envía para siempre, pero eso está más relacionado con auditorías que con control de errores.
El caso fácil ya lo tenemos: generamos mensaje, lo guardamos como “no procesado” y cuando recibimos respuesta correcta, lo marcamos como procesado o lo borramos de nuestra “fila de mensajes”. ¿Y si no recibimos respuesta o la respuesta no es lo que se espera? Pues tendríamos que reintentar, igual que haríamos en el caso de la carta, pero teniendo en cuenta varias consideraciones:
- No seamos demasiado insistentes. Si el destinatario está de vacaciones o de año sabático, no mandemos una carta cada semana. En este caso sucede lo mismo. Si sabemos que hay un error y lo están arreglando, no tiene ningún sentido bombardear a peticiones al sistema destino porque podemos aumentar sus problemas o aparecer en listas de “remitentes no deseados”
- Intentar averiguar el motivo del rechazo. En ocasiones el mensaje de respuesta puede aportar información sobre los motivos del error, como que nuestra petición es incorrecta o que faltan datos, por ejemplo. En este caso, antes de reintentar es necesario corregir nuestros errores
- Preguntar antes de reintentar. Este caso sería como llamar por teléfono para comprobar si ha llegado la carta. Puede parecer un poco absurdo, pero viene bien en casos como los pagos o envíos que solo deben realizarse una sola vez o que tienen consecuencias en cada envío
Todas estas posibilidades complican la gestión de los errores, pero aumentan el nivel de robustez de nuestro sistema ante cualquier pérdida de información.
Añadamos un punto más de complejidad. En ocasiones los errores (del remitente o del destinatario) se pueden resolver de forma automática (por ejemplo, un reinicio) pero hay ocasiones en que es necesaria intervención humana. Si tenemos 10 mensajes al día, no hay problema, pero si tenemos 10.000 hay que buscar alguna manera de automatizarlo, ya que normalmente el equipo técnico y el equipo de soporte a usuarios son distintos. Hay que buscar la forma de hacer entendible el error para que el responsable de tratar el error pueda comprenderlo y resolverlo si llega el caso.
Por tanto, como listado final para la resolución de errores, podemos destacar que:
- Los sistemas van a fallar, y tenemos que construir nuestros sistemas en base a esa premisa
- Podemos saber dónde está el fallo o podemos no saberlo. Hay que garantizar que no se pierde información y que no se envían duplicidades en mensajes críticos
- Se deben definir estrategias ante los posibles errores
- Podemos automatizar al máximo la gestión de los errores y su traslado a otros departamentos
Al final el tratamiento de los errores en las comunicaciones tiene un equivalente similar al mundo físico, pero lo que lo hace mucho más difícil son los números que se manejan y que al final todo está hecho por personas que nos equivocamos en mayor o menor medida hasta conseguir unos sistemas perfectamente ajustados.
