Le traitement asynchrone augmente l'évolutivité en autorisant des limites plus élevées par contexte. Les requêtes asynchrones sont exécutées dans leurs propres threads en arrière-plan. Les utilisateurs peuvent ainsi continuer à travailler côté client pendant que les tâches asynchrones sont exécutées en arrière-plan.

Salesforce Lightning Platform offre une variété de technologies asynchrones qui peuvent être utilisées pour résoudre un cas d'utilisation donné. Chaque technologie présente des avantages et des limites que vous devrez prendre en compte lors de la sélection d'une approche pour chaque cas d'utilisation.

Lors du choix d'une technologie pour l'implémentation, trois considérations importantes à prendre en compte sont les suivantes :

1. Le traitement asynchrone n'est pas la meilleure approche pour chaque problème. Il peut être tentant de considérer tout processus qui ne nécessite pas directement l'interaction de l'utilisateur comme un bon candidat pour le traitement asynchrone, mais il y a quelques inconvénients. Tout d'abord, les processus asynchrones n'ont pas de contrat de niveau de service, ce qui signifie qu'il n'y a aucune garantie qu'un processus asynchrone se termine dans un délai défini. Deuxièmement, rien ne garantit une latence de réponse cohérente. Si un processus asynchrone se termine dans un délai donné, un processus suivant peut prendre un délai différent. Par conséquent, même si un utilisateur n'attend pas directement une réponse, le traitement asynchrone peut ne pas être adapté à votre scénario si vous avez des processus ultérieurs qui dépendent d'une réponse ou si vous craignez que des temps de réponse excessifs ne désynchronisent vos données avec celles d'un système externe.
2. Il existe différentes méthodes de traitement des requêtes asynchrones sur Salesforce Platform. Par conséquent, assurez-vous de choisir la meilleure approche. Les technologies qui prennent en charge le traitement asynchrone sur Salesforce Platform fonctionnent différemment « en arrière-plan », et certaines ont été conçues pour des cas d'utilisation très spécifiques.
3. Si une technologie est asynchrone côté client, cela ne signifie pas nécessairement que tous les traitements de bout en bout sont effectués en parallèle. Selon vos choix, les messages du client peuvent parfois être numérotés côté serveur.

Si vous utilisez les mauvaises technologies ou les mauvaises combinaisons de technologies pour une tâche, des conséquences inattendues qui annulent les avantages du traitement asynchrone peuvent se produire. Ce guide fournit des explications et des recommandations, ainsi que les inconvénients potentiels et les anti-modèles pour divers cas d'utilisation asynchrone, avec la justification de ces recommandations. Il fournit également des connaissances sur le fonctionnement et la réglementation des diverses techniques d'implémentation asynchrone sur Salesforce Platform.

Si vous décidez de la technologie à utiliser, un guide de décision sur le traitement asynchrone ciblé permet de mapper rapidement les cas d'utilisation typiques avec la technologie la plus adaptée.

Salesforce Lightning Platform est une plate-forme complète pilotée par l'IA qui unifie les employés, les agents IA autonomes, les données de l'entreprise et les applications dans un système unique et de confiance afin d'améliorer la productivité et l'expérience client. Il permet la création d'une "entreprise agentique" en connectant les applications Customer 360, Data Cloud, et Slack pour une automatisation de bout en bout.

Ce document ne couvre pas les technologies d'autres écosystèmes tels que MuleSoft, Informatica, Commerce Cloud, Tableau et Marketing Cloud.

Notez que ce guide se concentre exclusivement sur le traitement asynchrone au sein de Salesforce Lightning Platform. Si vous recherchez des informations sur les modèles d'intégration asynchrone, consultez Architecture pilotée par les événements.

