Existen muchos artículos sobre los comandos que podemos lanzar con la linea de comandos de Salesforce, la llamada Salesforce CLI.

Pero en muchas ocasiones, me pregunto si al mostrar todos esos comandos, conseguimos realmente transmitir las capacidades y los beneficios que la CLI puede aportar a todos, sin excepción.

Por este motivo, este artículo tiene un enfoque completamente distinto.

Change Data Capture es un mecanismo ya disponible en Winter ’19 que facilita la integración entre sistemas y permite crear nuevos procesos de negocio, generando eventos (Change Data Events) cuando creamos, actualizamos, eliminamos o recuperamos un registro de un objeto.

En esta entrada veremos que con tan solo pocos clics podremos activar la generación de eventos, y suscribirnos para tratarlos con 3 mecanismos distintos.

Vimos en la entrada anterior las alternativas para almacenar información confidencial en Salesforce y vimos que el mecanismo preferido inicialmente, era la creación y despliegue de un Protected Custom Metadata Type.

En este artículo veremos paso a paso y en detalle:

  • La arquitectura recomendada por Salesforce para el Managed Package y asegurar la confidencialidad de la información (y alguna variante que propongo).
  • Cómo construir y configurar el Custom Metadata Type que albergue esa información.
  • Cómo desplegar el paquete en la ORG destino.

Durante estas fechas (Navidades),  es fundamental saber guardar ciertos secretos 😉 .

Saber qué secretos ocultar, a quién y a quién no ocultarlos, y cuanto esfuerzo nos a va suponer ocultarlo. Aparecen varias opciones y así no romper la magia de los más pequeños demasiado pronto.

Sucede de igual manera en Salesforce cuando deseamos almacenar secretos o información confidencial.

(This article is also available in English as appeared translated in Salesfoceben on July 2019).

En la última entrada sobre Optimización de Queries en Salesforce, destapaba unos de los problemas más evidentes de cualquier proyecto: la degradación de rendimiento de los elementos que consultan datos en Salesforce.

Es decir, a medida que nuestra ORG crece, las consultas que inicialmente diseñamos (que quizás optimizamos o quizás no) pueden sufrir degradación. Pero no estoy hablando sólo de las Queries de los Developers con SOQL, estoy hablando de List Views, Reports y Dashboards que crean los usuarios.

Ayer, 06/11 tuvimos el evento de Dreamforce Gathering 2018 en Barcelona, conjuntamente el grupo de Developers y Administradores de Salesforce.

Primero de todo agradecer a Cognizant, por ceder sus oficinas, y a los organizadores Pablo García, David Sánchez y Roger Borges, por la magnífica organización (dedicando su tiempo), lo interesante del evento y el buen rollo que uno siente en estos eventos.

Vimos en la entrada anterior que el objetivo de la optimización de consultas es conseguir:

  • Obtener el menor coste posible, es decir el mejor plan de ejecución
  • Que este coste sea inferior a 1, significando que la consulta es selectiva utilizando los índices creados

Como desarrolladores o administradores necesitamos validar si una consulta será selectiva antes de llegar a Producción, y mejorar su rendimiento.

Ayer 04/10 tuvimos el Meetup en Barcelona, de como crear un framework de triggers Rock-Solid, con las ideas que propusieron Tony Scott, Dan Appleman y Hari Krishnan, en la  Developer Community .

Es un placer, encontrarnos y compartir conocimientos y experiencias de todos, deberíamos vernos más!!

Mil gracias a Pablo García por toda su organización y a el equipo de Minsait en Indra, que cedieron el local y todo funcionó a la perfección.

Tanto el código comentado, como la presentación se pueden encontrar en este Repositorio Público con la presentación y el código comentado.

Un tema fundamental al que nos enfrentamos es conseguir que las Queries, Reports, Dashboards, List Views que construimos tengan el mejor rendimiento posible (muchas veces fueron escritas por otros compañeros hace un tiempo).

Desde hace un tiempo quería dedicar una serie de entradas al diseño y optimización de Queries y habiendo finalizado la certificación de Data Architecture and Designer es el momento ideal.

En esta serie de entradas trataré estos 8 aspectos:

En la entrada anterior describí que era la anomalía en los datos llamada Data Skew en Salesforce. Y aunque ese es el primer paso, lo realmente útil, en nuestro día a día, es poderlo detectar con antelación.

No conozco qué Salesforce ofrezca, ninguna utilidad para la localización de Data Skew, aunque anticiparnos a qué suceda en nuestra ORG, puede suponer ahorrarnos muchos dolores de cabeza.

