Antes de conectar, escucha a quien hace el trabajo
Imagina a una persona que recibe pedidos en la web, los copia en una herramienta de facturación y después organiza las entregas en un calendario. Conoce el proceso de memoria. También sabe qué hacer cuando un cliente cambia de idea, aunque ese paso nunca se haya escrito en ningún sitio.
Antes de automatizar, vale la pena sentarse con ella. ¿Cuándo está listo un pedido para facturarse? ¿Qué pasa si cambia la fecha o se cancela? Escuchar esas respuestas ayuda a entender el trabajo que quiero facilitar. La elección de una API o de una herramienta puede esperar un poco.
Empezaría por una parte pequeña: al aprobar un pedido, enviar la solicitud de facturación y guardar su referencia. Así puedo seguir un caso completo, revisar contigo lo que ocurre y corregirlo antes de conectar el resto.
Que cada dato tenga un lugar claro
En este ejemplo, la web puede guardar el pedido, la herramienta de facturación controlar la factura y el calendario recibir lo necesario para preparar la entrega. Otro negocio necesitará repartir esas tareas de otra manera. Lo importante es que el equipo sepa dónde consultar y dónde corregir cada dato.
Daría al pedido una referencia que se conserve en las tres herramientas. Buscarlo por el nombre del cliente puede resultar confuso: dos personas pueden llamarse igual. Una referencia común permite responder «esta es su factura y esta es su entrega» sin abrir varias pestañas para adivinar cuál corresponde.
Cuando algo falla, alguien necesita saber qué hacer
Una petición puede quedarse sin respuesta aunque la operación se haya completado. Repetirla sin comprobarlo podría crear otro registro. Amazon explica cómo un identificador de solicitud permite reconocer los reintentos de una misma operación. A esa propiedad se le llama idempotencia: repetir la solicitud no debería repetir su efecto.Amazon Builders’ Library: reintentos e idempotencia ↗
Vuelvo al ejemplo de la factura. Intentar crearla de nuevo porque no llegó la respuesta es distinto de pedir otra factura. Antes de añadir reintentos automáticos, hay que comprobar si la herramienta receptora permite reconocer esa diferencia. Si no lo permite, hace falta una forma de consultar lo ocurrido o revisar el caso.
También me importa quien espera al otro lado. Si la facturación deja de responder, esa persona necesita ver qué pedidos siguen pendientes y cómo retomarlos. Un mensaje comprensible y una acción clara le sirven más que un error escondido en un archivo que solo sabe leer el equipo técnico.
Poder explicar de dónde salió un dato
En Healthier desarrollé un validador para detectar duplicados y conservar referencias al archivo de origen y a los datos extraídos. Esa relación permite volver al origen cuando hace falta revisar un resultado. Es una parte de ese trabajo que me interesa llevar a otras integraciones: poder explicar de dónde viene la información.
Para los pedidos del ejemplo, guardaría la referencia de origen, la acción solicitada, la respuesta y el estado. Con ese contexto se puede investigar sin empezar de cero. También cuidaría qué información queda guardada: quiero entender el proceso y respetar la privacidad de quienes aparecen en él.
Probarlo junto a quien lo va a usar
Tomaría un pedido de prueba y lo seguiría hasta la entrega. Después repetiría un intento de facturación, cambiaría un dato y simularía una interrupción. Junto con el equipo, revisaría si se entiende qué pasó y si hay una forma de continuar. Ese momento puede mostrar detalles que el diagrama no mostraba.
Antes de sumar otra conexión, dejaría claro quién la mantiene y dónde pedir ayuda. Me interesa que una integración le quite trabajo al equipo y que, cuando algo se detenga, nadie tenga que sentirse perdido frente a una pantalla. Esa también es una parte del desarrollo que merece cuidado.