• Avant d'utiliser le traitement asynchrone, assurez-vous que vos cas d'utilisation correspondent au modèle. Les modèles asynchrones n'ont pas de contrat de niveau de service, sont soumis à plusieurs mécanismes de gouverneur, peuvent avoir des limites de capacité définies en fonction de la licence et peuvent entraîner des retards de traitement en raison de la nature limitée des ressources allouées à l'infrastructure asynchrone dans Salesforce Platform. Tenez sérieusement compte de ces limitations lors de l'utilisation d'un traitement asynchrone dans les scénarios où un utilisateur demande une réponse du système avant de pouvoir poursuivre son travail.
• Le traitement asynchrone avec Salesforce n'est pas une solution pour des besoins d'évolutivité illimités. Salesforce Platform n'évolue pas à l'infini, et les modèles asynchrones restent soumis à des limitations. Le traitement asynchrone utilise des threads, qui contiennent les informations contextuelles dont un processeur a besoin pour exécuter un flux d'instructions. Les threads peuvent être exécutés en parallèle. Le nombre de threads disponibles dans n'importe quel processeur est limité. Par conséquent, la plate-forme a mis en place des mécanismes pour s'assurer que ses threads disponibles sont utilisés aussi efficacement que possible. Le mécanisme de contrôle de flux de la plate-forme empêche les organisations de consommer trop de threads et d'affecter négativement les autres organisations. L'algorithme d'utilisation équitable de la plate-forme contrôle le nombre de threads disponibles pour une organisation pour chaque type de message particulier.
• Déterminez quand les transactions sont réellement asynchrones. Certains modèles d'architecture ont un comportement asynchrone de bout en bout. Cependant, d'autres processus se comportent de façon asynchrone côté client ou côté navigateur, mais sérialisent les requêtes côté serveur, qui sont ensuite soumises à des limitations du gouverneur synchrone.
• Pour élaborer des intégrations sortantes à grande échelle à partir de Salesforce Platform, utilisez des événements de plate-forme et un middleware robuste au lieu d'appels externes via Apex asynchrone. Comme il existe un nombre fini de threads asynchrones disponibles sur la plate-forme, les intégrations sortantes via Apex asynchrone ont une évolutivité limitée. Si votre organisation a des intégrations sortantes qui impliquent des volumes de messages élevés, dépassent le nombre de threads disponibles et ont des temps de traitement longs, alors l'utilisation Apex asynchrone introduira inévitablement des délais.
• Assurez-vous d'incorporer la surveillance lors de l'utilisation du traitement asynchrone. Avec la surveillance, vous pouvez détecter les problèmes le plus tôt possible et les corriger avant que des incidents de performance majeurs se produisent.
• Compte tenu des événements qui peuvent entraîner des charges extrêmes. Lorsque vous concevez des processus asynchrones, assurez-vous qu'ils peuvent gérer de façon prévisible les pics de charge de travail et les accalmies. Examinez comment votre implémentation gère les événements inattendus, tels que les pannes de courant, et concevez des mesures de protection qui atténuent la perte de données ou la perte de fonctionnalité.

Lorsque vous sélectionnez une approche pour le traitement asynchrone côté serveur, commencez par évaluer les besoins de votre organisation et les ressources disponibles. Votre objectif est de sélectionner une approche qui minimise les coûts d'implémentation et de maintenance tout en garantissant l'évolutivité et en minimisant la probabilité d'infractions aux limites. Cet objectif dépend des considérations techniques exposées dans les sections suivantes, ainsi que de la composition de votre équipe. Déterminez par exemple si votre équipe compte des développeurs Apex capables de gérer votre solution pro-code. Sinon, une approche déclarative peut être plus logique. Notez également que différents ensembles de limites peuvent s'appliquer à différents outils.

Prenons le cas d'un processus de commande asynchrone dans Salesforce. Lorsqu'une commande est enregistrée, elle déclenche un message à un système de gestion d'entrepôt externe avec des instructions spéciales pour emballer et expédier un article. L'utilisateur qui passe la commande n'a pas besoin d'une réponse immédiate du système de gestion de l'entrepôt. Par conséquent, la demande peut être envoyée de façon asynchrone. Le traitement asynchrone permet à l'utilisateur de poursuivre son travail sans délai.

Considérations relatives à votre architecture :

• Combien de processus simultanés sont nécessaires ?
• Comment le processus concurrent interagira-t-il les uns avec les autres ?
• Combien de requêtes SOQL vont être exécutées dans chaque processus ?
• Combien d'opérations DML vont être exécutées dans chaque processus ?
• Quelle est la durée d'exécution de chaque processus ?
• Quelle est la sensibilité des processus à un calendrier spécifique ?

L'architecture multilocataire de Salesforce Platform isole et prend en charge simultanément les exigences variables de nombreux locataires (organisations). Toutes les méthodes Apex asynchrones abordées dans ce guide sont exécutées dans la même infrastructure asynchrone de Salesforce Platform. Ils utilisent un cadre de mise en file d'attente des messages régi par deux mécanismes d'application principaux : le contrôle des flux et l'utilisation équitable.

Le contrôle du flux et les mécanismes d'utilisation équitable empêchent un locataire unique d'utiliser trop de ressources serveur et de ne pas laisser suffisamment de ressources pour les locataires restants. Bien qu'il soit utile de comprendre le fonctionnement de ces mécanismes, vous devez retenir que le respect des meilleures pratiques de traitement asynchrone, telles que celles décrites dans les sections suivantes, réduit considérablement la probabilité de rencontrer des problèmes avec ces mécanismes.

Le mécanisme de contrôle de flux de la plate-forme empêche une organisation d'inonder un type de message donné, qui consomme trop de threads et affecte négativement les autres organisations. Avant d'ajouter de nouvelles entrées à la file d'attente associée à un type de message, l'infrastructure vérifie les premiers milliers d'entrées existantes dans la file d'attente. Si la majorité des entrées existantes sont associées à la même organisation et que cette organisation contient déjà des entrées dans des threads worker, les nouvelles entrées ajoutées sont déplacées en arrière de la file d'attente. Ce processus est appelé mise en file d'attente. La mise en file d'attente arrive généralement aux processus Apex par lot et API de transfert en masse, car ils insèrent souvent un grand nombre d'entrées en même temps dans leurs files d'attente.

