Best practice su Process Builder
Ciao, sto leggendo un libro per imparare la codifica apex e ho trovato questo paragrafo relativo a PB:
Una best practice consiste nell'assicurare che per un singolo oggetto ci sia un unico processo Process Builder definito con tutto il controllo gestito attraverso questo processo. In pratica, ciò non è sempre gestibile e potrebbe richiedere la migrazione del processo a un trigger Apex. Se ti trovi in una situazione in cui hai bisogno di più di un processo per oggetto, dovresti considerare la migrazione di questi processi ad Apex.
Battisson, Paul. Imparare a sviluppare Salesforce con Apex: scrivere, eseguire e distribuire Apex Code con facilità (edizione inglese) (p. 26). Pubblicazioni BPB. Edizione Kindle.
Quello che ho capito da questo è che tutti gli aggiornamenti eseguiti su un oggetto in Process Builder dovrebbero essere eseguiti in un solo processo ?!
Sono un po 'preoccupato dato che abbiamo più di 10 processi su ciascuno dei nostri oggetti ...
Risposte
Avere un unico generatore di processi per un oggetto è l'approccio giusto, ma l'eccezione a questa regola è quando si dispone di un generatore di processi per gli eventi di creazione e uno per gli eventi di aggiornamento.
Per il limite di PB per un oggetto, controllare questa domanda su salesforce.stackexchange.com
Per le migliori pratiche per il generatore di processi, passare attraverso questi collegamenti:
10 best practice per PB
Best practice per Salesforce Process Builder
Se ci sono altre domande che intendevi fare con questa domanda, aggiorna la domanda.
Saluti
Sì, il consolidamento dei flussi è considerato una best practice. Avendo lavorato in un'organizzazione in cui siamo stati spinti a consolidare i nostri flussi di Process Builder, posso parlare sia degli aspetti positivi che negativi. Il motivo per cui siamo stati spinti in questa direzione è perché stavamo raggiungendo i limiti del governatore sulle nostre operazioni di salvataggio per diversi oggetti. Il consolidamento di questi flussi risolve questo problema nella misura in cui i flussi vi contribuiscono. Se hai un'organizzazione molto complessa e osservi le eccezioni dei limiti del governatore, dovresti assolutamente considerare il consolidamento del flusso come primo passo per affrontarle.
Per quanto riguarda gli svantaggi, ce ne sono alcuni. La tua gestione delle versioni diventa un po 'più complicata, per prima cosa. E la già scarsa gestione degli errori dei flussi è esacerbata perché fondamentalmente saprai solo "qualcosa è andato storto in Process Builder" senza alcuna indicazione di quale nodo abbia causato il problema. Mentre i problemi live inviano un'e-mail di errore che fornisce maggiori dettagli, qualsiasi problema in uno unit test ti lascia su di giri. Non avrai letteralmente modo di indagare se non eseguire il test e sperare di poter rintracciare il file di registro corretto e la sua sezione. Ciò può essere piuttosto complicato se si verifica un errore che si verifica solo durante la convalida della distribuzione, soprattutto perché le organizzazioni in cui è necessario considerare questa strategia tendono a richiedere molto tempo per la convalida.
Se consolidi, ti consiglio vivamente di aggiungere un campo all'oggetto che ti consenta di bypassare i flussi per scopi di test unitario. Altrimenti, l'intero sistema diventerà troppo fragile da gestire.
Ho letto anche questa raccomandazione, ma per me la manutenibilità / leggibilità dei processi è molto importante. Ho esattamente 10 processi per l'account, alcuni per eventi di creazione, alcuni per eventi di aggiornamento.
Alcuni processi copiano i campi, altri creano oggetti, molti invocano un avviso di posta. Tutti questi hanno condizioni diverse ovviamente. Alcuni addirittura generano azioni in futuro. Metterli in due soli processi (uno per la creazione, uno per l'aggiornamento) risulterebbe in processi molto grandi, se possibile.
Per dire di più sull'aspetto della manutenibilità: supponiamo di avere un solo processo per oggetto e supponiamo di lavorare su nuove funzionalità, in una sandbox. Diciamo che una soluzione rapida deve essere eseguita in produzione. Questa correzione non ha nulla a che fare con la nuova funzionalità, ma si applica allo stesso oggetto. Quindi sei obbligato ad applicarlo anche alla tua sandbox, perché è tutto un grande processo. E non è un elegante aggiornamento del processo: un changeset aggiunge semplicemente una nuova versione, non unirà nulla.
Inoltre, se vuoi disabilitare temporaneamente un po 'di funzionalità: quando hai processi separati, devi semplicemente disattivare quello appropriato. Se hai un grande processo, beh, devi modificare alcune condizioni, da qualche parte, immagino, e ricordare dove hai fatto cosa. Buona fortuna.
Mettere tutte le funzionalità di un oggetto in un unico grande processo va contro tutte le lezioni che abbiamo imparato sulla manutenibilità.
Quindi per il momento li tengo in processi separati. Per quanto riguarda la raccomandazione di migrare alle classi Apex: è semplicemente ridicolo. Dovresti considerare la programmazione Apex solo se non puoi soddisfare i requisiti tramite processi / flussi / flussi di lavoro. Il codice Apex è molto più soggetto a errori e rende la tua organizzazione molto più rigida.