Best Practices für Process Builder
Hallo, ich lese ein Buch, um die Apex-Codierung zu lernen, und habe diesen Absatz im Zusammenhang mit PB gefunden:
Eine bewährte Methode besteht darin, sicherzustellen, dass für ein einzelnes Objekt ein einzelner Process Builder-Prozess definiert ist, bei dem alle Steuerelemente über diesen einen Prozess verwaltet werden. In der Praxis ist dies nicht immer wartbar und erfordert möglicherweise eine Migration des Prozesses auf einen Apex-Trigger. Wenn Sie sich in einer Situation befinden, in der Sie mehr als einen Prozess pro Objekt benötigen, sollten Sie diese Prozesse auf Apex migrieren.
Battisson, Paul. Lernen der Salesforce-Entwicklung mit Apex: Schreiben, Ausführen und Bereitstellen von Apex-Code mit Leichtigkeit (englische Ausgabe) (S. 26). BPB-Veröffentlichungen. Kindle Edition.
Ich verstehe daraus, dass alle Aktualisierungen, die an einem Objekt im Process Builder vorgenommen wurden, in nur einem Prozess ausgeführt werden sollten?!
Ich bin etwas besorgt, da wir auf jedem unserer Objekte mehr als 10 Prozesse haben ...
Antworten
Ein einziger Prozess-Builder für ein Objekt ist der richtige Ansatz. Eine Ausnahme von dieser Regel besteht jedoch, wenn Sie einen Prozess-Builder für Erstellungsereignisse und einen für Aktualisierungsereignisse haben.
Informationen zum PB-Limit für ein Objekt Überprüfen Sie diese Frage auf salesforce.stackexchange.com
Die Best Practices für Process Builder finden Sie über die folgenden Links:
10 Best Practices für PB
Best Practices für Salesforce Process Builder
Wenn Sie mit dieser Frage eine andere Frage stellen möchten, aktualisieren Sie die Frage.
Prost
Ja, die Konsolidierung von Flows wird als Best Practice angesehen. Nachdem ich in einer Organisation gearbeitet habe, in der wir gezwungen waren, unsere Process Builder-Flows zu konsolidieren, kann ich sowohl mit den positiven als auch mit den negativen Aspekten sprechen. Der Grund, warum wir in diese Richtung gedrängt wurden, ist, dass wir bei unseren Sicherungsvorgängen für mehrere Objekte die Reglergrenzen überschritten haben. Durch die Konsolidierung dieser Flows wird dieses Problem behoben, sofern Ihre Flows dazu beitragen. Wenn Sie eine hochkomplexe Organisation haben und Ausnahmen für Governor-Limits beachten, sollten Sie die Flow-Konsolidierung auf jeden Fall als einen frühen Schritt in Betracht ziehen, um diese zu beheben.
Was die Nachteile betrifft, gibt es einige. Zum einen wird Ihre Versionsverwaltung ein bisschen chaotischer. Die ohnehin schon schlechte Fehlerbehandlung von Flows wird noch verschärft, da Sie im Grunde nur wissen, dass in Process Builder ein Fehler aufgetreten ist, ohne dass angegeben wurde, welcher Knoten das Problem verursacht hat. Während Live-Probleme eine Fehler-E-Mail mit mehr Details senden, bleiben Sie bei jedem Problem in einem Komponententest hoch und trocken. Sie haben buchstäblich keine andere Möglichkeit, als den Test auszuführen und zu hoffen, dass Sie die richtige Protokolldatei und den richtigen Abschnitt davon finden können. Dies kann sehr schwierig sein, wenn Sie einen Fehler haben, der nur während der Bereitstellungsvalidierung auftritt, insbesondere da Organisationen, bei denen Sie diese Strategie berücksichtigen müssen, die Validierung in der Regel lange dauern.
Wenn Sie konsolidieren, empfehle ich dringend, Ihrem Objekt ein Feld hinzuzufügen, mit dem Sie Ihre Flows für Unit-Testzwecke umgehen können. Andernfalls wird Ihr gesamtes System zu spröde, um verwaltet zu werden.
Ich habe diese Empfehlung ebenfalls gelesen, aber für mich ist die Wartbarkeit / Lesbarkeit der Prozesse sehr wichtig. Ich habe genau 10 Prozesse für das Konto, einige davon für Erstellungsereignisse, einige für Aktualisierungsereignisse.
Einige Prozesse kopieren Felder, andere erstellen Objekte, andere rufen eine E-Mail-Warnung auf. All dies hat natürlich unterschiedliche Bedingungen. Einige erzeugen in Zukunft sogar Aktionen. Diese in nur zwei Prozesse (einen für die Erstellung, einen für die Aktualisierung) zu integrieren, würde zu sehr großen Prozessen führen, wenn dies überhaupt möglich ist.
Um mehr über den Aspekt der Wartbarkeit zu sagen: Angenommen, Sie haben nur einen Prozess pro Objekt und arbeiten an neuen Funktionen in einer Sandbox. Angenommen, eine schnelle Lösung muss für die Produktion durchgeführt werden. Dieser Fix hat nichts mit der neuen Funktionalität zu tun, gilt jedoch für dasselbe Objekt. Dann müssen Sie es auch auf Ihre Sandbox anwenden, denn es ist alles ein großer Prozess. Und es ist kein elegantes Update des Prozesses: Ein Änderungssatz fügt einfach eine neue Version hinzu, es wird nichts zusammengeführt.
Wenn Sie eine Funktion vorübergehend deaktivieren möchten: Wenn Sie separate Prozesse haben, deaktivieren Sie einfach die entsprechende. Wenn Sie einen großen Prozess haben, müssen Sie irgendwo eine Bedingung bearbeiten und sich daran erinnern, wo Sie was getan haben. Viel Glück damit.
Das Zusammenführen aller Funktionen für ein Objekt in einem großen Prozess widerspricht allen Lektionen, die wir über die Wartbarkeit gelernt haben.
Im Moment halte ich sie in getrennten Prozessen. Die Empfehlung, auf Apex-Klassen zu migrieren, ist einfach lächerlich. Sie sollten die Apex-Programmierung nur in Betracht ziehen, wenn Sie die Anforderungen nicht über Prozesse / Flows / Workflows erfüllen können. Apex-Code ist viel fehleranfälliger und macht Ihre Organisation viel unflexibler.