Le mécanisme d'utilisation équitable de la plate-forme implémente un système basé sur le niveau. Le système garantit que chaque organisation sur Salesforce Platform reçoit une part équitable du temps de traitement pour un type de message donné, y compris les types de message Future, Queueable et Batch. Si une organisation domine un type de message donné pendant que d'autres organisations attendent pour travailler sur le même type de message, l'algorithme d'utilisation équitable réduit le nombre de threads disponibles pour ce type de message particulier.

Un avantage de l'utilisation de méthodes Apex asynchrones est que certaines limites du gouverneur, telles que les limites en requêtes SOQL et les limites en taille de tas, sont plus élevées. Cependant, ne vous appuyez pas trop sur ces méthodes. En raison des ressources limitées allouées à l'infrastructure asynchrone, une utilisation intensive de Future, Queueable et Batch Apex peut entraîner des retards de traitement qui découlent de limitations basées sur une utilisation équitable et un contrôle de flux.

Les appels externes sortants qui utilisent Apex asynchrone sont pris en compte dans la limite Apex asynchrone. La limite quotidienne est actuellement de 250 000 ou 200 fois le nombre de licences utilisateur applicables, selon la valeur la plus élevée. Cette limite peut être problématique pour les cas d'utilisation à haut volume. Si vous dépassez la limite, vos tâches Apex asynchrones et leurs appels sortants associés échoueront.

De plus, comme la plate-forme a un nombre fini de threads asynchrones disponibles, l'évolutivité des intégrations sortantes via Apex asynchrone est limitée. Toutes les intégrations sortantes à haut volume qui dépassent le nombre de threads disponibles peuvent entraîner des temps de traitement importants et des retards.

Pour des cas d'utilisation à haut volume, tenez compte des approches alternatives ci-dessous. Les appels d'API avec ces approches sont pris en compte dans la limite quotidienne en requêtes d'API, qui est significativement plus élevée que la limite Apex asynchrone quotidienne. Ainsi, ces approches sont plus évolutives. Notez toutefois que le nombre de requêtes simultanées que tout processeur peut traiter reste limité.

• Middleware Scheduled Pull. Évitez les délais associés aux tâches d'intégration sortantes à haut volume en utilisant un middleware pour extraire les données sur une base planifiée au lieu de les envoyer automatiquement via Apex asynchrone. Les middlewares, tels que MuleSoft Anypoint Platform, peuvent utiliser l'API SOAP native ou l'API REST de façon synchrone afin d'introduire peu, voire aucun délai. Middleware peut également utiliser l'API de transfert en masse native pour des volumes de données importants.

• Middleware Pull via Notification d'événement de plate-forme. Au lieu de mettre en file d'attente Apex asynchrone Future, Queueable ou Batch pour effectuer des intégrations sortantes, vous pouvez utiliser des événements de plate-forme. L'événement de plate-forme peut livrer les informations sortantes lui-même ou charger un outil middleware d'extraire les informations requises via une API native et de les livrer à leur destination finale. Aucune de ces approches n'est soumise aux délais auxquels est soumis Apex asynchrone. Cependant, les limites en événements de plate-forme restent applicables.

Avec Apex Queueable, vous pouvez exécuter de façon asynchrone des processus Apex qui impliquent des opérations de base de données étendues ou des appels externes de service Web. Pour utiliser Apex Queueable, implémentez l'interface Queueable, puis ajoutez une tâche à la file d'attente des tâches Apex. Cette approche garantit que la tâche Apex asynchrone est exécutée en arrière-plan dans son propre thread isolé et ne retarde pas l'exécution de votre logique Apex principale. Chaque tâche en file d'attente est exécutée lorsque des ressources système sont disponibles.

Apex Queueable représente l'évolution des Apex asynchrones. Il offre des fonctionnalités qui ne seront plus disponibles pour les futures méthodes Apex, notamment :

• ID de travail : Lorsque vous soumettez une tâche en invoquant la méthode System.enqueueJob, la méthode renvoie l'ID de la nouvelle tâche. Vous pouvez utiliser cet ID pour identifier votre travail. Pour suivre sa progression, consultez la page Tâches Apex dans la Configuration de Salesforce, ou interrogez l'objet AsyncApexJob.
• Prise en charge des types non primitifs : Les classes Queueable peuvent contenir des variables membres de types de données non primitifs, tels que des sObjects ou des types Apex personnalisés.
• Appui à la chaîne de travail : Vous pouvez enchaîner les tâches Queueable en lançant une deuxième tâche à partir d'une tâche en cours. Cette technique peut vous aider à gérer des scénarios impliquant des dépendances de processus.
• Contrôle de profondeur maximal : Vous pouvez configurer des tâches Queueable avec une profondeur de pile maximale afin d'éviter que des chaînes de tâches se terminent par une récursion inattendue.
• Signatures de déduplication : Les tâches en file d'attente fournissent une signature facultative pour détecter et retirer les tâches dupliquées.
• Délai configurable : Vous pouvez définir un délai allant jusqu'à 10 minutes avant l'exécution de la tâche Queueable.
• Filtrisateurs de transaction : Vous pouvez joindre une séquence post-action à une tâche Queueable et prendre des mesures pertinentes en fonction de son résultat. Par exemple, un finaliseur de transaction peut mettre en file d'attente jusqu'à cinq fois une tâche Queueable échouée en raison d'une exception non gérée.

