Siempre me ha resultado curioso el comprobar que algo que llevas haciendo desde hace tiempo,a alguien se le ha ocurrido ponerle un nombre (¿cómo llamáis al cacharro que usan en las heladerías para hacer las bolas de helado para los cucuruchos? Yo lo llamaba “hacedor de bolas”, hasta que a un amigo se le ocurrió bautizarlo como “Chilaguillo”). Esta misma sensación la ha tenido leyendo teoría de patrones de diseño y de repente decir, anda, pero si esto lo llevo haciendo de hace tiempo, no sabía que era un patrón. Bueno, para ser sinceros, me ha pasado más veces con los anti-patrones que con los patrones 🙂
Esta semana, en el curso de Biztalk, me ha vuelto a pasar, resulta que una de las opciones que incluye la herramienta es la de incorporar actividades de compensación, algo que, venía haciendo desde tiempo atrás, sin saber que tenía ese nombre.
Un código o una acción de compensación se puede contemplar cuando estamos realizando una incursión en un entorno no transaccional, donde aplicamos cambios sobre diferentes orígenes de datos. Si en alguno de los puntos se produce un error, podríamos no disponer de la posibilidad de volver todo al estado inicial de forma automática y con total seguridad de que se va a hacer de forma correcta (lo que sería una transacción de base de datos por ejemplo, o utilizando el componente de transacciones distribuidas de Microsoff el MSDTC).
Si no lo podemos resolver de forma automática, algo tendremos que hacer para que nuestro conjunto de datos no quede en un estado inconsistente. ¿Y qué podemos hacer? Pues muy fácil, compensar el error 🙂
Por poner un ejemplo algo gráfico, imaginaos una aplicación donde al pulsar un botón de “Iniciar Proceso” se lleven a cabo una serie de acciones que implican la creación de ciertos registros a través de servicios web pertenecientes a diferentes proveedores. Podría darse el caso que alguno fallara, cuando una llamada a un servicio anterior ya ha sido confirmada. En ese caso, en el bloque “catch” correspondiente, tendríamos que comprobar cuál ha sido la llamada que ha fallado e intentar volver a su estado inicial las acciones que ya teníamos confirmadas. Nos iría estupendo por ejemplo con contar métodos dentro de los mismos servicios web que nos permitieran volver atrás la acción (si hemos hecho una inserción, pues disponer de un método para hacer el borrado). Aunque también caben otro tipo de compensaciones que aunque a primera vista no parezcan muy elaboradas pueden dar muy buenos resultados, como enviar un e-mail a un administrador indicando en que punto del proceso se ha producido el fallo, o incorporar una entrada en el monitorizador de eventos del servidor para que salte la alerta automáticamente a los responsables del sistema, resolviendo el usuario el problema de forma manual.
Un saludo.
Miguel.