Это может показаться довольно простым вопросом, но я не могу найти документацию, в которой это четко указано. У меня есть сомнения по поводу этих вопросов -

  1. Учитываются ли действия построителя рабочих процессов/процессов, такие как обновления полей, в ограничениях DML?
  2. Когда рабочий процесс (или любой другой инструмент автоматизации) выбирает записи на основе критериев фильтрации, учитывается ли это в ограничениях SOQL?
  3. Если используются операторы DML, выполняется ли операция в случае рабочих процессов? Я знаю, что транзакция усложнена в сборщиках процессов, но не уверена в рабочих процессах.
  4. Что произойдет, если превышены ограничения регулятора, а для аргумента allorNone установлено значение false в методе Database.update? Будет ли откатываться вся транзакция независимо от значения, переданного в аргументе, или она будет частично успешной, даже если будут превышены ограничения регулятора?
  5. Я знаю, что большинство лимитов регулятора рассчитываются для каждой транзакции. Мне все еще интересно, есть ли дневной лимит на операторы SOQL/DML.

Если есть какая-либо документация по этому поводу, поделитесь ссылкой в ​​разделе комментариев, и мы можем закрыть этот вопрос. Я провел свое честное исследование, прежде чем прибегнуть к этому порталу, чтобы задать этот простой вопрос.

Большое спасибо.

3
Ayush Goyal 15 Янв 2020 в 20:43
1
Это похоже на то, что вы можете проверить самостоятельно. Создайте новую песочницу разработки, измените запись, проверьте журналы отладки, создайте рабочий процесс, измените ту же запись, проверьте журналы отладки.
 – 
gNerb
15 Янв 2020 в 20:06

1 ответ

  1. да
  2. Зависит - если это построитель процессов, работающий над обновлением/созданием объекта, то объекты уже существуют, и фильтрация аналогична тому, как вы делаете это в контексте триггера вершины. Если вы выполняете компонент Get Record в потоке, это будет запрос.
  3. Я считаю, что да, хотя я не могу найти никакой документации, которая прямо говорит об этом. Обратите внимание, что обновления полей рабочего процесса запускают триггеры before update и after update еще раз, поэтому вы можете подтвердить, что он просто повторно запускает тот же пакет записей в триггере.
  4. Если вы достигаете своих пределов, то вы достигаете своих пределов. Он не будет продолжать завершаться - не путайте его, продолжая завершать работу из-за сбоя операции записи (столкновение с правилом проверки) и достижения ваших пределов. Обычно вы можете использовать класс Limits также проверять перед выполнением операций.
  5. За транзакцию — без дневного лимита в отношении SOQL или DML. Обратите внимание, что действия электронной почты и рабочего процесса на основе времени имеют ограничения, основанные на времени.

Подробнее об ответах выше:

В Документации по ограничениям процессов указано, что действия потока учитываются, когда вы ожидаете им (запросы и обновления). Если вы думаете об этом, PB просто выполняет апекс в бэкэнде с более простым в использовании пользовательским интерфейсом.

enter image description here

Затем просмотрите документ Триггеры и порядок выполнения. , он охватывает все упомянутые вами средства автоматизации, которые будут учитываться при этом.

У потоков даже есть собственная документация, касающаяся ограничений, которые они могут достичь в своих Per- Документ с ограничениями потока транзакций и статья о об увеличении количества потоков в транзакциях

enter image description here

enter image description here

Я полагаю, что правила рабочего процесса усложнены тем, что они выполняют правила рабочего процесса для пакета записей.

Вся документация, связанная с лимитами, относится к каждой транзакции (у электронных писем есть дневные лимиты).

2
Kris Goncalves 15 Янв 2020 в 21:34