Лучшие практики по Process Builder
Привет, я читаю книгу, чтобы изучить кодирование вершины, и нашел этот абзац, связанный с PB:
Лучшая практика - обеспечить, чтобы для одного объекта был определен один процесс Process Builder, и все элементы управления управлялись через этот один процесс. На практике это не всегда обслуживается, и может потребоваться перенос процесса на триггер Apex. Если вы оказались в ситуации, когда вам требуется более одного процесса для каждого объекта, вам следует подумать о переносе этих процессов в Apex.
Баттиссон, Пол. Изучение разработки Salesforce с Apex: написание, запуск и развертывание кода Apex с легкостью (английское издание) (стр. 26). Публикации BPB. Kindle Edition.
Из этого я понимаю, что все обновления, сделанные для объекта в построителе процессов, должны выполняться всего в одном процессе ?!
Я немного обеспокоен тем, что у нас есть около 10+ процессов для каждого из наших объектов ...
Ответы
Наличие единого построителя процессов для объекта - правильный подход, но исключением из этого правила является случай, когда у вас есть один построитель процессов для событий создания и один для событий обновления.
Для ограничения PB для объекта. Проверьте этот вопрос на salesforce.stackexchange.com
Чтобы узнать о лучших практиках для построителя процессов, перейдите по этим ссылкам:
10 лучших практик для PB
Рекомендации по построению процессов Salesforce
Если есть какие-либо другие вопросы, которые вы хотели задать этим вопросом, обновите вопрос.
Ура
Да, объединение потоков считается лучшей практикой. Поработав в организации, где нас подтолкнули к консолидации потоков Process Builder, я могу говорить как о положительных, так и о отрицательных моментах. Причина, по которой нас подтолкнули в этом направлении, заключается в том, что мы достигли ограничений регулятора для наших операций сохранения для нескольких объектов. Консолидация этих потоков решает эту проблему в той мере, в какой ваши потоки способствуют этому. Если у вас очень сложная организация и вы наблюдаете исключения из ограничений регулятора, вам определенно следует рассматривать консолидацию потоков как ранний шаг для их устранения.
Что касается минусов, то их несколько. С одной стороны, ваше управление версиями становится немного более беспорядочным. И без того плохая обработка ошибок потоков усугубляется, потому что вы в основном будете знать только «что-то пошло не так в Process Builder» без каких-либо указаний на то, какой узел вызвал проблему. В то время как живые проблемы отправляют электронное письмо с более подробной информацией об ошибке, любая проблема в модульном тесте оставляет вас без внимания. У вас буквально не будет другого способа исследовать, кроме как запустить тест и надеяться, что вы сможете найти нужный файл журнала и его раздел. Это может быть довольно сложно, если у вас есть ошибка, которая возникает только во время проверки развертывания, тем более что организации, в которых вы должны учитывать эту стратегию, обычно требуют много времени для проверки.
Если вы все же консолидируете, я настоятельно рекомендую добавить к вашему объекту поле, которое позволяет вам обходить потоки для целей модульного тестирования. В противном случае вся ваша система станет слишком хрупкой для управления.
Я тоже прочитал эту рекомендацию, но для меня очень важна ремонтопригодность / читаемость процессов. У меня есть ровно 10 процессов для учетной записи, некоторые из них для событий создания, некоторые для событий обновления.
Некоторые процессы копируют поля, другие создают объекты, некоторые вызывают почтовое уведомление. Конечно, все они имеют разные условия. Некоторые даже порождают действия в будущем. Если поместить их всего в два процесса (один для создания, другой для обновления), это приведет к очень большим процессам, если это вообще возможно.
Чтобы сказать больше об аспекте ремонтопригодности: предположим, что у вас есть только один процесс для каждого объекта, и предположим, что вы работаете над новой функциональностью в песочнице. Скажем, на производстве нужно быстро исправить. Это исправление не имеет ничего общего с новой функциональностью, но применяется к тому же объекту. Затем вы должны применить его и к своей песочнице, потому что это все один большой процесс. И это не элегантное обновление процесса: ревизия просто добавляет новую версию, она ничего не объединяет.
Кроме того, если вы хотите временно отключить один бит функциональности: когда у вас есть отдельные процессы, вы просто деактивируете соответствующий. Если у вас есть один большой процесс, ну, вам нужно где-то отредактировать какое-то условие, я думаю, и запомнить, где вы что сделали. Удачи с этим.
Объединение всей функциональности объекта в один большой процесс противоречит всем урокам, которые мы извлекли о ремонтопригодности.
Поэтому на данный момент я храню их в отдельных процессах. Что касается рекомендации перейти на классы Apex: это просто смешно. Вам следует рассматривать программирование на Apex только в том случае, если вы не можете выполнить требования через процессы / потоки / рабочие процессы. Код Apex гораздо более подвержен ошибкам и делает вашу организацию более негибкой.