Столкнулся с ситуацией когда на организации около 6-ти Managed Package и некоторых из них имеют триггеры на Account и Lead. И приходиться писать свои триггеры, на те же самые объекты. В итоге при попытке запуска батча или использования Data Loader, получаю ошибки. Это или UABALE TO LOCK ROW или CPU time limit который приходит от одного из managed package. Все проверки сделал, никаких бесконечных циклов нет. Может кто-то сталкивался с такой ситуацией?
Из того что сталкивался. очень влияет Process builder. Он проверяет запись и ничего с ней не делает. но пр иэтом cpu time хавает будь здоров.
Потом искал решение и нашел. Уменьшайте размер батча. В некоторых случая даже до 1-й записи. Офециальынй ответ по cpu limit от sf.
Вся боль началась в том что я пробовал по 1 записи передавать в батч. И тут тоже ошибки.
Хорошая практика - выключать триггеры через custom settings, вполне возможно что Ваши пакетные триггеры тоже могут отключаться, посмотрите в пакетных custom settings.
А затем, перед запуском батча или импорта - отключить всё лишнее.
1 Вподобання
Спасибо, попробую
Ще важливий момент в якому порядку обробляются рекорди, хоча я думаю ти знаєш, що краще сортувати по parent record, коли обробляются children. Тому що, при процесінгу child record, блокується parent record і якщо в тебе в batch child record йдуть скажемо по CreatedDate будеш ловити помилки.
1 Вподобання
В итоге пришлось отключать все process созданные из process builder. Чтобы сделать апдейте 130 записей. Каждая обновлялась по паре минут. Будьте бдительны с тему процессами которые к вам приходят. Ещё manged package, они тоже в себе могу нести много проблем.
ми якось хотіли всі трігери перекинути в процесс білдер, ну як ми хотіли, клієнт хотів і мотивував фінансово, після купи проблем, схожих на твою, ми все ревертнули, я взагалі процесс білдер тепер користуюсь в крайніх випадках. Дуже важко координувати ці інстанси разом.
1 Вподобання
Згоден. Краще перевести усі процеси в apex code. И проблем стане набагато маньше