Praktik terbaik di Process Builder
Hai, saya membaca buku untuk mempelajari pengkodean apex dan menemukan paragraf ini terkait dengan PB:
Praktik terbaiknya adalah memastikan bahwa untuk satu objek ada satu proses Pembuat Proses yang ditentukan dengan semua kontrol yang dikelola melalui satu proses ini. Dalam praktiknya, ini tidak selalu dapat dipelihara dan mungkin memerlukan proses untuk dimigrasi ke pemicu Apex. Jika Anda berada dalam situasi di mana Anda memerlukan lebih dari satu proses per objek, Anda harus mempertimbangkan untuk memigrasi proses ini ke Apex.
Battisson, Paul. Mempelajari Pengembangan Salesforce dengan Apex: Menulis, Menjalankan, dan Menerapkan Kode Apex dengan Mudah (Edisi Bahasa Inggris) (p. 26). Publikasi BPB. Edisi menyalakan.
Apa yang saya pahami dari sini adalah bahwa semua pembaruan yang dilakukan pada objek di Pembuat proses harus dijalankan hanya dalam 1 proses ?!
Saya agak khawatir karena kami memiliki 10+ Proses pada masing-masing objek kami ...
Jawaban
Memiliki pembangun proses tunggal untuk sebuah objek adalah pendekatan yang tepat, tetapi pengecualian untuk aturan ini adalah jika Anda memiliki satu pembuat proses untuk peristiwa pembuatan dan satu untuk peristiwa pembaruan.
Untuk batas PB untuk suatu objek Periksa pertanyaan ini di salesforce.stackexchange.com
Untuk praktik terbaik bagi pembuat proses, buka tautan berikut:
10 praktik terbaik untuk PB
Praktik Terbaik Pembangun Proses Salesforce
Jika ada pertanyaan lain yang ingin Anda tanyakan melalui pertanyaan ini, harap perbarui pertanyaannya.
Bersulang
Ya, konsolidasi arus dianggap sebagai praktik terbaik. Setelah bekerja di organisasi tempat kami didorong untuk mengonsolidasikan aliran Pembangun Proses, saya dapat berbicara tentang hal positif dan negatif. Alasan kami didorong ke arah ini adalah karena kami mencapai batas gubernur pada operasi penyimpanan kami untuk beberapa objek. Konsolidasi aliran ini memperbaiki masalah ini sejauh aliran Anda berkontribusi padanya. Jika Anda memiliki organisasi yang sangat kompleks dan mengamati pengecualian batas gubernur, Anda harus mempertimbangkan konsolidasi aliran sebagai langkah awal untuk mengatasinya.
Mengenai kerugiannya, ada beberapa. Manajemen versi Anda menjadi sedikit lebih berantakan, untuk satu hal. Dan penanganan error yang buruk pada aliran diperburuk karena pada dasarnya Anda hanya akan tahu "ada yang salah di Process Builder" tanpa indikasi apa pun dari node mana yang menyebabkan masalah. Sementara masalah langsung mengirimkan email kesalahan yang memberikan detail lebih lanjut, masalah apa pun dalam pengujian unit membuat Anda bingung. Anda benar-benar tidak memiliki cara untuk menyelidiki selain menjalankan tes dan berharap Anda dapat melacak file log yang benar dan bagiannya. Itu bisa sangat rumit jika Anda memiliki kesalahan yang hanya terjadi selama validasi penerapan, terutama karena organisasi tempat Anda harus mempertimbangkan strategi ini cenderung membutuhkan waktu lama untuk memvalidasi.
Jika Anda melakukan konsolidasi, saya sangat menyarankan untuk menambahkan bidang ke objek Anda yang memungkinkan Anda untuk melewati arus Anda untuk tujuan pengujian unit. Jika tidak, seluruh sistem Anda akan menjadi terlalu rapuh untuk dikelola.
Saya telah membaca rekomendasi ini juga, tetapi bagi saya pemeliharaan / keterbacaan proses sangat penting. Saya memiliki tepat 10 proses untuk Akun, beberapa di antaranya untuk acara pembuatan, beberapa di antaranya untuk acara pembaruan.
Beberapa proses menyalin bidang, membuat objek lainnya, beberapa meminta peringatan email. Semua ini tentunya memiliki kondisi yang berbeda-beda. Beberapa bahkan menelurkan aksi di masa depan. Untuk menempatkan ini hanya dalam dua proses (satu untuk pembuatan, satu untuk pembaruan) akan menghasilkan proses yang sangat besar, jika bisa dilakukan sama sekali.
Untuk menjelaskan lebih lanjut tentang aspek pemeliharaan: misalkan Anda hanya memiliki satu proses per objek dan anggap Anda sedang mengerjakan fungsionalitas baru, di kotak pasir. Katakanlah perbaikan cepat harus dilakukan pada produksi. Perbaikan ini tidak ada hubungannya dengan fungsionalitas baru, tetapi ini berlaku untuk objek yang sama. Daripada Anda berkewajiban untuk menerapkannya ke kotak pasir Anda juga, karena itu semua adalah satu proses besar. Dan ini bukan pembaruan proses yang elegan: set perubahan hanya menambahkan versi baru, itu tidak akan menggabungkan apa pun.
Selain itu, jika Anda ingin menonaktifkan sementara sedikit fungsionalitas: saat Anda memiliki proses terpisah, Anda cukup menonaktifkan yang sesuai. Jika Anda memiliki satu proses besar, Anda harus mengedit beberapa kondisi, di suatu tempat, saya kira, dan ingat di mana Anda telah melakukan apa. Semoga beruntung dengan itu.
Menempatkan semua fungsionalitas untuk suatu objek dalam satu proses besar bertentangan dengan semua pelajaran yang telah kita pelajari tentang pemeliharaan.
Jadi untuk saat ini saya menyimpannya dalam proses terpisah. Adapun rekomendasi untuk bermigrasi ke kelas Apex: itu konyol. Anda sebaiknya hanya mempertimbangkan pemrograman Apex jika Anda tidak dapat memenuhi persyaratan melalui proses / aliran / alur kerja. Kode apex jauh lebih rentan terhadap kesalahan dan membuat organisasi Anda jauh lebih tidak fleksibel.