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.

Desde hace ya mucho, para los lenguajes de programación más comunes, disponemos de analizadores de código estático.

Existen varias herramientas en el mercado, para el análisis de código Apex (Checkmarx utilizada por Salesforce, Sonarqube, Cosechan, Codacy, etc.) pero desde abril de 2016, Robert Sösemann portó Apex a PMD, una de las herramientas más conocidas de análisis de código y con licencia Open Source (Hiper-Kudos para Robert), con años de experiencia como una de las soluciones líderes en Java.

PMD para Apex y Visualforce (aún incipiente) no requiere de ninguna infraestructura adicional, solo descargar los binarios y ejecutarlos, en nuestro ordenador, en el servidor, con la 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 los nuevos recursos del lenguaje Apex más novedosas, y amplía las ideas de los 2 frameworks anteriores para la implementación de buenas prácticas.

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 .