Najlepsze praktyki w programie Process Builder
Cześć, czytam książkę, aby nauczyć się kodowania wierzchołków i znalazłem ten akapit związany z PB:
Najlepszą praktyką jest upewnienie się, że dla pojedynczego obiektu istnieje zdefiniowany jeden proces Konstruktora procesów z całą kontrolą zarządzaną przez ten jeden proces. W praktyce nie zawsze jest to możliwe do utrzymania i może wymagać migracji procesu do wyzwalacza Apex. Jeśli znajdziesz się w sytuacji, w której potrzebujesz więcej niż jednego procesu na obiekt, powinieneś rozważyć migrację tych procesów do Apex.
Battisson, Paul. Nauka rozwoju Salesforce za pomocą Apex: Pisz, uruchamiaj i wdrażaj kod Apex z łatwością (wersja angielska) (s.26). Publikacje BPB. Wersja Kindle.
Z tego rozumiem, że wszystkie aktualizacje obiektu w Kreatorze procesów powinny być uruchamiane tylko w jednym procesie ?!
Jestem trochę zaniepokojony, biorąc pod uwagę, że mamy ponad 10 procesów na każdym z naszych obiektów ...
Odpowiedzi
Posiadanie jednego konstruktora procesów dla obiektu jest właściwym podejściem, ale wyjątkiem od tej reguły jest sytuacja, gdy masz jednego konstruktora procesów dla zdarzeń tworzenia i jednego dla zdarzeń aktualizacji.
O limit PB dla obiektu Sprawdź to pytanie na salesforce.stackexchange.com
Aby zapoznać się z najlepszymi praktykami dla konstruktora procesów, skorzystaj z tych linków:
10 najlepszych praktyk dla PB
Najlepsze praktyki Salesforce Process Builder
Jeśli jest jakieś inne pytanie, które chciałeś zadać w tym pytaniu, zaktualizuj pytanie.
Twoje zdrowie
Tak, konsolidacja przepływów jest uważana za najlepszą praktykę. Pracując w organizacji, w której zostaliśmy poproszeni o konsolidację naszych przepływów kreatora procesów, mogę mówić zarówno o pozytywach, jak i negatywach. Powodem, dla którego popychano nas w tym kierunku, jest to, że osiągaliśmy limity gubernatora dotyczące naszych operacji składowania dla kilku obiektów. Konsolidacja tych przepływów rozwiązuje ten problem w stopniu, w jakim przyczyniają się do niego przepływy. Jeśli masz bardzo złożoną organizację i przestrzegasz wyjątków od limitów zarządcy, zdecydowanie powinieneś rozważyć konsolidację przepływu jako wczesny krok w celu rozwiązania tych problemów.
Jeśli chodzi o wady, jest kilka. Po pierwsze, zarządzanie wersjami staje się bardziej skomplikowane. A już i tak słaba obsługa przepływów jest zaostrzona, ponieważ w zasadzie wiesz tylko „coś poszło nie tak w programie Process Builder” bez żadnego wskazania, który węzeł spowodował problem. Podczas gdy problemy na żywo wysyłają wiadomość e-mail o błędzie zawierającą więcej szczegółów, każdy problem w teście jednostkowym powoduje, że jesteś odprężony i suchy. Nie będziesz miał dosłownie żadnego innego sposobu na zbadanie sprawy poza uruchomieniem testu i nadzieją, że możesz wyśledzić właściwy plik dziennika i jego sekcję. Może to być dość trudne, jeśli wystąpi błąd, który pojawia się tylko podczas walidacji wdrożenia, zwłaszcza że organizacje, w których musisz wziąć pod uwagę tę strategię, zwykle zajmują dużo czasu, aby zweryfikować.
Jeśli przeprowadzasz konsolidację, zdecydowanie polecam dodanie pola do obiektu, które umożliwia ominięcie przepływów na potrzeby testów jednostkowych. W przeciwnym razie cały system stanie się zbyt kruchy, aby nim zarządzać.
Przeczytałem również tę rekomendację, ale dla mnie łatwość utrzymania / czytelność procesów jest bardzo ważna. Mam dokładnie 10 procesów dla konta, część z nich dla wydarzeń tworzenia, część dla wydarzeń aktualizacji.
Niektóre procesy kopiują pola, inne tworzą obiekty, kilka wywołuje alert e-mail. Oczywiście wszystkie mają inne warunki. Niektórzy nawet odradzają akcje w przyszłości. Umieszczenie ich w zaledwie dwóch procesach (jeden do tworzenia, jeden do aktualizacji) spowodowałoby bardzo duże procesy, jeśli w ogóle można to zrobić.
Aby powiedzieć więcej o aspekcie konserwacji: załóżmy, że masz tylko jeden proces na obiekt i przypuśćmy, że pracujesz nad nową funkcjonalnością w piaskownicy. Powiedzmy, że na produkcji trzeba zrobić szybką naprawę. Ta poprawka nie ma nic wspólnego z nową funkcjonalnością, ale dotyczy tego samego obiektu. Wtedy jesteś zobowiązany zastosować go również do swojej piaskownicy, ponieważ to wszystko jest jednym dużym procesem. I nie jest to elegancka aktualizacja procesu: zestaw zmian po prostu dodaje nową wersję, niczego nie scali.
Ponadto, jeśli chcesz tymczasowo wyłączyć jeden bit funkcji: gdy masz oddzielne procesy, po prostu dezaktywujesz odpowiedni. Jeśli masz jeden duży proces, cóż, myślę, że musisz gdzieś edytować jakiś warunek i pamiętać, gdzie co zrobiłeś. Powodzenia z tym.
Umieszczenie wszystkich funkcji obiektu w jednym dużym procesie jest sprzeczne ze wszystkimi lekcjami, których nauczyliśmy się na temat łatwości konserwacji.
Więc na razie trzymam je w osobnych procesach. Jeśli chodzi o zalecenie migracji do klas Apex: to jest po prostu śmieszne. Powinieneś rozważyć programowanie Apex tylko wtedy, gdy nie możesz spełnić wymagań za pośrednictwem procesów / przepływów / przepływów pracy. Kod Apex jest znacznie bardziej podatny na błędy i sprawia, że Twoja organizacja jest znacznie mniej elastyczna.