No creo que sea casualidad que, en cada nueva versión, Salesforce introduzca mejoras sustanciales, a la permeabilización de sus datos y en especial, intentar hacerlo de forma eficiente, estándar y cada vez más simple.
Hasta hace relativamente pocos años, la integración entre Salesforce y sistemas externos, estaba limitada a unos escenarios concretos y a unas APIs reducidas.
Esto ha cambiado completamente, acuciado por, la tendencia de las empresas a establecer lo que denominamos Golden Record, es decir NO tener N repeticiones del mismo registro, con inconsistencia entre ellos, muchas veces debido a los caprichos/silos de negocios y abordar una estrategia del gobierno del dato.
Esto supone la dispersión/desfiguración/falsedad de los datos, que para muchas empresas supone la pérdida de competitividad y mayor valor.
Por tanto, esta entrada pretender enumerar, las diferentes opciones arquitectónicas que existen (no todas), para comunicar los cambios en nuestros datos existentes en Salesforce a otros sistemas externos.
No es objetivo ni tiene sentido discutir si el Golden Record de la empresa debe estar en Salesforce o en un sistema onPremise, o Cloud público etc., ya que cada empresa, es un mundo y razones distintas para ubicarlo donde considere.
Escenarios de Arquitectura
Lo primero que sorprende, es la versatilidad (confusión) de escenarios de arquitectura que disponemos en Salesforce.
Como se han añadido paulatinamente, existe cierto solape entre ellas, ya que Salesforce reutiliza la implementación anterior, para proporcionar otra nueva, y además cambiando la nomenclatura.
La lista de alternativas, evitando combinaciones entre ellas, que conformarían una lista demasiado larga es:
- Acceso a Servicios Externos mediante API expuesta por el sistema destino
- Lógica de detección de cambios + Callouts a API de sistema externo
- Replicación mediante Queries ad-hoc:
- SOQL con comunicación ad-hoc al sistema destino
- Replicación nativa por detección de cambios
- Uso de Replication API
- Mediante herramientas intermediarias
- Data Loader en CLI en cadena automatizada
- Mediante Herramienta ETL (Informatica Cloud, Jitterbit, etc.)
- Salesforce Connect mediante adaptador con oData 4.0
- Escritura en BD destino mediante bridge REST
- Heroku Connect
- Arquitectura Basada en Eventos (modelo Pub/Sub)
- Uso de Streaming API
- Uso de Change Data Capture nativo en Salesforce
Requerimientos a considerar
Estos escenarios aunque parecen muchos, tienen casos de uso a los que dan respuesta más adecuada en cada caso. Para describirlos de manera uniforme, se utilizarán los siguientes conceptos:
Train Change
Se requiere que todos los cambios que se producen sobre el registro, se comuniquen, o por el contrario, solo se requiere el estado final del registro (el más reciente).
Ventana de caducidad
¿Qué espacio temporal tiene la ventana de caducidad del cambio? Es decir, ¿Se requiere que el cambio se comunique en tiempo real, Near Real time, o la ventana de validez es diaria, mensual, etc.?
Volumen de datos
Volumetría de los registros (y/o de cambios sobre el registro en caso de Train Change) que van a sufrir cambios durante la ventana de caducidad.
Comunicación orientada a Evento u orientada sistema destino concreto
La comunicación del cambio se realiza mediante la comunicación de un evento, donde N receptores, posiblemente desconocidos, se han suscrito a recibir esa información, o tenemos una comunicación con un sistema destino conocido (no necesariamente acoplado) con el que intercambiamos información.
Dificultad y coste
Toda solución tecnológica tiene muchos costes asociados, pero se evaluarán subjetivamente los 3 más generalizados, que además son el grueso de un cálculo de TCO.
Coste de Implementación
Valoración subjetiva sobre la complejidad que tendrá el equipo encargado o equipos encargados de la implementación.
Coste de Implantación
Valoración subjetiva del coste, que conlleva situar la implementación en un entorno productivo.
Coste de Mantenimiento
Valoración subjetiva del coste, que conlleva mantener, modificar y gestionar la implementación en un entorno productivo.
A continuación se muestra una tabla muy resumida de lo que implica cada escenario respecto a los conceptos establecidos.
Entradas posteriores detallaran cada uno de estos conceptos y casos de uso adecuados a cada escenario.
| Train Change, Ventana, Volumetría, Orientado a Eventos y Costes | |
|---|---|
| Lógica + Callout | Train Change: altamente complejo Ventana: ad-hoc, condicionada por el tiempo de ejecución de la llamada al servicio Volumetría: con alta volumetría se producen solapes de ejecución Eventos: Ad-hoc, con alta volumetría se producen solapes Implementación: Bajo Implantación: Medio Mantenimiento: Medio |
| SQL Ad-hoc | Realizar consultas SOQL que con las condiciones que consideremos obtiene los cambios en los registros. Una vez detectados deben enviarse al destino. Siempre es un escenario alternativo al uso de Replication API.
Train Change: no aplica |
| Replication API | Train Change: no aplica Ventana: ad-hoc, condicionada por la planificación que realicemos (solape entre ejecuciones) Volumetría: con alta volumetría se producen solapes de ejecución Eventos: no aplica Implementación: Medio Implantación: Bajo Mantenimiento: BajoArtículo disponible: Replication API para identificar cambios |
| Data Loader | Planificación de extracciones de objetos, basado en condiciones via CLI.
Train Change: no aplica Artículos disponibles: BULK API 2.0 y BULK API via CLI |
| Herramienta ETL | Train Change: no aplica Ventana: Ad-hoc, condicionada por la planificación que realicemos (solape entre ejecuciones) Volumetría: con alta volumetría se producen solapes de ejecución Eventos: no aplica Implementación: Medio Implantación: alto (costes de adquisición y soporte) Mantenimiento: bajo (dependiendo de la complejidad de los flujos implementados) |
| Salesforce Connect | Train Change: dado que no hay replicación de datos, en el momento de acceso, se ve el estado del registro. Si se lanzan queries contra el objeto remoto, se obtiene su estado actual, y por tanto no hay train change. Ventana: no aplica en acceso. Si se lanzan consultas contra el objeto remoto se obtiene el valor al instante Volumetría: con alta volumetría se producen latencias muy elevadas o queries con resultados no superiores > 2000 registros. Eventos: no aplica Implementación: Bajo Implantación: Medio (coste de Salesforce Connect y otros adaptadores necesarios) Mantenimiento: BajoArtículos disponibles: Salesforce Connect para acceder Datos externos |
| Bridge Rest | Train Change: depende de la frecuencia del envio de datos, cona alta volumetría se producen solapes de ejecuciones Ventana: Ad-hoc, condicionada por la planificación que realicemos (solape entre ejecuciones) Volumetría: con alta volumetría se producen latencias elevadas. Eventos: no aplica Implementación: Media (dado que en la BD destino deberán establecerse políticas de gestión de errores e ingesta masiva) Implantación: Media (dependiendo del coste del Bridge) Mantenimiento: MedioArtículos disponibles: Salesforce Connect para acceder Datos externos |
| Heroku Connect | Train Change: depende de la frecuencia del envio de datos, cona alta volumetría se producen solapes de ejecuciones Ventana: Ad-hoc, condicionada por la planificación que realicemos (solape entre ejecuciones) Volumetría: con alta volumetría se producen solapes de ejecución Eventos: no aplica Implementación: Bajo en el lado de Heroku pero incierto en el lado de la base de datos destino Implantación: Bajo Mantenimiento: Medio |
| Streaming API | Train Change: nativo, pero solo disponible para un número limitado de objetos en Salesforce Ventana: nativo Volumetría: sin restricciones (el suscriptor debe tener capacidad de ingesta adecuada) Eventos: nativo y capacidad de recuperar histórico Implementación: Bajo en Salesforce, requiere cliente basado en estándares para suscribirse CometD/Bayeaux Implantación: Medio Mantenimiento: Medio |
| CDC Nativo | Train Change: nativo, aún en fase beta, para todos los objetos de Salesforce Ventana: nativo y capacidad de recuperar histórico Volumetría: sin restricciones (el suscriptor debe tener capacidad de ingesta adecuada) Eventos: narivo Implementación: Bajo en Salesforce, requiere cliente basado en estándares para suscribirse CometD/Bayeaux Implantación: N/D (política comercial del producto pendiente) Mantenimiento: análogo anterior |
Conclusiones
Hay una solución para cada caso de uso, tanto el uso de Data Loader, como una herramienta ETL, tienen sus casos de uso, como veremos en futuras entradas.
Actualmente Salesforce está ultimando la implantación definitiva de la propagación de eventos para cualquier objeto en Salesforce mediante Evento siguiendo estándares, y por tanto Change Data Capture de forma nativa, puede ser una de las mejores opciones en ciertos escenarios en un futuro inmediato.
Salesforce FOR ARTISANS 
Deja una respuesta