Quan volem interoperar diversos sistemes independents hi ha un tema de vital importància que pot ser un autèntic maldecap si no es gestiona correctament des de la pròpia definició de les comunicacions, que és la gestió d’errors.
Perquè, encara que tinguem la nostra implementació molt ben feta, és imprescindible que la definició dels serveis, trucades, protocols… tingui suport a errors per poder ser consistents. I, per què és tan crític en aquest tipus de sistemes? Si en tot programari tenim gestió d’errors, proves, validacions, què té d’especial quan interoperem?.
La diferència és que en aquest cas estem comunicant sistemes diferents, fabricats per empreses / persones diferents en diferents moments, amb diferents tecnologies i que poden estar ubicats en llocs diferents amb diferents temps de resposta.
Posarem un exemple del món físic i després veurem com es pot traslladar a l’hora de connectar diferents plataformes. Suposem, per exemple, que volem enviar una carta de la qual esperem resposta. És bastant fàcil (possiblement faltin passos): escriure la carta, indicar el destinatari, llançar-la a la bústia, recollida de la bústia, classificació i transport, repartiment, recollida per part del destinatari, lectura i els mateixos passos en sentit invers per a la resposta. Aquest procés pot fallar en molts punts: escriure malament el destinatari, que la bústia es cremi, la carta es perd: en recollir-la, en el centre de procés o en repartir-la, el destinatari no escriu resposta, i el mateix per a la carta de resposta. Sembla improbable veritat? Doncs no ho és tant al món digital perquè en informàtica parlem de milions i milions de transaccions i de comunicacions on pot passar de tot. Perquè les fallades, vulguem o no, es produiran i cal estar preparats davant d’elles i davant de les seves conseqüències: pèrdua d’informació, peticions replicades, enviaments incorrectes, ….
En informàtica parlem de milions i milions de transaccions i de comunicacions on pot passar de tot
Cada sistema té les seves necessitats i els seus requeriments, i una petició duplicada, per exemple, pot no ser rellevant en una petició d’informació, però si estem fent un pagament sí que tenim conseqüències i augmenta la complexitat de les comunicacions.
Ja tenim clar que tindrem errors i que hem d’estar coberts. Afortunadament, fa bastant que existeixen els protocols de comunicacions i gairebé tots els sistemes es basen, més o menys, en els estàndards bàsics (TCP, UPD, FTP…) per poder establir la lògica dels missatges a intercanviar: petició, resposta, confirmació, disponibilitat, validació.
Basant-nos en aquests protocols podem definir i construir els nostres sistemes per minimitzar les conseqüències dels errors ja que aquesta ha de ser la base de l’arquitectura: la plataforma que tinguem ha de ser resistent a errors sense duplicitats ni pèrdues d’informació.
L’enfocament contrari (enfocament optimista) és incorrecte perquè porta més treball i és molt més difícil de cobrir tots els casos: si construïm una plataforma confiant que va tot bé i els errors són les excepcions el més probable és que no sigui 100% fiable i costarà molt més fabricar-la.
Per tant, tenim que l’error es pot produir:
- En la fabricació del missatge
- En l’enviament del missatge (caiguda de la xarxa, direcció incorrecta, …)
- En el procés del missatge pel destinatari: li arriba, però no ho entén
- En la fabricació de la resposta
- En l’enviament de la resposta
- En la lectura de la resposta
I aquests errors en un sistema amb infinitat de trucades, que no pot parar i que no pot perdre o duplicar informació.
Vegem una manera d’enfocar-lo, per descomptat no és l’única i està descrita a molt alt nivell.
Hem comentat que per defecte els nostres missatges fallen, per tant, d’alguna manera hem d’emmagatzemar tot el que enviem o ser capaços de poder reconstruir el missatge a partir de la informació que disposem. Normalment, el guardem fins que estem segurs que el missatge ha estat processat pel destinatari, o també podem guardar tot el que s’envia per sempre, però això està més relacionat amb auditories que amb control d’errors.
El cas fàcil ja el tenim: generem missatge, el guardem com a "no processat" i quan rebem resposta correcta, el marquem com a processat o l’esborrem de la nostra "fila de missatges". I si no rebem resposta o la resposta no és el que s’espera? Doncs hauríem de tornar a intentar, igual que faríem en el cas de la carta, però tenint en compte diverses consideracions:
- No siguem massa insistents. Si el destinatari és de vacances o d’any sabàtic, no enviem una carta cada setmana. En aquest cas succeeix el mateix. Si sabem que hi ha un error i l’estan arreglant, no té cap sentit bombardejar a peticions al sistema destí perquè podem augmentar els seus problemes o aparèixer en llistes de "remitents no desitjats"
- Intentar esbrinar el motiu del rebuig. En ocasions el missatge de resposta pot aportar informació sobre els motius de l’error, com que la nostra petició és incorrecta o que falten dades, per exemple. En aquest cas, abans de tornar a intentar és necessari corregir els nostres errors
- Preguntar abans de tornar a intentar. Aquest cas seria com trucar per telèfon per comprovar si ha arribat la carta. Pot semblar una mica absurd, però ve bé en casos com els pagaments o enviaments que només han de realitzar-se una sola vegada o que tenen conseqüències en cada enviament
Totes aquestes possibilitats compliquen la gestió dels errors, però augmenten el nivell de robustesa del nostre sistema davant de qualsevol pèrdua d’informació.
Afegim un punt més de complexitat. En ocasions els errors (del remitent o del destinatari) es poden resoldre de forma automàtica (per exemple, un reinici) però hi ha ocasions en què és necessària intervenció humana. Si tenim 10 missatges al dia, no hi ha problema, però si en tenim 10.000 cal buscar alguna manera d’automatitzar-lo, ja que normalment l’equip tècnic i l’equip de suport a usuaris són diferents. Cal buscar la manera de fer comprensible l’error perquè el responsable de tractar l’error pugui comprendre-ho i resoldre-ho si arriba el cas.
Per tant, com a llista final per a la resolució d’errors, podem destacar que:
- Els sistemes fallaran, i hem de construir els nostres sistemes partint d’aquesta premissa
- Podem saber on és la fallada o podem no saber-ho. Cal garantir que no es perd informació i que no s’envien duplicitats en missatges crítics
- S’han de definir estratègies davant dels possibles errors
- Podem automatitzar al màxim la gestió dels errors i el seu trasllat a altres departaments
Al final el tractament dels errors en les comunicacions té un equivalent similar al món físic, però el que ho fa molt més difícil són els números que es manegen i que al final tot està fet per persones que ens equivoquem en una mesura o una altra fins a aconseguir uns sistemes perfectament ajustats.