Salesforce utilise une infrastructure basée sur la file d'attente pour gérer les processus asynchrones. Cette file d'attente est utilisée pour équilibrer les charges de travail des requêtes entre les organisations. Pour vous assurer que votre organisation utilise cette file d'attente aussi efficacement que possible :

• Évitez de mettre en file d'attente des méthodes futures ou Queueable directement à partir d'actions générées par des volumes importants d'activités de l'utilisateur final ou d'appels d'API d'intégration. Cette approche peut rapidement épuiser les limites Apex asynchrones quotidiennes, entraînant de graves impacts métiers.
• Évitez de mettre en file d'attente plusieurs actions asynchrones par action synchrone. Lorsque plusieurs méthodes asynchrones sont mises en file d'attente à partir d'une seule action synchrone, les activités asynchrones sont souvent exécutées en même temps et contribuent à des contentions de verrouillage de ligne et/ou à des erreurs d'expiration de verrouillage de ligne.
• Évitez d'ajouter un grand nombre de méthodes futures ou Queueable à la file d'attente asynchrone.
• Assurez-vous que les méthodes futures et Queueable sont exécutées le plus rapidement possible. Plus l'exécution d'une méthode future est longue, plus les requêtes derrière elle dans la file d'attente risquent d'être retardées. Pour garantir une exécution rapide des tâches par lot, réduisez les temps d'appel externe du service Web, ajustez les requêtes utilisées dans vos futures méthodes et optimisez toutes les autres automatisations d'objets, y compris les processus du Générateur de processus, les règles de workflow, les flux et les déclencheurs Apex.
• Testez vos méthodes asynchrones à l'échelle. Utilisez un environnement qui génère le nombre maximal de méthodes que vous souhaitez traiter. Ces tests aident à déterminer si vous rencontrerez des problèmes de performance ou de limites dans votre environnement de production. Tenez également compte de l'impact sur les limites quotidiennes cumulées.
• Utilisez Apex par lot au lieu de méthodes futures ou Queueable pour traiter un grand nombre d'enregistrements. Apex par lot peut gérer des processus complexes et longs qui s'exécutent sur des milliers d'enregistrements et dont l'exécution peut être planifiée pendant les heures creuses lorsque davantage de ressources sont disponibles.

Utilisez Apex planifié pour exécuter à une heure spécifiée et à une fréquence répétée telle que définie par une expression cron. Bien que l'action de planifier Apex via l'expression cron soit un processus asynchrone, le code sous-jacent est exécuté de façon synchrone au démarrage de la tâche. Apex planifié est idéal pour les tâches de maintenance quotidiennes ou hebdomadaires.

• Vous ne pouvez avoir que 100 Tâches Apex planifiées à la fois. Pour éviter cette limitation, pensez à utiliser un flux déclenché par une planification qui invoque un code Apex au lieu d'utiliser Apex planifié.
• Faites preuve de la plus grande prudence si vous envisagez de planifier un cours à partir d'un déclencheur. Vous devez être en mesure de garantir que le déclencheur n'ajoute pas plus de classes planifiées que la limite. En particulier, tenez compte des mises à jour en masse d'API, des assistants d'importation, des modifications en masse d'enregistrements via l'interface utilisateur et de tous les cas où plusieurs enregistrements peuvent être mis à jour à la fois.
• Pour les tâches uniques qui doivent être planifiées jusqu'à 10 minutes plus tard, utilisez une tâche Queueable retardée. Cette approche n'est pas prise en compte dans la limite de 100 tâches planifiées.
• Apex planifié est exécuté dans un contexte synchrone avec des limitations synchrones.
• Tenez compte de la durée d'exécution de la tâche planifiée. Une tâche longue peut chevaucher le début de la tâche planifiée suivante.
• Salesforce planifie l'exécution de la classe à l'heure spécifiée. L'exécution réelle peut être retardée en fonction de la disponibilité du service. L'exécution des tâches planifiées pendant les temps d'arrêt de maintenance du service est planifiée après le retour du service.
• Utilisez System.scheduleBatch pour planifier des tâches par lot plutôt que d'avoir une tâche planifiée dans le seul but de mettre en file d'attente une tâche par lot.

Historiquement, les appels externes synchrones effectués à partir d'une méthode Apex exécutée dans un contexte de transaction Apex synchrone, par exemple un contrôleur Visualforce ou un contrôleur de composant Lightning, étaient soumis à la limite Apex simultanée concernant les requêtes de longue durée. À compter de la version Winter ’19, les appels externes synchrones ne sont plus pris en compte comme des appels de longue durée. Bien que les continuations Apex aient été initialement créées comme solution aux appels externes synchrones qui entraînaient de longues requêtes, elles apportent également quelques avantages supplémentaires.

