Tres preguntas que definen el patrón, no la herramienta
El error más común al seleccionar una integración para Salesforce es comenzar por la herramienta: MuleSoft, Platform Events, Bulk API o un simple Webhook. La herramienta es una consecuencia, no un punto de partida. Tres preguntas clave determinan el patrón adecuado:
- ¿Qué tan rápido necesita saber la otra parte? Un segundo, un minuto, una hora o un día: esta es la diferencia entre Real-Time y Batch.
- ¿Quién es el propietario del dato en cada momento? Si la respuesta no es inequívoca, ningún patrón técnico resolverá el problema.
- ¿Qué sucede cuando la otra parte no está disponible? Una respuesta como "esperaremos de nuevo" no es una respuesta; se necesita un comportamiento definido: Retry, cola o fallo explícito.
Quien responde estas tres preguntas antes de seleccionar una tecnología, casi siempre llega a la misma conclusión a la que llegaría un arquitecto experimentado, pero sin incurrir en costos de prueba y error en producción. Una ampliación sobre la conexión entre esta decisión y la arquitectura general se encuentra en la Guía de Arquitectura CRM.
Mapa de Patrones: Cuándo es adecuado cada uno
| Patrón | Tiempo de respuesta típico | Ejemplo de uso típico | Costo de mantenimiento | Riesgo principal |
|---|---|---|---|---|
| Request-Reply síncrono | Milisegundos a segundos | Verificación de crédito antes de aprobar una transacción en pantalla | Moderado | Un Timeout bloquea al usuario |
| Fire-and-Forget | Inmediato en el envío, sin esperar resultado | Envío de un evento para crear una Tarea en otro sistema | Bajo-Moderado | Fallo silencioso sin monitoreo |
| Batch periódico | Horas a un día | Sincronización diaria del catálogo de productos desde el ERP | Bajo | Discrepancias temporales entre sistemas |
| CDC (Change Data Capture) | Segundos a minutos | Actualización del estado de un pedido que afecta al soporte | Moderado-Alto | Carga en el Event Bus con múltiples cambios |
| Event-Driven (Platform Events / Pub-Sub) | Segundos | Notificación de un evento de negocio a varios consumidores simultáneamente | Alto en el setup, bajo en mantenimiento | Requiere disciplina de Schema y Versioning |
La tabla es un punto de partida para la discusión, no una decisión final. Un sistema puede, y a veces debe, utilizar varios patrones en paralelo según el tipo de dato.
Por qué la latencia no es suficiente para decidir
El segundo error común: decidir únicamente por la latencia e ignorar la consistencia. Un patrón rápido que actualiza solo una parte y deja a la otra "casi sincronizada" genera un problema más grave que un patrón lento pero consistente, porque los usuarios aprenden a no confiar en el dato y, en consecuencia, eluden el sistema.
La pregunta correcta es doble: ¿qué tan rápido se requiere la respuesta y cuán grave es una situación en la que ambas partes no están sincronizadas por un momento? Un proceso de cotización presentado a un cliente requiere tanto velocidad como consistencia total; aquí se necesita un Request-Reply síncrono con un Timeout definido y un manejo explícito de fallos. La actualización del "número de vistas de un artículo" puede permitirse un retraso de minutos; en este caso, Fire-and-Forget o CDC son suficientes.
Propiedad de los datos: Una decisión que precede a cualquier patrón
Antes de elegir cómo se transfieren los datos entre los sistemas, es fundamental decidir dónde reside el "dato fuente". Un campo que se actualiza en dos sistemas sin un propietario definido crea un bucle de sincronización: A envía a B, B actualiza y retransmite a A, A envía de nuevo. Esto no es un escenario extremo; es el resultado esperado de una sincronización bidireccional sin reglas de resolución.
Una regla de trabajo práctica: a cada campo compartido se le asigna un único propietario (Owner). Si existe una necesidad empresarial real de edición desde ambas partes (por ejemplo, el servicio de atención al cliente actualiza una dirección tanto en Salesforce como en el ERP), se agrega una regla de Conflict Resolution explícita: el último Timestamp prevalece, o un campo determina y el otro es solo para visualización. La gestión de permisos en torno a estos campos sensibles se aborda en la Guía del Modelo de Permisos en Salesforce.
Manejo de fallos: La prueba que la mayoría de los proyectos omiten
Casi todas las integraciones se prueban en el "Happy Path". Pocas realizan una prueba sistemática de los siguientes tres escenarios de fallo:
- El segundo sistema no está disponible en el momento del envío ¿El mensaje se guarda en una cola y se reenvía, o se pierde?
- El mensaje llega dos veces (problema común en Retry automático y en el Event Bus) ¿El receptor crea un registro duplicado?
- El mensaje llega en un orden incorrecto ¿La actualización del estado "cancelado" que llega antes que "aprobado" causa un resultado erróneo?
Un sistema que no está construido como Idempotente (identificador único para cada mensaje + verificación si ya fue procesado) fallará precisamente en los dos primeros escenarios, y generalmente bajo carga, es decir, justo cuando el negocio más depende de él. Las limitaciones de la API y cómo lidiar con el Throttling en este contexto se detallan en la Guía de Salesforce API Limits.
Marco de decisión: De la pregunta de negocio al patrón
| Pregunta inicial | Si la respuesta es "Sí" | Si la respuesta es "No" |
|---|---|---|
| ¿El usuario está esperando en pantalla el resultado de la integración? | Request-Reply síncrono con Timeout definido | Pasamos a la siguiente pregunta |
| ¿Se requiere una actualización en pocos minutos de un cambio específico? | CDC o Platform Event | Pasamos a la siguiente pregunta |
| ¿Varios consumidores diferentes necesitan conocer el mismo evento? | Event-Driven con Pub-Sub | Pasamos a la siguiente pregunta |
| ¿Es conveniente procesar un gran volumen en una ventana de tiempo fija? | Batch periódico | Considerar Fire-and-Forget con cola |
Este es un punto de partida para la discusión en una reunión de arquitectura, no una fórmula exhaustiva. Siempre existen casos límite (por ejemplo, un volumen masivo que requiere CDC pero también una reconciliación Batch diaria como red de seguridad).
Escenario de ejemplo: Cadena de clínicas privadas con veinte sucursales
Supongamos una cadena de clínicas que utiliza Salesforce para la gestión de solicitudes de pacientes y un sistema de facturación separado (Billing) que, por el momento, no puede ser reemplazado. El requisito: cuando un paciente completa una cita, el sistema de facturación debe actualizarse inmediatamente, y cuando una facturación se actualiza (por ejemplo, se recibe un pago), Salesforce debe reflejarlo para que el representante de servicio no solicite un pago duplicado.
La elección inicial del equipo fue un Batch nocturno bidireccional, simple de configurar, pero que generó una brecha de hasta 24 horas en la que los representantes veían información desactualizada, lo que provocó quejas. La solución finalmente adoptada: una dirección (finalización de cita desde Salesforce a facturación) pasó a Fire-and-Forget con una cola de mensajes y Retry automático, ya que el usuario no necesita esperar. La otra dirección (confirmación de pago desde facturación a Salesforce) pasó a CDC, ya que se trata de un cambio puntual que debe llegar en minutos. El Batch nocturno se mantuvo solo como un mecanismo de Reconciliación: una comparación diaria que detecta discrepancias y emite alertas, no como el canal de actualización principal.
El resultado: el tiempo de actualización se redujo de horas a minutos, y el mecanismo de Reconciliación detectó dos casos de mensajes perdidos en el primer mes, cumpliendo exactamente su función.
Riesgos y acciones preventivas específicas para la integración
| Riesgo | Cómo se manifiesta en la práctica | Acción preventiva |
|---|---|---|
| Falta de Idempotencia | Registros duplicados después de Retry o fallas de red | Identificador único para el mensaje + verificación antes de crear |
| Fuente de verdad indefinida | Bucle de sincronización o actualización "ganadora" aleatoria | Propietario definido para cada campo + regla de Conflict Resolution |
| Point-to-Point sin capa de integración | Cualquier cambio de esquema en un sistema rompe otra conexión | Capa de Middleware/API con contrato de versiones explícito |
| Monitoreo solo técnico | La integración está "en verde" pero faltan pedidos en la práctica | Métrica de Reconciliation de negocio, no solo Uptime técnico |
| Ignorar Governor Limits | La integración colapsa precisamente bajo carga máxima | Planificación de Bulkification y Backoff de antemano, no como reacción |
Checklist para la selección del patrón de integración
- ☐ Se definió el tiempo de respuesta requerido en números, no con la palabra "rápido".
- ☐ Se definió un único Owner para cada campo compartido entre los sistemas.
- ☐ Se verificó qué sucede cuando la otra parte no está disponible, y se documentó.
- ☐ Se verificó qué sucede cuando un mensaje llega dos veces.
- ☐ Se verificó qué sucede cuando los mensajes llegan en un orden incorrecto.
- ☐ Existe un mecanismo de Reconciliation incluso cuando el patrón principal es asíncrono.
- ☐ Las limitaciones de la API y los Governor Limits se verificaron contra el volumen esperado bajo carga máxima.
- ☐ Se definieron métricas de éxito de negocio, no solo métricas técnicas.
Métricas para el monitoreo continuo de la integración
Después del lanzamiento, es recomendable monitorear solo tres o cuatro métricas: el porcentaje de mensajes exitosos en el primer intento, el tiempo de extremo a extremo real frente al SLA definido, las diferencias diarias de Reconciliation entre los sistemas y la proximidad a los límites de la API. Un aumento constante en cualquiera de ellos –y no solo una desviación puntual– es la señal para considerar la transición a otro patrón, antes de que el sistema falle en producción. Las consideraciones de identidad y permisos de acceso entre sistemas se detallan en la Guías de SSO e Identidad en Salesforce.
Resumen
La selección de un patrón de integración adecuado no comienza con la pregunta "¿qué herramienta?", sino con tres preguntas: ¿qué tan rápido se necesita una respuesta?, ¿quién es el propietario del dato? y ¿qué sucede cuando algo falla? Real-Time es apropiado cuando un usuario espera un resultado; CDC y Event-Driven son adecuados para la actualización rápida de un cambio específico o para la distribución a varios consumidores; Batch es idóneo para grandes volúmenes en una ventana de tiempo fija. En cada patrón, la Idempotencia, la propiedad definida de los datos y un mecanismo de Reconciliation no son "deseables", son la condición para que la integración soporte una carga real y no solo una demostración.
Recursos profesionales
- Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – Arquitectura CRM — https://hpi.pro/crm-architecture
- HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data