• Accueil / Salesforce / Limites de transaction…
, Limites de transaction dans Salesforce (Apex et Flow)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">9</span> minutes de lecture</span>

Limites de transaction dans Salesforce (Apex et Flow)9 minutes de lecture


, Limites de transaction dans Salesforce (Apex et Flow)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">9</span> minutes de lecture</span>

introduction

L’hiver 22 introduit la capacité de
annuler les modifications d’enregistrement en attente lorsqu’un élément de flux échoue au moment de l’exécution. J’ai eu deux réactions à cela – d’abord, c’est bien ; Deuxièmement, comment se fait-il
tu n’as pas toujours fait ça ? Cela m’a ramené aux (très peu) jours où je l’ai fait
Visual Basic fonctionne et a découvert que
les expressions booléennes n’ont pas court-circuité
– c’est quelque chose qui fait partie intégrante d’autres technologies
avec qui j’ai travaillé, il ne m’est jamais venu à l’esprit que ce serait différent.

L’idée originale de cet article était d’appeler le retour en arrière qui ne s’applique qu’aux
la transaction en cours et associez le fonctionnement d’Apex à titre de comparaison. Mais ensuite, il m’est venu à l’esprit que dans le
Écosystème Salesforce il y a beaucoup de gens qui s’apprennent Apex qui pourraient
utiliser probablement un peu plus d’informations sur le fonctionnement des transactions, donc, selon les termes de Henry James a écrit dans sa nécrologie pour George du Maurier
(en référence au roman
Feutre):

« tout le phénomène a grandi et grandi jusqu’à ce qu’il devienne, en tout cas pour ce
victime particulière, une fontaine de ténèbres et un présage de malheur »

Transactions

Une transaction est un ensemble d’actions qui sont appliquées comme une seule unité.
Les transactions assurent l’intégrité de la base de données face aux exceptions,
erreurs, plantages et pannes de courant. Les caractéristiques d’une transaction sont connues sous l’acronyme ACID :

  • Atomique – le travail réussit entièrement ou échoue entièrement. Indépendamment de quoi
    se produit en termes d’échec, la base de données ne peut pas être partiellement mise à jour.

  • Cohérent – lorsqu’une transaction est terminée, la base de données est dans un
    l’état en termes de toutes les règles et contraintes. Cela ne garantit pas les données
    est correct, juste que c’est légal du point de vue de la base de données.

  • Isolé – les modifications apportées au cours d’une transaction ne sont pas visibles par les autres
    utilisateurs/demandes jusqu’à la fin de la transaction.

  • Durable – une fois la transaction terminée, les modifications apportées sont
    permanent.

Transactions dans Apex

Apex est différent d’un certain nombre de langues que j’ai utilisées dans le passé, car il
est étroitement couplé à la base de données. Pour cette raison, vous n’avez pas à vous inquiéter
sur la gestion des transactions à moins que vous ne vouliez prendre le contrôle. Lorsqu’un utilisateur
fait une requête qui appelle votre code, par exemple un composant Web Lightning
appelant une méthode @AuraEnabled, votre code est déjà dans une transaction
le contexte.

Lorsqu’une demande se termine sans erreur, la transaction est automatiquement
commis et toutes les modifications apportées au cours de la demande sont appliquées de façon permanente à
la base de données. Cela entraîne également des travaux tels que l’envoi d’e-mails et
la publication de certains types d’événements de plate-forme à avoir lieu. Envoi d’un e-mail
sur un travail qui n’a pas vraiment eu lieu n’a pas beaucoup de sens, même si
cela nous a causé beaucoup d’angoisse dans le passé alors que nous essayions de trouver des moyens de nous connecter à
un système externe qu’une transaction avait échoué (Publish Immediately platform
les événements nous ont finalement donné un mécanisme pour y parvenir).