• Une action synchrone unique peut exécuter jusqu'à trois actions de continuation. La continuation précédente doit être terminée avant l'exécution d'une nouvelle action de continuation.
• Chaque action de continuation peut exécuter jusqu'à trois appels externes, qui sont exécutés en parallèle.
• Lorsque tous les appels externes effectués par une action de continuation sont terminés, la plate-forme invoque la méthode de rappel de continuation pour gérer les résultats.

Bien que les continuations s'exécutent de façon asynchrone par rapport à l'action synchrone d'origine, il existe des différences clés entre les Continuations Apex et les autres techniques Apex asynchrones telles que les méthodes futures, Queueable ou Batch. Les principales différences sont les suivantes :

• Les continuations ne sont en aucun cas mises en file d'attente.
• Les continuations ne contribuent pas à la limite quotidienne en exécutions Apex asynchrones.
• Les continuations basculent le contexte du thread sur le serveur d'applications d'un thread de plate-forme Apex lourd à un thread léger qui effectue uniquement des appels externes. Pour exécuter des appels externes qui peuvent atteindre 120 secondes, les continuations permettent d'économiser considérablement la mémoire du serveur d'applications.
• À l'origine, les continuations ne pouvaient être exécutées que depuis un appel distant Visualforce JavaScript. Cependant, dans la version Summer ‘19, des continuations ont été officiellement ajoutées à l'infrastructure de composants Lightning, ce qui a éliminé la nécessité de Visualforce.

Les événements de plate-forme sont l'implémentation par Salesforce Platform d'une architecture purement pilotée par les événements. Pour plus d'informations sur les composants associés à ce type d'architecture, consultez le Architect’s Guide to Event-Driven Architecture.

Les événements de plate-forme et les déclencheurs/flux d'événements de plate-forme sont souvent d'excellentes alternatives à l'exécution Apex asynchrone. Ils sont également très efficaces pour invoquer le traitement hors plate-forme. Vous pouvez par exemple utiliser une combinaison de relais d'événements Amazon Web Services et d'événements de plate-forme pour invoquer la fonctionnalité de calcul sans serveur dans AWS Lambda. Un travail effectué relativement rapidement et sans appel externe (ce qui n'est pas possible avec un déclencheur ou un flux d'événement de plate-forme) est un excellent candidat pour une combinaison événement/déclencheur de plate-forme ou événement/flux.

Les événements publiés dans le bus via publier après validation sont livrés dans l'ordre et peuvent être traités en masse par le déclencheur ou le flux dans un contexte synchrone séparé. Le contexte est synchrone et applique toutes les limites du gouverneur synchrone. Choisissez soigneusement la taille de lot de déclencheur/flux d'événement de plate-forme pour ne pas atteindre les limites.

• Comme les événements sont publiés dans le bus d'événement, ils sont disponibles pour les consommateurs. Dans le cas de déclencheurs d'événements (Apex ou flux), ces événements sont répartis dans les threads synchrones disponibles au niveau de l'application (un thread par déclencheur/flux d'événements). Notez que ce processus n'a pas d'accord de niveau de service.
• Lorsque des opérations de publication sont ajoutées à la file d'attente, le résultat du processus de mise en file d'attente est stocké dans l'objet Database.SaveResult. Ces entrées indiquent uniquement si l'opération de mise en file d'attente a réussi ou non. Pour obtenir le résultat final d'un événement publié via le bus d'événement, implémentez un rappel Apex publish. Avec ces informations supplémentaires, vous pouvez prendre des décisions sur d'autres actions, par exemple tenter de republier des événements échoués.
• Bien que les événements de plate-forme ne soient pas soumis aux mêmes limitations qu'Apex asynchrone, ils ont leurs propres ensembles de limites de gouverneur. Si vous rencontrez des problèmes avec les limitations, vous pouvez activer les métriques d'utilisation avancées des événements afin de déterminer si des événements spécifiques utilisent plus de vos allocations que prévu. Si vous avez besoin d'un débit supérieur sur les déclencheurs d'événements, vous pouvez utiliser des abonnements parallèles pour traiter les événements simultanément au lieu d'un flux unique. Avec les abonnements parallèles, vous pouvez adapter les déclencheurs d'événements de plate-forme Apex pour gérer des volumes d'événements importants. Les abonnements parallèles sont disponibles pour des événements de plate-forme personnalisés à haut volume, mais pas pour des événements standard ou des événements de modification.
• Les événements de plate-forme ont deux options pour le comportement de publication :
  • Publier immédiatement : Les événements sont publiés immédiatement pendant la transaction, avant l'engagement final de la base de données. Les événements publiés de cette façon ne sont pas garantis d'être publiés dans l'ordre.
  • Publier après l'engagement : Les événements sont publiés lorsque la transaction de base de données est engagée avec succès. Les événements publiés de cette façon sont garantis d'être publiés dans l'ordre.

