Salesforce Connect para acceder a datos en Amazon RDS via oData

Supongamos el siguiente caso de uso:

• Queremos acceder a una gran cantidad de datos, que están fuera de nuestra ORG de Salesforce (presumiblemente en una base de datos en nuestro CPD)
• Queremos acceder a estos datos, sin interfaces ni APIs
• Queremos realizar reporting y análisis, cruzando esta base de datos con nuestros objetos declarados en nuestra ORG

Escenarios de arquitectura

Solo voy a analizar 2 escenarios:

1. Replicación de Datos en Salesforce
2. Uso de Salesforce Connect: si no podemos replicar en Salesforce, por temas regulatorios, económicos, etc., pero que debemos usar como si de un objeto Custom se tratara

Por supuesto existen escenarios alternativos, o híbridos de estos 2, pero creo que estos 2, son los más habituales en un entorno empresarial.

Replicación de los datos a Salesforce

Este escenario consiste, en replicar los datos desde la base de datos a nuestra ORG. El siguiente esquema muestra a muy alto nivel los componentes necesarios:

Esquema de herramientas Principales para realización de datos en Salesforce

1. Herramienta de inspección de cambios en los logs (para la detección de cambias en las tablas que se vayan modificando)
2. Herramienta de transformación de los cambios detectados (seguramente no nos interesa subir los datos en crudo a Salesforce sino con cierta transformación o adaptación a objetos de Salesforce)
3. Herramienta de carga de datos en Salesforce manteniendo el flujo y la temporalidad de los cambios

Replicación a Amazon RDS y acceso mediante Salesforce Connect (oData)

Este escenario pivota alrededor del uso de Salesforce Connect.

Salesforce Connect es la implementación de un cliente nativo de oData, que permite acceder a una capa de persistencia remota, de forma transparente  y sin programación. Dado que los datos no se almacenan en Salesforce no se consume almacenamiento en la ORG.

Para ello, Salesforce utiliza 2 objetos de metadata:

• External Data Source: configuración del acceso a la base de datos remota (URL del endpoint, compatibilidad del conector, credenciales, etc.)
• External Objects: se crean objetos que representan las tablas que tenemos en la base de datos remota

El siguiente esquema muestra los componentes de alto nivel utilizados:

Diagrama uso de Salesforce Connect para acceso a una Base de Datos en Amazon RDS vía Adaptador oData

1. Una base de datos de Amazon RDS (de hecho podría ser la mayoría de BD en un Cloud público como Azure o Google Cloud Platform, siempre que permitan acceso externo a la base de datos).
   1. Actualmente Amazon RDS ofrece múltiples motores de BD: Mysql, Postgress, Oracle, etc., e híbridos de alto rendimiento como Aurora, etc.
   2. En mi caso, la experiencia ha sido positiva tanto en Mysql, como Postgres y Aurora en Amazon RDS (puedes probar los 2 primeros sin coste pero con Aurora incurres en ciertos costes, que para una prueba de concepto o testing son muy reducidos)
2. Replicación de datos mediante el uso de Amazon Database Migration Service. En un componente nativo de AWS para la replicación de datos desasitida entre bases de datos.
3. Acceso a la base de datos de RDS mediante un Adaptador:
   1. Como ninguna de las bases de datos en Amazon RDS ofrece interfaz oData nativo, es necesario la utilización de un adaptador externo (traducirá las peticiones de Salesforce Connect al motor).
   2. Empresas como Skyvia (sin licenciamiento asociado) o Progress, ofrecen adaptadores de acceso a oData, mediante una configuración muy simple.
4. Configurar Salesforce Connect:
   1. External Data Source:

      

      Definición External Data Source muy simple e intuitiva. Tuve que ajustar algún parámetro que afectaba a la respuesta del Adaptador, pero una vez conseguida la configuración correcta, el rendimiento es bueno, casi imperceptible.

   2. External Data Objects: son los objetos Salesforce, que se corresponden a las tablas expuestas en el adaptador oData.La definición de los External Objects, se realiza mediante la operación Validate&Sync. En ese momento se ejecuta la petición http://URL_Odata/$metadata y a partir de ahí, es tan sencillo, como escoger que tablas->objetos queremos sincronizar.
5. Ya solo queda utilizar estos objetos, como si de objetos nativos se tratara, con List views, Layouts, Custom buttons e incluso Reporting, Dashboards, ambos con ciertas limitaciones etc., sobre ellos. (ver enlaces a final del artículo para las limitaciones asociadas), SOQL, SOSL etc. (dependiendo de las capacidades que aporte el conector).

   

   Detalle External Data Object en Salesforce – Aparece un objeto con las características de un objeto Custom/Standard.

   1. Es posible establecer relaciones entre External Objects y Standard/Custom (vale más una imagen que mil palabras):

      

      Establecer relaciones con External Objects es una funcionalidad Standard de Salesforce – tanto para que el External Object sea el Parent o sea el Child

Hay que tener en cuenta la compatibilidad con las varias versiones de oData v2 disponibles.Inicialmente te recomiendo el uso de oData v2, y después aventurarte en la escritura con la v4.

Vemos en la siguiente imagen como se realiza esta definición en el Adaptador que ofrece gratuitamente Skyvia:

Definición conexión del adaptador con el protocolo Odata en Skyvia

Principales Ventajas/Inconvenientes de cada escenario

