Salesforce Connect en dreamOlé 18 –

Durante el pasado Abril, tuve el inmenso placer de introducir el protocolo oData mediante el uso Salesforce Connect en dreamOlé.

Este evento, el mayor realizado en España, está liderado por un equipo de personas absolutamente increíble, que dedican su tiempo libre, sus energías y buen humor para crear un evento de ámbito internacional.

Continue reading “Salesforce Connect en dreamOlé 18 –”

Apex Connector Framework – Usar un servicio externo como un Objeto Nativo

Vimos en las entradas anteriores sobre el uso de oData en Salesforce con Connect, pero dejé para más adelante el Apex Connector Framework (ACF), y ha llegado la hora.

Con un caso de uso que espero entretenido e interesante, muestro como el ACF nos abre un fácil integración con sistemas externos que sin él tendría un coste muy elevado, abriendo las capacidades internas de Salesforce Connect.

Si no conoces el ACF, no te preocupes, realizaré una pequeña introducción, y si lo conoces, quizás te intereses saber algo más de criptomonedas 😉

Continue reading “Apex Connector Framework – Usar un servicio externo como un Objeto Nativo”

Introducción a la Arquitectura de Eventos en Salesforce

“Four years from now, ‘mere mortals’ Will begin to adopt an event-driven architecture (EDA) for the sort of complex event processing that has been attempted only by software gurus [until now]’
—Roy Schulte (Gartner), 2003

En esta primera entrada de una serie, intento situar, cuales son los mecanismos existentes en Salesforce, cuyo core es el uso de Eventos, e intento compararlos y ubicarlos en sus casos de uso.

Podría decirse que esta es una entrada 101 en Eventos de Salesforce.

En mi experiencia, no es trivial entender los “productos/mecanismos” que ofrece y ofrecerá Salesforce sobre eventos (Streaming API, Platform Events, etc.), y las tecnologías (Kafka, Bayeaux, Long Polling, etc.)  asociadas y los casos de uso a que dan respuesta.

Por ejemplo, el título de esta entrada es incorrecto, ya que debería ser algo así como: Introducción a los mecanismos de la Salesforce Enterprise Messaging Platform (pero con ese nombre …), espero pues, que el resto del artículo no sea como el título ;-).

Continue reading “Introducción a la Arquitectura de Eventos en Salesforce”

BULK API v2: 2 veces más rápida con la mitad de código

Una de las novedades que quizás pasaron inadvertidas en la última release de Winter ’18, fue la nueva versión de la BULK API, denominada BULK API v2, disponible en v41.0.

Esta nueva versión, sigue siendo una API REST, que utiliza los verbos HTTP para crear Jobs, cerrar/abortar, eliminar y obtener información al respecto, aportando novedades para el programador y una mejora del rendimiento para el usuario final.

En esta entrada, se muestran las diferencias entre ambas versiones y se compara el rendimiento.

Continue reading “BULK API v2: 2 veces más rápida con la mitad de código”

Las Named Credentials simplifican el código Apex de Callouts mediante configuración estándar

La mayoría de los proyectos de Salesforce requieren Callouts para integrarse e invocar servicios en sistemas externos. Habitualmente estos Callouts, requieren de código Apex, el cual, puede volverse costoso, voluminoso y engorroso de mantener si desconocemos las Named Credentials.

Continue reading “Las Named Credentials simplifican el código Apex de Callouts mediante configuración estándar”

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.

Continue reading “Replicar cambios en Salesforce hacia sistemas externos – Opciones y alternativas”

Reporting sobre una Arquitectura Híbrida: Amazon-Salesforce usando Salesforce Connect

Una de las limitaciones que existian en referencia al uso de External Objects, era su limitada capacidad de Reporting.

En un artículo de Mark Kovacevich, Salesforce Connect Reporting, explicaba un workaround mediante programación en APEX:

  • Mostrando una List View con un Controller básico
  • VisualForce que con un Custom Controller muestra los registros y pinta un par de diagramas.

Continue reading “Reporting sobre una Arquitectura Híbrida: Amazon-Salesforce usando Salesforce Connect”

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

Continue reading “Salesforce Connect para acceder a datos en Amazon RDS via oData”

Mi lista de Limitaciones en Integraciones de Salesforce

Creo que todos lo hemos sufrido -> “Salesforce no soporta FTP nativo” -> Mala cara.

Integración de Salesforce

De mi background como arquitecto de Integración esa afirmación sorprende, pero cuando conoces las capacidades de Integración de Salesforce y otros aspectos como su Seguridad, Fiabilidad, Documentación, Comunidad, etc., se te pasa el susto.

