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.

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 😉