Процессы: при сохранении или по планировщику?
- Процессы при сохранении выполняются в сохраняющем запросе; связи и последующие объекты часто ещё не созданы.
- Процессы планировщика отделяют интерфейс от работы, но требуют Cron, наблюдения и идемпотентности.
- Неправильная модель проявляется пустыми письмами, зависшими запросами и двойными действиями, а не абстрактной теоретической ошибкой.
Процессы SuiteCRM, исторически Advanced Open Workflow, позволяют условные действия на уровне модуля. На практике они чаще ломаются не из-за движка, а из-за ошибочных предположений о моментеполноты данных и установки связей. Статья поясняет архитектурный выбор с помощью решения, сравнения жизненных циклов и списка тестов.
Какой тип процесса подходит вашему случаю?
Два вопроса — рекомендация. Не замена тестов, а фильтр против самой частой ошибки выбора.
Подходит для вычислений или смены статуса той же записи без зависимых связей и заметного ожидания.
1. Два жизненных цикла: синхронный и асинхронный
Вместо абстрактных определений посмотрим на реальный путь пользователя и системы:
Цикл при сохранении
- 1 Пользователь нажимает «Сохранить»
- 2 HTTP-запрос выполняется, браузер ждёт
- 3 Валидация и хуки перед сохранением
- 4 Запись в базу (INSERT/UPDATE)
- 5 Процесс при сохранении: возможны письма, вебхуки и новые записи
- 6 Ответ браузеру
Цикл планировщика
- 1 Пользователь сохраняет — быстрый ответ
- 2 Интерфейс снова доступен
- 3 Отложенно: Cron / обработчик
- 4 Задача читает текущее состояние базы, связи обычно уже есть
- 5 Пакетные действия без блокировки интерфейса
- 6 Установить флаг статуса / идемпотентности
2. Краткая помощь в выборе
| Вопрос проектирования | Скорее при сохранении | Скорее планировщик |
|---|---|---|
| Связанная запись появляется только после сохранения? | неблагоприятно | подходит |
| Пользователю нужно немедленно видимое поле или ответ? | подходит | с задержкой |
| Внешний API с заметной задержкой? | рискованно в запросе | лучше |
| Большие объёмы / ночные запуски? | не подходит | планировать с фильтрами |
3. Три архитектурные ловушки
Иллюзия подпанелей
Идентификатор основной записи может существовать при сохранении, а связанные записи подпанелей записываться позднее в транзакции или после неё. Процесс, ожидающий контакт предложения, ничего не находит, хотя пользователь только что создал связь в интерфейсе. Мера защиты: Планировщик или осознанный второй шаг, когда связь гарантированно читается.
Рекурсивная бесконечная петля
Процесс меняет поле, вызывает сохранение, запускается снова — до тайм-аута или лимита памяти. Особенно коварно, когда условие и запись касаются одного поля. Мера защиты: Явный флаг обработки, условия без эффекта при повторе, отсутствие лишних сохранений в цепочке.
Неограниченный запуск планировщика
Процесс без узких фильтров даты и статуса после многих лет может обрабатывать огромный архив при каждом Cron. Система внезапно кажется медленной, хотя процесс всегда был таким. Мера защиты: Узкие критерии отбора, статус «обработано», наблюдение за временем и нагрузкой.
4. Готовность к развёртыванию: протокол тестов
Запуск без этих пяти доказательств — работа вслепую независимо от события запуска.
Список проверок тестовой среды
Модуль Workflow Engine в AgenticUltimate использует визуальное моделирование, симуляцию и утверждение версий, чтобы процессы не запускались незаметно. Выбор при сохранении или по планировщику остаётся архитектурным; симуляция не заменяет пять проверок выше.
Workflow Engine ↗5. Границы статьи
Нет гарантии для каждого патча SuiteCRM или набора собственных хуков. Рекомендации — архитектурные ориентиры по типичным ошибкам; решающими остаются тесты вашей установки.