Déclencheur Apex
Un déclencheur Apex (trigger) est du code Apex que Salesforce exécute automatiquement avant ou après l’insertion, la mise à jour, la suppression ou la restauration d’enregistrements d’un objet donné. Les déclencheurs before valident ou modifient les enregistrements avant leur sauvegarde ; les déclencheurs after exploitent les valeurs définies par le système et agissent sur d’autres enregistrements.
Syntaxe et événements
Un déclencheur se déclare sous la forme trigger Name on Object (events) { … }. Les événements disponibles sont before insert, before update, before delete, after insert, after update, after delete et after undelete, et un même déclencheur peut en traiter plusieurs.
Les déclencheurs before servent à mettre à jour ou à valider des valeurs avant l’enregistrement. Les déclencheurs after servent à lire des champs définis par le système, comme l’Id de l’enregistrement ou LastModifiedDate, et à modifier d’autres enregistrements ; les enregistrements qui lancent un déclencheur after sont en lecture seule.
Contexte du déclencheur
La classe Trigger donne accès aux enregistrements et à des indicateurs de contexte comme isBefore, isInsert, operationType et size. Leur disponibilité dépend de l’événement : par exemple, Trigger.newMap n’est pas disponible en before insert, alors que les anciennes valeurs concernent la mise à jour et la suppression. Consultez le tableau des variables de contexte avant d’utiliser une collection ; les nouveaux enregistrements ne sont modifiables que dans le contexte before approprié.
Traitement en masse et limites
Un déclencheur ne reçoit pas les enregistrements un par un. Les opérations DML portant sur plus de 200 enregistrements sont traitées par lots de 200, et le déclencheur est appelé une fois par lot. Comme Apex impose des limites du gouverneur par transaction, une requête ou une instruction DML placée dans une boucle sur les enregistrements peut les dépasser ; la bonne pratique de Salesforce consiste à rassembler enregistrements et Id dans des sets et des maps, à interroger une seule fois avec une clause IN, et à exécuter le DML sur des collections.
Les appels externes doivent être faits de façon asynchrone depuis un déclencheur, et lorsque plusieurs déclencheurs existent sur le même objet pour le même événement, Salesforce ne garantit pas leur ordre d’exécution.
Ce qu’apporte aprity
aprity lit chaque déclencheur dans les métadonnées, en lecture seule, et le place dans le graphe d’exécution de l’objet, regroupé par événement d’enregistrement avec les flows et les règles de validation. Le graphe de dépendances calcule de façon déterministe ce qui dépend d’une classe Apex, d’un champ ou d’un objet, et la carte des intégrations est construite à partir des sites d’appel repérés dans le code Apex.
Termes liés
- Ordre d’exécution Salesforce — La séquence fixe dans laquelle Salesforce exécute flows, déclencheurs, règles de validation et autres automatisations lors de la sauvegarde d’un enregistrement.
- Flow déclenché par un enregistrement — Un Flow que Salesforce lance automatiquement lorsqu’un enregistrement d’un objet donné est créé, mis à jour ou supprimé.
- Flow avant ou après enregistrement — Les deux optimisations d’un flow déclenché par un enregistrement : Mises à jour rapides des champs avant, Actions et enregistrements associés après.
- API de dépendance Salesforce (Dependency API) — L’objet MetadataComponentDependency de l’API Tooling, qui indique quels composants de métadonnées d’une org en référencent d’autres.
Sources
La documentation officielle de Salesforce sur laquelle cette définition a été vérifiée (pages en anglais). Le comportement de la plateforme évolue d’une version à l’autre : la page citée fait foi.