Il est utile d'utiliser Publier immédiatement pour des cas d'utilisation tels que la consignation, dans lesquels vous souhaitez publier l'événement de consignation, que la transaction réussisse et s'engage, ou échoue et annule. Il est possible de publier immédiatement un événement de plate-forme consommé par un déclencheur d'événement de plate-forme. Le déclencheur d'événement de plate-forme concurrence ensuite la transaction qui l'a publié pour obtenir un verrou de ligne de base de données. Vérifiez attentivement toutes les conceptions avant de publier immédiatement des événements de plate-forme pour éviter ce scénario.

Les flux asynchrones offrent des alternatives à code faible aux Apex asynchrones. Comme avec les autres formes de traitement asynchrone, ils sont exécutés en arrière-plan lorsque des ressources sont disponibles. Les flux asynchrones n'ont pas non plus de SLA et peuvent avoir des temps d'attente imprévisibles.

Les parcours planifiés sont basés sur un déclencheur cron à exécuter à une heure spécifique. Ils s'exécutent lors de la création, de la mise à jour ou de la suppression d'enregistrements et permettent de contrôler avec précision l'exécution de l'automatisation par rapport au changement d'enregistrement. (Exemple : envoyer un e-mail à un utilisateur une heure avant l'échéance d'une tâche). Contrairement aux futures méthodes Apex, qui sont limitées à 50 méthodes maximum mises en file d'attente dans une transaction synchrone, les actions de flux planifiées n'ont actuellement pas de limite maximale en file d'attente par transaction. Cependant, la définition du parcours planifié contient une configuration de taille de lot qui permet de contrôler le nombre d'enregistrements traités par l'exécution du flux du parcours planifié.

Les parcours asynchrones peuvent être ajoutés à des flux déclenchés par un enregistrement. Ils sont exécutés en arrière-plan et ne retardent pas l'exécution de la transaction qui a déclenché le flux. Vous pouvez utiliser un parcours asynchrone pour exécuter une opération longue ou n'importe quelle opération que vous souhaitez exécuter sur son propre temps. Les parcours asynchrones peuvent éviter les erreurs DML mixtes qui se produisent lorsque vous devez mettre à jour une valeur dans un enregistrement associé qui ne fait pas partie de l'enregistrement ayant déclenché le flux.

Note : La messagerie sortante est une fonctionnalité héritée et les événements de plate-forme (décrits dans la section précédente) sont une approche plus moderne et offrent plus de flexibilité. Les événements de plate-forme sont le modèle recommandé par Salesforce pour l'intégration pilotée par l'événement.

Les messages sortants fournissent un moyen de communication sortante asynchrone via l'API SOAP. Lorsqu'elle est configurée dans Salesforce, la définition du message sortant produit un WSDL SOAP qui peut être consommé par un fournisseur de services Web externe. Les messages sortants peuvent être déclenchés à partir de règles de workflow, de processus du Générateur de processus ou de déclencheurs de flux Lightning after-save. Un message SOAP sortant peut contenir jusqu'à 100 notifications. Chaque notification contient l'ID d'objet et une référence aux données sObject associées. Si les informations de l'objet sous-jacent changent après la mise en file d'attente de la notification, mais avant son envoi, seules les toutes dernières données sont livrées, pas les modifications intermédiaires.

Lorsqu'un écouteur de message sortant (le service Web que vous avez configuré avec le WSDL généré) reçoit un message, il utilise les informations d'ID de session incluses pour appeler l'API Lightning Platform afin de mettre à jour l'enregistrement dans Salesforce qui a déclenché le message sortant.

• Les messages sortants ne sont pas gérés via l'infrastructure asynchrone basée sur la file d'attente dans Salesforce qui exécute des activités telles que les méthodes futures, Apex Queueable, Apex Batch, API de transfert en masse, etc. À la place, les enregistrements sont stockés localement dans l'objet OutboundMessage. Les messages sont distribués et réessayés via un processus en arrière-plan planifié local.
• Les messages ne sont pas envoyés de façon synchrone lorsque l'action de message sortant est exécutée par l'automatisation initiatrice (par exemple, un déclencheur de flux après la sauvegarde). À la place, ils restent dans l'objet OutboundMessage jusqu'à ce qu'ils soient envoyés avec succès ou abandonnés après 24 heures de livraison échouée.
• Pour éviter une boucle infinie de messages sortants, assurez-vous que l'utilisateur qui met à jour les objets ne dispose pas de l'autorisation Envoyer des messages sortants.

E-mail vers requête fonctionne normalement de façon synchrone. Quatre threads synchrones sont limités pour gérer les requêtes E-mail vers requête entrantes. Le formulaire synchrone du gestionnaire maintient une connexion au serveur de messagerie Salesforce entrant (MTA) qui reçoit l'e-mail. Cependant, le traitement E-mail vers requête peut être asynchrone pour plusieurs raisons :