Lorsqu’une requête rencontre une erreur, la transaction est automatiquement lancée
en arrière et toutes les modifications apportées au cours de la demande sont rejetées. Souvent l’utilisateur
reçoit une trace de pile moche, c’est là que vous pourriez décider que vous avez besoin d’un
un peu plus de contrôle sur la transaction.

Attraper des exceptions

En interceptant une exception, vous pouvez interroger l’objet exception pour savoir
ce qui s’est réellement passé et de formuler un beau message d’erreur à envoyer à l’utilisateur.
Cependant, à moins que vous ne présentiez ce message à l’utilisateur, vous avez modifié le
comportement de la transaction, peut-être sans s’en rendre compte. Par exemple, si vous
intercepter une exception et renvoyer un message encapsulant ce qui s’est passé :

Account acc=new Account(Name='TX Test');
Contact cont=new Contact(FirstName='Keir', LastName='Bowden');
String result='SUCCESS';
try {
   insert acc;
   cont.AccountId=acc.Id;
   insert cont;
}
catch (Exception e) {
    result='Error ' + e.getMessage();
}

return result;

Dans mon organisation de développement, j’ai configuré une règle de validation que l’un des e-mails ou du téléphone doit
être défini, donc l’insertion du contact échoue et je vois une assez belle erreur
un message:

, Limites de transaction dans Salesforce (Apex et Flow)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">9</span> minutes de lecture</span>

Malheureusement, ce n’est pas le seul problème avec mon code – car j’ai attrapé le
exception, la demande n’a pas échoué donc la transaction n’a pas été automatiquement
annulées. Alors que du point de vue de l’utilisateur, la demande a échoué, le premier
une partie a réussi et un compte nommé TX Test a été créé :

, Limites de transaction dans Salesforce (Apex et Flow)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">9</span> minutes de lecture</span>

et chaque fois que l’utilisateur réessaie la demande, j’obtiens un autre compte TX Test
et ils recevront un autre message d’erreur.

Reprendre le contrôle

Heureusement, Apex m’appuie là-dessus, et si je le veux (et je sais ce que je fais)
Je peux prendre le contrôle de la transaction et y apporter quelques nuances, plutôt que
tout réussit ou échoue.

Les points de sauvegarde vous permettent de créer ce qui peut être considéré comme sous-jacent ou imbriqué
transactions. Un point de sauvegarde identifie un point dans une transaction qui peut être
annulé, annulant tout le travail après ce point mais conservant tout le travail avant
à ce point. Changer mon extrait d’en haut pour utiliser un point de sauvegarde et
rollback, je peux m’assurer que toutes mes modifications réussissent ou échouent :

SavePoint preAccountSavePoint=Database.setSavePoint();
Account acc=new Account(Name='TX Test');
Contact cont=new Contact(FirstName='Keir', LastName='Bowden');
String result='SUCCESS';
try {
   insert acc;
   cont.AccountId=acc.Id;
   insert cont;
}
catch (Exception e) {
    result='Error ' + e.getMessage();
    Database.rollback(preAccountSavePoint);
}

return result;

L’expérience de l’utilisateur reste la même – il reçoit un message d’erreur convivial indiquant que l’insertion a échoué. Cette fois, cependant, il n’est pas nécessaire de débarrasser ma base de données du compte gênant. Avant d’effectuer une DML, j’ai créé un point de sauvegarde et, dans mon gestionnaire d’exceptions, je suis revenu à ce point de sauvegarde, annulant tout le travail entre les deux – l’insertion du compte qui a réussi. Notez que l’annulation de la transaction n’a aucun effet sur mes variables locales – avant l’instruction de retour, j’ai un compte en mémoire qui a un identifiant attribué à partir de la base de données, mais qui n’existe plus. Bien sûr, cela laisse également en place tout autre travail qui s’est produit dans la transaction en dehors de mon code, ce qui peut ou non être ce que je veux, donc prendre le contrôle des transactions ne doit pas être fait à la légère.