Por ello, he desarrollado una utilidad en APEX que permite analizar tu ORG, y encontrar todos los campos con Data Skew. Disponer de esta información puede ahorrar problemas a los usuarios de tu ORG, espero que te sea de ayuda .

(Actualización 11/12/2018:  realizé una presentación en el evento, Barcelona Dreamforce Global Gathering 2018, donde expuse la problemática de Data Skew. Para la explicación, utilizé analogías con Gru y los Minions, y dado su buen recibimiento he creído necesario actualizar este artículo y el uso de las analogías que utilicé).

Sucede habitualmente que podemos tomar decisiones para gestionar nuestros datos, que disfrazadas de buenas ideas, pueden perjudicar el rendimiento e incorporan incidencias importantes. Estas han sido detectadas en muchas ORGs y reciben el nombre de Data Skew.

(Actualizado Mayo 2020)
Desde hace ya mucho, para los lenguajes de programación más comunes, disponemos de analizadores de código estático. Son herramientas, que aplican reglas de validación al código que escribimos.

Salesforce no proporciona una herramienta nativa dedicada al análisis de código estático APEX. Afortunadamente existen diferentes opciones en el mercado: CodeScan, Checkmarx, PMD, etc. Salesforce ofrece scans ad-hoc mediante Force.com Code Scanner Portal en asociación con Checkmarx, que es la herramienta utilizada internamente en Salesforce.

Una de estas herramientas muy empleada en otro lenguajes de programación es PMD. PMD es una librería Open Source para la ejecución de reglas de validación sobre un lenguaje de programación.

En Abril de 2016, Robert Sösemann anunció que había portado muchas reglas de validadción sobre el lenguaje Apex a PMD. Desde entonces PMD se ha convertido en una herramienta crucial en muchos proyectos de Salesforce, dada su facilidad de uso y la calidad de las reglas utilizadas.

PMD no requiere de ninguna infraestructura adicional, solo descargar los binarios y ejecutarlos, en nuestro ordenador, o en un servidor, con unda JDK instalada etc.

Las capacidades de PMD, su licenciamiento, versatilidad, extensibilidad, integración con los IDEs y con  herramientas de CI habituales (Maven, Ant, Gradle, etc.), y comunidad facilita enormemente su adopción.

Por ello, si no lo conoces, creo que puede ser muy útil, y es una herramienta muy a tener en cuenta para utilizar en nuestros proyectos. Te animo a leer el artículo por si te puede ayudar.

Estás creando un nuevo trigger con la funcionalidad deseada. Lo has probado en tus scratch orgs, funciona correctamente, tus tests devuelven los resultados esperados.

Realizas el pase a la Sandbox de Integración, y PUF!! tu trigger finaliza con una Excepción de Límites superados. ¿Cómo puede ser?

Uno de tus compañeros, te pregunta: ¿Qué se está ejecutando dentro del Contexto de Ejecución al invocar el Trigger?

Si esta pregunta te suena a chino o no estás seguro de los que es el Contexto de Ejecución, quizás este artículo pueda ayudarte… y que sepas que no es culpa de nadie 😉

Como tercera entrada de la serie de Frameworks para la gestión de Triggers, no podía faltar la propuesta de Hari Krishnan. Este framework no es revolucionario, sinó que cómo explica el mismo autor, fue la culminación de evolucionar las ideas de Tony Scott, Dan Appleman, siendo mejoradas.

De los 3 frameworks analizados en esta serie, este es el que ofrece una orientación a objetos y uso de Apex más potente, ampliando las ideas de los 2 frameworks anteriores.

Si participas o prevés estar en proyectos de cierto tamaño, conocer este framework es vital, y sobretodo entender su implementación (si tienes poca experiencia como programador, no desistas, dedicando algo de tiempo, no tendrás problema).

Las ideas propuestas por Dan Appleman en su libro Advanced Apex para la gestión eficiente de triggers, han sido la base para varios frameworks aparecidos posteriormente.

De hecho, el título que el autor dio al capítulo de su libro, “One trigger to rule them all” es ampliamente mencionado en muchos artículos y sitios web.

Mi objetivo en esta entrada, es explicar llanamente, los conceptos e ideas de este framework, que son principios que casi todos los frameworks implementan.

Uno de los primeros patrones/frameworks que aparecieron fue en un Force.com Cookbook, y después mejorado en su propio blog, por su propio autor, Tony Scott.

Utilizaré la nomenclatura de Patrón en lugar de Framework, porque realmente el autor no propuso, ni era su propósito, facilitar un framework, sino unas buenas prácticas que dieran respuesta a las problemáticas de su propia experiencia.

