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

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

  • El trigger no contine código, solo invoca a una clase Handler que implementa la lógica en cada evento
  • Una clase Factory, construye los Handlers de forma dinámica y enruta las acciones en función del evento del trigger (before, insert…)
  • Este funcionamiento requiere de la creación de una Interface que todos los triggers deberán implementar
  • Se incorporan funciones de BULK para eficientar el código

Algunas de las decisiones de este esquema planteado, se repite en varios de los frameworks que iremos viendo, por lo que es muy útil entenderlas.

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 ayuda.

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.

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