• E-mail vers requête est soumis à des limitations en threads, en particulier 10 threads de gestionnaire au total par serveur d'applications : quatre threads pour le traitement synchrone et six threads pour le traitement asynchrone.
• Si un gestionnaire de messagerie synchrone dépasse 15 secondes de temps d'exécution, cette adresse de service de messagerie est marquée comme asynchrone pendant une période de 30 minutes. Les requêtes ultérieures du gestionnaire pour cette adresse de service entraînent un message mis en file d'attente pour MessageTypeName = MAILCATCHER_EMAIL_TO_CASE, avec une référence au contenu de l'e-mail.
• Si un thread synchrone est déjà utilisé pour une organisation et une adresse de service particulières, les requêtes supplémentaires pour cette adresse de service sont mises en file d'attente de façon asynchrone.
• Si un e-mail traité de façon synchrone rencontre une erreur, par exemple une expiration de verrouillage de ligne, la requête est enregistrée et mise en file d'attente de façon asynchrone.
• Si aucun thread de gestionnaire synchrone n'est disponible, la requête est mise en file d'attente de façon asynchrone.

• Une option de déduplication existe lorsque vous configurez E-mail vers requête, mais elle ne déduplique les pièces jointes qu'après le traitement de l'e-mail. Cette déduplication permet de gagner de l'espace dans la base de données, mais ne réduit pas les temps de traitement des e-mails. Vous pouvez toutefois améliorer les performances en implémentant un gestionnaire E-mail vers requête Apex personnalisé pour le traitement des messages. Cette implémentation n'affecte aucune limite du gouverneur, mais elle accorde au gestionnaire l'accès à l'e-mail et à toutes ses pièces jointes avant tout engagement dans la base de données. Cet accès vous permet de calculer des sommes de contrôle pour toutes les pièces jointes incluses et d'ignorer celles que vous jugez inutiles, y compris les doublons, les images de signature bien connues ou les types de fichier indésirables.
• La validation des pièces jointes aux e-mails dans Salesforce Files est responsable de la majorité du temps de traitement des e-mails. À mesure que les réponses au contact ou à partir de celui-ci augmentent et que la chaîne d'e-mails augmente, le temps de traitement de chaque e-mail augmente également. Si l'option d'e-mail « Répondre uniquement avec un nouveau contenu » n'est pas sélectionnée, les chaînes d'e-mails se développent à chaque réponse. Par conséquent, nous recommandons d'utiliser un gestionnaire E-mail vers requête Apex avec une logique qui implémente la déduplication des pièces jointes au moment du traitement.
• Malgré l'invocation de déclencheurs Apex dans le cadre du traitement, les gestionnaires E-mail vers requête sont exempts de la limite Apex simultanée.

Pour traiter des volumes importants d'enregistrements de façon asynchrone, vous pouvez utiliser l'une des approches ci-dessous.

Vous pouvez utiliser Apex par lot pour élaborer des processus complexes et longs qui impliquent des milliers d'enregistrements. Apex par lot fonctionne en divisant votre ensemble d'enregistrements et en le traitant en segments gérables. Par exemple, vous pouvez élaborer une solution d'archivage exécutée de nuit et ajouter à une archive des enregistrements datant de plus d'une date donnée. Alternativement, vous pouvez élaborer une opération de nettoyage des données qui examine tous les comptes et toutes les opportunités tous les soirs et effectue toutes les mises à jour nécessaires sur la base d'un ensemble de critères prédéfinis.