Les points de sauvegarde sont également utiles s’il existe un certain nombre de plans d’action également valables pour votre code. Vous définissez un point de sauvegarde et essayez l’option 1, si cela ne fonctionne pas, vous revenez en arrière et essayez l’option 2 et ainsi de suite. C’est assez rare dans mon expérience, car il y a généralement une exigence spécifique autour d’une action de l’utilisateur, mais cela arrive, comme lorsque l’option 2 écrit les détails de comment et pourquoi l’option 1 a échoué.

Vous pouvez également définir plusieurs points de sauvegarde, chacun annulant de moins en moins de travail, et choisir jusqu’où la restauration en cas d’erreur. Vos collègues ne vous remercieront probablement pas pour cela, et sont plus susceptibles de voir cela comme une combinaison de Circles of Hell dans le vôtre. Enfer. Si vous choisissez d’emprunter cette voie, notez que lorsque vous revenez à un point de sauvegarde, tout ce que vous avez créé depuis n’est plus valide, vous ne pouvez donc pas basculer entre les différentes versions de la base de données à volonté.

Les points de sauvegarde ne fonctionnent que dans la transaction en cours, donc si vous exécutez un travail par lots qui nécessite 10 lots pour traiter tous les enregistrements, l’annulation du lot 10 n’a aucun effet sur les lots 1 à 9, car ceux-ci ont eu lieu dans leurs propres transactions qui se sont terminées avec succès .

Annulation des transactions de flux

Après cette longue diversion dans Apex, j’espère que vous comprendrez pourquoi je m’attends à ce que tout annule automatiquement la transaction en cas d’erreur – cela fait longtemps que cela n’a pas été mon problème. Selon les notes de version de Winter 22, le flux ne fait pas ceci :

Auparavant, lorsqu’une transaction se terminait, ses modifications d’enregistrement en attente étaient enregistrées dans la base de données même si un élément de flux échouait dans la transaction

et gardez à l’esprit que c’est toujours le cas – ce qui a été ajouté est un nouvel élément Roll Back Records que vous pouvez utiliser dans un chemin d’erreur. Pourquoi cela n’a-t-il pas été modifié pour revenir automatiquement en cas d’erreur ? Pour la même raison que Visual Basic n’a pas commencé à court-circuiter les expressions booléennes – il existe une tonne de solutions existantes et certaines d’entre elles s’appuieront sur le fonctionnement du flux de cette façon. Bien que ce ne soit pas idéal, l’introduction d’un changement radical dans l’automatisation client existante n’est pas non plus.

Une autre chose à garder à l’esprit est que cela annule la transaction en cours, pas nécessairement tout le travail qui a eu lieu dans le flux. Selon l’article d’aide Flux dans les transactions Salesforce, une transaction de flux se termine lorsqu’un élément Screen, Local Action ou Pause est exécuté. Poursuivant avec mon approche Compte et contact, si vous avez inséré le compte, puis utilisez un élément Screen pour demander à l’utilisateur le nom du contact, le compte est engagé dans la base de données et persistera quoi qu’il arrive à votre tentative de créer un Contact. Tout comme la note Apex du lot ci-dessus, l’annulation de la deuxième transaction (Contact) n’a aucun effet sur la première transaction (Compte) car celle-ci s’est déjà terminée avec succès.

Vous aimez les transactions ?

Essayer transactions distribuées:

, Limites de transaction dans Salesforce (Apex et Flow)<span class="wtr-time-wrap after-title"><span class="wtr-time-number">9</span> minutes de lecture</span>

Puis les faire évoluer sur de nombreux microservices.

Il y a de nombreuses années, je devais gérer moi-même les transactions et, dans un cas particulier, j’ai dû travailler sur la répartition des transactions sur un certain nombre de systèmes disparates. C’était un travail intéressant et stimulant, mais ça ne me manque pas!

Articles Similaires





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Vous utilisez Pardot depuis un certain temps mais vous n'êtes pas sûr d'en
exploiter tout le potentiel

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer