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.