• Apex par lot est le meilleur pour traiter de grandes quantités de données, car Apex asynchrone a des limites plus élevées que Apex synchrone. Apex par lot est également plus efficace lorsqu'il traite plus d'éléments par lot, car il utilise des opérations en masse qui entraînent moins de frais généraux liés à la gestion des files d'attente. Par conséquent, pour éviter de déclencher le mécanisme de contrôle de flux via une inondation de file d'attente et éviter d"épuiser la limite Apex asynchrone quotidienne, ne créez pas de lots avec des tailles d"étendue réduites ou qui ont des temps de traitement rapides.
• Évitez de mettre en file d'attente les tâches par lot directement à partir d'actions générées par de grands volumes d'activités de l'utilisateur final ou d'appels d'API d'intégration. Cette approche peut rapidement épuiser la file d'attente Flex. Si vous envisagez d'invoquer une tâche par lot à partir d'un déclencheur, vous devez garantir que le déclencheur n'ajoute pas plus de tâches par lot que la limite.
• Apex par lot est limité à cinq threads simultanés maximum, ce qui limite beaucoup plus son débit que les futures méthodes ou Apex Queueable.
• Idéalement, les tâches par lot qui impliquent des volumes de données importants doivent être planifiées pour être exécutées pendant les heures creuses afin de libérer des ressources pour les processus qui nécessitent des réponses en temps réel ou en temps quasi réel.
• Lorsque vous appelez System.scheduleBatch, la plate-forme planifie l'exécution de votre tâche à l'heure que vous spécifiez. L'exécution réelle a lieu à partir de cette date, selon la disponibilité du service.
• Le planificateur est exécuté dans le contexte système. Toutes les classes sont exécutées, que l'utilisateur qui a planifié l'exécution soit autorisé ou non à exécuter la classe.
• Toutes les limites Apex planifiées s'appliquent aux tâches par lot planifiées en utilisant System.scheduleBatch. Une fois la tâche par lot mise en file d'attente (avec un statut En attente ou En file d'attente), toutes les limites en tâches par lot s'appliquent, et la tâche n'est plus prise en compte dans les limites Apex planifiées.
• Pour une tâche par lot avec une planification récurrente, tenez compte du comportement correct si la tâche précédente est toujours exécutée lorsque la nouvelle tâche commence à être exécutée.
• Les tâches par lot mises en file d'attente à partir de transactions Apex synchrones utilisent la file d'attente flexible. La file d'attente flexible est limitée à 100 éléments maximum à tout moment. Si une transaction tente d'ajouter d'autres entrées, la plate-forme génère des erreurs et ne soumet pas la tâche par lot.
• Les appels externes et autres opérations non transactionnelles à partir de tâches par lot doivent respecter des considérations de conception idempotentes. Les tâches par lot mises en file d'attente avant un temps d'arrêt de maintenance du service Salesforce restent dans la file d'attente. Une fois le temps d'arrêt du service terminé et les ressources système disponibles, les tâches par lot en file d'attente sont exécutées. Si une tâche par lot est exécutée en cas d'arrêt, l'exécution par lot est annulée et redémarrée après la restauration du service. Les méthodes execute peuvent donc être exécutées plusieurs fois. Par conséquent, toutes les opérations non transactionnelles, telles que les appels externes, peuvent être réessayées.
• Vous pouvez configurer la tâche par lot pour lever des événements BatchApexErrorEvent afin de gérer les scénarios d'erreur et d'exception.

Un flux déclenché par une planification est un flux dont l'exécution est planifiée à une heure spécifiée et à une fréquence répétée (quotidienne, hebdomadaire ou unique) pour exécuter des actions sur un lot d'enregistrements. (Exemple : mettez à jour un champ dans tous les cas avec un statut « En cours » à 2 heures du matin tous les soirs). Les flux planifiés sont exécutés via le mécanisme de déclenchement cron et sont traités en masse.

• Un flux déclenché par une planification exécute 200 enregistrements par invocation, mais est exécuté avec plusieurs threads simultanés si plus de 200 enregistrements sont présents.
• Les flux déclenchés par une planification sont exécutés dans un contexte synchrone avec des limitations synchrones.
• Actuellement, il n'existe aucun moyen de contrôler le nombre d'enregistrements traités par invocation de flux planifiée. Si l'exécution concerne plus de 200 enregistrements, il existe un réel danger d'erreurs Apex concurrentes.

L'API de transfert en masse est basée sur les principes REST et optimisée pour travailler avec des jeux de données volumineux. Vous pouvez l'utiliser pour insérer, mettre à jour, mettre à jour/insérer, interroger ou supprimer de nombreux enregistrements de façon asynchrone et traiter les résultats ultérieurement. Salesforce Platform traite la requête en arrière-plan. Par contre, l'API SOAP et l'API REST utilisent des requêtes synchrones et sont optimisées pour les applications clientes en temps réel qui mettent à jour quelques enregistrements à la fois. Vous pouvez utiliser ces deux API pour traiter de nombreux enregistrements, mais lorsque les jeux de données contiennent des centaines de milliers d'enregistrements, elles sont moins pratiques. L'infrastructure asynchrone de l'API de transfert en masse est conçue pour faciliter et améliorer le traitement des données de quelques milliers à des millions d'enregistrements.

Pour utiliser l'API de transfert en masse, la méthode la plus simple consiste à l'activer pour traiter les enregistrements dans Data Loader en utilisant des fichiers CSV. Avec Data Loader, il n'est pas nécessaire d'écrire votre propre application cliente. Cependant, des exigences uniques nécessitent parfois d'écrire une application personnalisée.

Deux API de transfert en masse sont disponibles dans Salesforce Platform.

• L'API de transfert en masse est la plus récente. Il fournit un workflow rationalisé et plus facile à utiliser, et est au centre des améliorations.
• L'API de transfert en masse d'origine reste totalement prise en charge, mais n'est plus améliorée. Nous recommandons d'utiliser l'API de transfert en masse 2.0 si possible.

Pour plus d'informations sur les limites en API, consultez Limites en API en masse et Limites en API 2.0 en masse.

Consultez ce guide pour élaborer ou envisager un traitement asynchrone sur Salesforce Platform. Il est toujours recommandé de comprendre l'éventail complet des options qui s'offrent à vous et leur adéquation à votre cas d'utilisation spécifique. Assurez-vous d'évaluer en profondeur votre paysage actuel avant d'apporter des modifications à vos architectures existantes, en particulier si votre solution actuelle fonctionne bien.