Descripción	Escenario replicación de DATOS en SALESFORCE	escenario USO de SALESFORCE CONNECT + AMAZON RDS + Amazon DMS
Licenciamiento y costes asociados	Requiere licenciar varias herramientas que puede suponer un coste muy elevado. Optar por alternativas Open Source para procesos muy exigentes puede ser un handycap importante. El incremento de almacenamiento en Salesforce es lineal y con un coste muy elevado (de los llamados Hidden Costs de Salesforce)	Requiere de pago por uso de un Cloud cuando deseamos mejores prestaciones que la Free Tier. En el caso de AWS los costes están determinados por el almacenamiento usado y no tanto por la capacidad de cómputo. Existen planes muy económicos, y actualmente DMS no tiene coste durante 6+3 meses.
Experiencia de usuario	Es la mejor experiencia de usuario, porque el usuario no nota cambio en su operativa. Aparecen más datos en los objetos ya existentes, u otros objetos nuevos, y la solidez y estabilidad de Salesforce aporta una experiencia excelente. Su satisfacción estará condicionada a las exigencias de Real Time de replicación.	Debido a que los datos residen fuera de la ORG, en cada petición los datos deben solicitarse al External Data Source. La experiencia en peticiones asociadas a unos mil de registros, es excelente, con lo que los casos habituales de navegación quedan cubiertos perfectamente. Las dificultades pueden aparecen en Reporting masivo. Su satisfacción estará condicionada al rendimiento del componente DMS.
Robustez de la replicación	El eslabón débil de esta solución radica en el encadenamiento de herramientas para la extracción y realización de los datos. Aparecen varios puntos de fallo, varios proveedores a coordinar en incidencias graves, etc.	La utilización de DMS siendo una herramienta nativa de Amazon, comporta un SOF(Single Point of Failure).
Capacidad para responder a demandas empresariales a largo plazo	La réplica de datos en Salesforce responde perfectamente al caso de uso original, pero si aparece un nuevo caso de uso, en que otro sistema debe acceder a estos datos, nos vemos obligados a crear otra réplica o a permeabilizar los datos de Salesforce, mediante API, servicios, etc.	Con la réplica de la Base de Datos en el Cloud, aparecen otras posibilidades para explotar esta información. Ofrecer una API de servicios de negocio, para crear escenarios Data Warehouse de gran volumen que proporcionen a los usuarios de analítica, Machine Learning, etc., son senzillos y la escalabilidad elástica garantizada.

Existe un caso de uso que algunas empresas están abordando:

• Existen normativas en algunos ámbitos empresariales, en que no se permite la réplica de datos sensibles. Es por eso, que, accediendo a una base de datos en Cloud Híbrido o Privado mediante oData, nos permite permeabilizar esos datos sensibles, sin necesidad de replicarlos.

Guión para replicar el escenario con Amazon RDS, Salesforce Connect y un adaptador intermedio (Skyvia)

Para replicar este esquema para testing personal:

1. Crear una cuenta gratuita en Amazon AWS Free Tier
2. Acceder a Amazon RDS (Relational Database Service) y crear cualquier base de datos.
   1. Recomiendo para no incurrir en costes  marcar la opción Only enable options eligible for RDS Free usage Teer (Aurora dejará de estar disponible)
   2. La opción importante es marcar la opción para que la base de datos sea Publicly accessible.
3. Crear una cuenta gratuita en Skyvia:
   1. Con el endpoint de la Base de datos en RDS, creamos una Connection
   2. Con la Connection creada, publicamos un acceso via oData en el apartado Connect. En este segundo paso es donde seleccionamos las tablas que queremos que sean accesibles a los clientes oData (en nuestro caso será Salesforce Connect en nuestra ORG)
      

      

      Configuración Skyvia para obtener un acceso oData a nuestra base de datos Amazon RDS

4. Ya en Salesforce, procedemos a crear el External Data Source
   1. Sincronizamos para ver las tablas accesibles, que se convertiran en objetos
   2. Se crearan los External Objects y mágicamente ya podemos empezar a utilizar estos objetos como si objetos de Salesforce habituales

Y si no existe conector oData para mi fuente de datos

Afortunadamente, no hay nada perdido, al contrario, Salesforce proporciona proporciona un Framework, denominado Apex Connector Framework, que permite implementar las clases necesarias, para definir las características de la fuente de datos y acceder a ella de forma remota, en código APEX.

Para ahondar en esta posibilidad recomiendo 2 videos al respecto:

• De Agustina García es muy recomendable (https://www.youtube.com/watch?v=W7Tfru19nS0&t=1614s).
• De Salesforce directamente: Access Any Data Anywhere with the Apex Connector Framework
• Artículos muy interesantes de Alba Rivas:
  • Salesforce Connect Custom Adapters y Callouts con API REST de Alba Rivas

Último apunte: …y con Big Objects?

Casi con total seguridad, que estarás pensando que existe otro mecanismo nativo en Salesforce para solventar esta problemática, mediante el uso de Big Objects, analizo esta opción en esta entrada.

Enlaces interesantes

• Considerations for Salesforce Connect—All Adapters
• High Data Volume Considerations for Salesforce Connect—OData 2.0 and 4.0 Adapters
• Módulo Trailhead, donde existe además una tabla comparativa entre External Objects y Custom Objects
• Reporting con Salesforce Connect y Webinar en oData. 
• Otro artículo de Alba Rivas sobre fuentes de datos  High Data Volume

 

Anuncio publicitario