Mantengo una lista de las limitaciones (no en el aspecto negativo) que comparto por si pueden ser de ayuda a alguien y ahorrar algo de tiempo. Por favor, si hay alguna incorrecta (lo siento de antemano) o me faltara alguna, pido por favor mencionarlo, para tener una lista mejor.

  1. Salesforce no tiene un BUS de Integración propio (aunque con Platform Events, Lightning Connect, Streaming API, etc., se da respuesta a muchos casos de uso)
  2. Salesforce no soporta transacciones ACID
  3. Salesforce no soporta WS-Security (https://en.wikipe
  4. dia.org/wiki/WS-Security)
  5. Salesforce no implementa WS-ReliableMessaging (https://en.wikipedia.org/wiki/WS-ReliableMessaging) – que utilizando Outboung Messaging queda mitigado por la lógica de los reintentos cada 10” durante 24h
  6. Salesforce no soporta WS-Addressing, lo que complica el enrutamiento dinámico, en un escenario de Orquestacion empresarial con BUS de Integración disponible
  7. Con Outbound Messaging, no podemos invocar servicios REST (pero hy abierta Idea 08730000000DhyEAAS)
  8. Con Outbound Messaging si al cabo de 10” no hay respuesta se reenvia la petición (hay que certificar Idempotencia en el diálogo)
  9. Con Outbound Messaging solo es posible enviar datos de un objeto, aunque puede recibirse del objeto y de sus objetos relacionados
  10. Las Workflow Rules no son aplicables el borrado de un registro, por lo tanto, no podemos invocar a un servicio externo directamente (existe Workaround mediante trigger)
  11.  Entornos con grandes volúmenes de datos, típicos de un Patrón de Batch, que requieran el uso de BULK API tanto en modo Serial como Parallel, con o sin Chunking, son difíciles de abordar sin herramientas ETL de terceros (que habitualmente tienen un CTO elevado). Nosotros utilizamos Informatica Cloud, aunque ODI y estoy seguro que otras facilitan el uso de BULK API.
  12. Los certificados para comunicación segura con Salesforce deben renovarse anualmente (un poco tedioso para los compañeros de sistemas)
  13. No hay una versión oficial de Data Loader para Linux (es una herramienta de escritorio para Windows y Mac, pero la posibilidad de usarlo como carga masiva usando la BULK API en servidores empresariales Linux es siempre muy tentador y podría…)
  14. Salesforce no proporciona una herramienta de escritorio de ETL simple para que el equipo de negocio pueda cargar datos transformándolos mínimamente (Mass Loader/Update y herramientas como Jitterbit y Dataloader.io, pueden suplir en parte esta carencia)
  15. El Force.com Excel Connector dejó de soportarse hace mucho tiempo, y muchos usuarios preguntan por funcionalidad similar

No menciono los Governor Limits, pq creo que son protecciones necesarias en un entorno Multi-tenant, y en muchos casos, romperlos implica que la solución adoptada no es la adecuada.

Seguramente tenemos otras de muy bajo nivel técnico, pero mi intención es solo compartir mi lista y si es posible mejorarla.

*Si perteneces a Salesforce y lees este artículo, no fruncir el ceño por favor, no hay mejor elogio para un fabricante, que sus clientes utilicen sus herramietnas y la conozcan bien.

Crédito de la imagen para: elearningindustry.com

Data Loader en CLI en Linux/Unix/Mac OS

Data Loader es una herramienta creada en Java, con su código disponible en gitHub, lo que nos permite descargar su código, y montar sus artefactos mediante maven.

 

Todos conocemos la interfaz gráfica, pero como se explica en la documentación del mismo Repositorio de gitHub, también ofrece una clase (com.salesforce.dataloader.process.ProcessRunner) para la invocación por línea de comandos  (CLI – Command Line Interface) en cualquier sistema operativo que disponga de una máquina virtual Java instalada.

Esto permite, por ejemplo, planificar (mediante CRON) cargas/descargas desde servidores empresariales Linux/Unix, y haciendo uso de Bulk API (hay otros muchos casos de uso ).

Utilizar Data Loader via CLI es muy senzillo y se describe en la documentación de Salesforce. Resumiendo son 3 pasos:

  1. Generar nuestro password encritpado en 2 pasos
  2. Crear el mapeo de los campos entre el fichero que cargaremos y el objeto destino
  3. Crear el fichero process-conf.xml q contiene el detalle del proceso a ejecutar (Operación, uso de BULK API, etc.)

Pero si además, estos 3 pasos nos parecen complejos/tediosos existe una herramienta llamada CLIq, que nos automatiza esta generació. Esta herramienta también está disponible en gitHub.

En la imagen adjunto, se observa la ejecución que realizo en el Linux más raro que he tenido nunca, Bash de Ubuntu en Windows, gracias al Windows Linux Subsystem, lo que demuestra que mientras haya disponible una máquina virtual de Java instalada, podemos ejecutar Data Loader y conseguir una nueva herramienta en nuestro arsenal de Integración.

Ejecución de Data Loader en Bash Ubuntu Windows Linux Subsystem
Ejecución de Data Loader en Bash Ubuntu Windows Linux Subsystem

Documentación para profundizar:

Replication API para identificar cambios

La Replication API de Salesforce tiene como objetivo, identificar todos los objetos modificados duante un intervalo de tiempo.

Esta API SOAP, permite obtener en un interval de tiempo, aquellos objetos nuevos, modificados o eliminados en nuestra ORG.

Aunque también esto es posible accediendo a los campos Audit de los registros de los objetos, esta API tiene una característica muy importante: es accesible via 2 métodos de la clase Database: getUpdated(), getDeleted() y es transversal a todos ellos.

En concreto se obtiene, un array de IDs de los registros  nuevos/modificados o eliminados, y la hora en la que se ha realizado la consulta (para poder encadenar posteriormente otra).

Esta API, y supongo de ahí el nombre que le puso Salesforce (y que en mi opinión no es del identificador de su funcionalidad), está dirigida a la Integración de sistemas (obtener los cambios realizados para sincronizar con otro sistemas). Pero existen otros escenarios donde puede ser útil: la  auditoría de cambios durante un evento especial, reconciliación datos etc.

Ejemplo básico de utilización:

Captura de pantalla de uso de la Replication API de Salesforce
Captura de pantalla de uso de la Replication API de Salesforce

Enlaces para saber más: