Meilleures pratiques sur Process Builder
Salut, je lis un livre pour apprendre le codage apex et j'ai trouvé ce paragraphe lié à PB:
Une bonne pratique consiste à s'assurer que pour un seul objet, il existe un seul processus Process Builder défini avec tous les contrôles gérés via ce processus. En pratique, cela n'est pas toujours réalisable et peut nécessiter la migration du processus vers un déclencheur Apex. Si vous vous trouvez dans une situation où vous avez besoin de plus d'un processus par objet, vous devez envisager de migrer ces processus vers Apex.
Battisson, Paul. Apprendre le développement Salesforce avec Apex: écrire, exécuter et déployer du code Apex en toute simplicité (édition anglaise) (p. 26). Publications BPB. Édition Kindle.
Ce que je comprends de cela, c'est que toutes les mises à jour effectuées sur un objet dans Process Builder doivent être exécutées en un seul processus?!
Je suis un peu inquiet étant donné que nous avons plus de 10 processus sur chacun de nos objets ...
Réponses
Avoir un générateur de processus unique pour un objet est la bonne approche, mais l'exception à cette règle est lorsque vous avez un générateur de processus pour les événements de création et un pour les événements de mise à jour.
Pour la limite de PB pour un objet Vérifiez cette question sur salesforce.stackexchange.com
Pour les meilleures pratiques pour le générateur de processus, suivez ces liens:
10 bonnes pratiques pour PB
Meilleures pratiques de Salesforce Process Builder
S'il y a autre chose que vous vouliez poser par cette question, veuillez mettre à jour la question.
Acclamations
Oui, la consolidation des flux est considérée comme une bonne pratique. Ayant travaillé dans une organisation où nous avons été poussés à consolider nos flux Process Builder, je peux parler à la fois des aspects positifs et négatifs. La raison pour laquelle nous avons été poussés dans cette direction est que nous atteignions les limites du gouverneur sur nos opérations de sauvegarde pour plusieurs objets. La consolidation de ces flux résout ce problème dans la mesure où vos flux y contribuent. Si vous avez une organisation très complexe et que vous observez des exceptions de limite de gouverneur, vous devez absolument envisager la consolidation de flux comme une première étape pour y remédier.
Quant aux inconvénients, il y en a quelques-uns. Votre gestion de version devient un peu plus un gâchis, d'une part. Et la gestion des erreurs déjà médiocre des flux est exacerbée parce que vous ne saurez fondamentalement que "quelque chose s'est mal passé dans Process Builder" sans aucune indication du nœud à l'origine du problème. Alors que les problèmes en direct envoient un e-mail d'erreur fournissant plus de détails, tout problème dans un test unitaire vous laisse planer. Vous n'aurez littéralement aucun moyen d'enquêter autre que d'exécuter le test et d'espérer pouvoir retrouver le bon fichier journal et sa section. Cela peut être assez délicat si vous rencontrez une erreur qui ne se produit que lors de la validation du déploiement, d'autant plus que les organisations où vous devez considérer cette stratégie ont tendance à prendre beaucoup de temps à valider.
Si vous consolidez, je vous recommande fortement d'ajouter un champ à votre objet qui vous permet de contourner vos flux à des fins de test unitaire. Sinon, tout votre système deviendra trop fragile à gérer.
J'ai également lu cette recommandation, mais pour moi la maintenabilité / la lisibilité des processus est très importante. J'ai exactement 10 processus pour le compte, certains pour les événements de création, certains pour les événements de mise à jour.
Certains processus copient des champs, d'autres créent des objets, plusieurs invoquent une alerte mail. Tous ont bien sûr des conditions différentes. Certains engendrent même des actions dans le futur. Les placer dans seulement deux processus (un pour la création, un pour la mise à jour) entraînerait des processus très volumineux, si cela peut être fait du tout.
Pour en dire plus sur l'aspect maintenabilité: supposons que vous n'ayez qu'un seul processus par objet et que vous travailliez sur de nouvelles fonctionnalités, dans un bac à sable. Disons qu'une solution rapide doit être apportée à la production. Ce correctif n'a rien à voir avec la nouvelle fonctionnalité, mais il s'applique au même objet. Ensuite, vous êtes obligé de l'appliquer également à votre bac à sable, car il s'agit d'un gros processus. Et ce n'est pas une mise à jour élégante du processus: un changeset ajoute simplement une nouvelle version, il ne fusionnera rien.
Aussi, si vous souhaitez désactiver temporairement un bit de fonctionnalité: lorsque vous avez des processus séparés, il vous suffit de désactiver celui qui convient. Si vous avez un gros processus, eh bien, vous devez modifier une condition, quelque part, je suppose, et vous rappeler où vous avez fait quoi. Bonne chance avec ça.
Mettre toutes les fonctionnalités d'un objet dans un seul grand processus va à l'encontre de toutes les leçons que nous avons apprises sur la maintenabilité.
Donc, pour le moment, je les garde dans des processus séparés. Quant à la recommandation de migrer vers les classes Apex: c'est tout simplement ridicule. Vous ne devriez envisager la programmation Apex que si vous ne pouvez pas répondre aux exigences via des processus / flux / workflows. Le code Apex est beaucoup plus sujet aux erreurs et rend votre organisation beaucoup plus rigide.