Replicar cambios en Salesforce hacia sistemas externos – Opciones y alternativas

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.

Representación de un golden record donde su origen se produce en varios sistemas distintos

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.

Concepto de Salesforce Message Bus, orientado a eventos

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:

  1. Acceso a Servicios Externos mediante API expuesta por el sistema destino
    1. Lógica de detección de cambios + Callouts a API de sistema externo
  2. Replicación mediante Queries ad-hoc:
    1. SOQL con comunicación ad-hoc al sistema destino
  3. Replicación nativa por detección de cambios
    1. Uso de Replication API
  4. Mediante herramientas intermediarias
    1. Data Loader en CLI en cadena automatizada
    2. Mediante Herramienta ETL (Informatica Cloud, Jitterbit, etc.)
    3. Salesforce Connect mediante adaptador con oData 4.0
    4. Escritura en BD destino mediante bridge REST
    5. Heroku Connect
  5. Arquitectura Basada en Eventos (modelo Pub/Sub)
    1. Uso de Streaming API
    2. 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
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: Bajo

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
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 (solo podemos interrogar un objeto en cada consulta)
Implantación: Bajo
Mantenimiento: Bajo

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.

Enlaces Interesantes

4 respuestas a “Replicar cambios en Salesforce hacia sistemas externos – Opciones y alternativas

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.