Los principios de este patrón de gestión de triggers son:

  1. El trigger no contine código, solo invoca a una clase Factory que implementa la lógica en su evento respectivo
  2. El Handler contiene la lógica de negocio de todos los eventos. Sus métodos son la implementación de una Interface.
  3. Una clase Factory, instancia el Handler y enruta las acciones en función del evento del trigger (before, insert…)
  4. Se incorporan funciones de BULK para eficientar el código

Estos principios, son pilares que los frameworks que vinieron a continuación tomaron como pilares,  y por lo tanto, vale la pena entender detenidamente lo que propuso Tony Scott .

Los triggers, son una funcionalidad ampliamente utilizada, pero que a medida que avanza el proyecto y se afianza, su uso desordenado provoca situaciones inadvertidas o efectos laterales indeseados, con frustración por parte del desarrollador y del usuario.

En este artículo quiero explicar, cuales son las problemáticas habituales, cuando aparecen, y las best practices y frameworks que se han desarrollado para mitigarlas.

Veamos pues, como crear Triggers vitaminados y super-mineralizados.

As explained in the last 2 entries, asynchronous processing and execution planning capabilities on Salesforce are very useful and powerful.

But nonetheless, in some complex scenarios, you will find some limitations that can be overcome easily.

Let me explain how, with some Apex Developing and using standard capabilities, you can get a quite powerful Dynamic Planner to sort out those limitations.

My goal on this entry is to describe the current limitations on the platform, explain how they can be solved, and hope they are useful and make some contribution to improve your knowledge in this key area.

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 😉

Como hemos visto en las 2 entradas anteriores, las capacidades asíncronas de Salesforce y su planificación son de gran utilidad.

Aún así, vimos que podemos encontrar una carencia: si nuestros procesos asíncronos tiene condiciones funcionales o técnicas de las que depende lanzar su ejecución, no existe la posibilidad de configurar estas dependencias.

Mi objetivo es explicar la idea, ofreciendo una prueba de concepto funcional, para que puedas darle la vuelta, mejorarlo y ampliarlo para tus necesidades.

En esta entrada me centraré, en cómo diseñar la ejecución de Procesos Asíncronos Apex (en adelante Apex Async), aprovechando las capacidades de la plataforma.

Pero lo haré de manera invertida a como se hace habitualmente, donde se explica como programar los mecanismos de programación. Pero en IMMO, si los desarrolladores, arquitectos y administradores, entendemos bien como gestiona Salesforce los procesos asíncronos, sus colas de Espera y Ejecución, sus límites asociados, etc., la elección del mecanismo de programación, es muy sencilla u obvia.

“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

(Entrada actualizada en Enero 2019, al liberarse como GA el mecanismo de Change Data Capture en Winter 19).

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 ;-).

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.

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.

En la entrada anterior, describía el caso de uso de cómo acceder a una gran volumen de datos desde nuestra ORG via External Objects, y dejaba la puerta abierta a la alternativa a la funcionalidad nativa de Big Objects en Salesforce.

Esta entrada describe qué son, en qué casos de uso pueden aplicarse, cómo crearlos, insertar datos (con Data Loader que parece ser un caso poco documentado) y describir sus características y restricciones, que no son pocas.

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.

Esta entrada pertenece a una serie:

  1. Introducción
  2. Descripción de la metadata
  3. Proceso y uso de la herramienta de despliegue
  4. Orquestación y visión completa
  5. Conclusiones Finales y recomendaciones (esta entrada)

Partimos inicialmente con el deseo y con la convicción de que la Integración Contínua en Salesforce es completamente necesaria, y esa convicción, a pesar de los retos y condicionantes observados,  sigue intacta.

Lo que ha cambiado completamente, es la simplificación con la que se habla y se predica la adopción de este proceso en modo DIY (Do it Yourself).

Esta entrada inicia una serie en la que muestro el proceso de mi adopción de Integración continua en Salesforce. Para la mayoría, no aporta ningún conocimiento nuevo, pero sirve para sentar las bases comunes.

Las entradas de la serie son:

  1. Introducción (esta entrada)
  2. Descripción de la metadata
  3. Proceso y uso de la herramienta de despliegue
  4. Orquestación y visión completa
  5. Conclusiones Finales y recomendaciones

Vincent Driessen en su blog GitFlow- A successfull Branching Model, describe el casi proceso de facto que aplican muchos equipos de desarrollo para la gestión de ramas (aunque prefiero la explicación y gráficos de AtlassiangitFlow Workflow.)-.

En esta entrada, intento explicar por qué, al menos en mi caso, no es directa su aplicación en un proyecto de Salesforce y las consideraciones adicionales y conclusiones a las que he llegado.