Триггеры автоматизации Baserow: настройка и тестирование

Каждый workflow Baserow начинается с триггера - события, которое запускает автоматизацию по расписанию, при изменении данных в таблице, по входящему HTTP-запросу или по команде из другого workflow; статья разбирает все доступные в открытой версии Baserow типы триггеров, их настройку и обязательное тестирование перед публикацией.

Что такое триггеры workflow

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

Каждый workflow Baserow начинается с триггера - события, которое запускает всю последовательность автоматизации. Без триггера workflow не может знать, когда выполняться. Триггеры бывают привязанными ко времени (запуск каждый час), управляемыми данными (при создании строки) или внешними (при получении API-запроса).

Как работают триггеры

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

• строку, которая была создана, изменена или удалена;
• данные, отправленные в HTTP-запросе;
• информацию о времени из периодических триггеров.

Все последующие узлы действий в workflow могут обращаться к этим данным триггера и использовать их для выполнения своих задач.

Доступные типы триггеров

Baserow предлагает несколько категорий триггеров под разные сценарии автоматизации:

• периодический триггер (по времени);
• триггеры изменения таблицы (по данным);
• получение HTTP-запроса (вебхук);
• ручной триггер (по команде).

Периодический триггер (по времени)

Периодический триггер запускает workflow по фиксированному расписанию без участия внешних событий. Так удобно планировать ежедневные отчёты или ночную очистку устаревших данных.

Настройка:

Периодический триггер можно настроить на запуск в любую заданную минуту. В облачной версии Baserow минимальный интервал - 15 минут, а на self-hosted развёртывании интервал можно установить вплоть до одной минуты.

Такой триггер полезен для еженедельной рассылки сводок команде, ежедневного архивирования завершённых задач, ежечасной проверки просроченных записей или ежемесячной автоматической генерации отчётов.

Триггеры изменения таблицы (по данным)

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

Настройка (применимо ко всем триггерам изменения таблицы):

1. Название - задайте понятное имя триггера.
2. Интеграция - выберите интеграцию, подключённую к рабочему пространству. Авторизация аккаунта даёт полный доступ к данным всем, у кого есть права редактирования приложения.
3. База данных - выберите базу данных с нужной таблицей.
4. Таблица - выберите конкретную таблицу для отслеживания.

Пакетное поведение

Когда строки создаются или изменяются через API, поведение триггера зависит от способа отправки строк:

Один запрос создаёт несколько строк: если один API-запрос создаёт сразу несколько строк (например, 10 строк одним пакетом), триггер workflow срабатывает один раз и передаёт массив со всеми затронутыми строками.

Несколько запросов создают отдельные строки: если для каждой строки отправляется отдельный запрос (например, 10 отдельных запросов), триггер workflow срабатывает по одному разу на каждый запрос - в результате получается 10 отдельных запусков workflow.

Изменены значения конкретных полей

Триггер «Изменены значения конкретных полей» запускает workflow только тогда, когда изменяются выбранные поля таблицы Baserow.

Вместо запуска при любом изменении строки можно выбрать одно или несколько полей для отслеживания. Изменения в остальных полях не запустят workflow.

Это удобно для процессов, которые должны выполняться только при изменении важной информации - например, статуса, ответственного или поля согласования.

Настройте триггер, указав:

• Интеграцию - используемую интеграцию Baserow;
• Базу данных - базу данных с нужной таблицей;
• Таблицу - таблицу для отслеживания изменений;
• Поля - одно или несколько полей, изменение значений которых должно запускать workflow.

Workflow запустится только при изменении одного из выбранных полей.

Пример

Workflow согласования расходов должен запускаться только при изменении поля «Статус».

Настройте триггер «Изменены значения конкретных полей» для отслеживания таблицы «Расходы» и выберите поле «Статус». Workflow будет запускаться при каждом изменении статуса, но не при редактировании других полей, например описания или суммы.

Получение HTTP-запроса (вебхук)

Этот триггер создаёт уникальный URL вебхука, который внешние сервисы могут вызвать для запуска workflow. Когда Baserow получает запрос по этому адресу, workflow выполняется с данными запроса в качестве пакета данных. Подробнее о механике работы вебхуков - в статье «Вебхуки Baserow» .

Так можно подключать внешние приложения и сервисы к workflow Baserow, в том числе через интеграции с такими инструментами, как Zapier или Make .

Настройка:

Почему стоит исключать GET-запросы?

GET-запросы используются браузерами и поисковыми роботами для обычных посещений страницы. Исключение GET предотвращает случайный запуск workflow, когда кто-то открывает URL в браузере или поисковая система сканирует страницу. Для намеренных запусков используйте POST, PUT или другие методы.

Типичные сценарии использования:

• обработка платежей из Stripe или PayPal;
• получение отправленных форм с сайта;
• синхронизация данных из внешних CRM-систем;
• запуск workflow из автоматизаций Zapier или Make.

Ручной триггер

Ручной триггер создаёт workflow, который запускается только по требованию.

В отличие от остальных триггеров, он не работает по расписанию, не реагирует на изменение строк и не срабатывает при получении HTTP-запроса. Он запускается только тогда, когда другой workflow или приложение вызывает его через действие «Запустить workflow».

Это удобно для создания переиспользуемых workflow, которые запускаются по мере необходимости.

Настройте триггер, указав:

• Название (необязательно) - произвольное имя триггера.

Дополнительная настройка не требуется.

Ограничения

• Workflow с ручным триггером можно запустить только действием «Запустить workflow».
• Его нельзя запустить периодическим триггером, другим ручным триггером или любым другим триггером напрямую.
• Чтобы запускать ручной workflow автоматически, вызовите его из другого workflow действием «Запустить workflow».

Пример

Создайте workflow «Отправить ежемесячный отчёт» с ручным триггером. Workflow собирает данные по проекту и отправляет уведомление в Slack.

Запланированный workflow выполняется каждый месяц и через действие «Запустить workflow» запускает workflow «Отправить ежемесячный отчёт». Тот же workflow можно запустить и из приложения при нажатии кнопки пользователем - это позволяет переиспользовать логику отчёта, не дублируя её.

Как протестировать триггер

Тестирование формирует пример данных, которые затем используются для настройки действий workflow. Всегда тестируйте триггер, прежде чем добавлять действия.

Тестирование триггеров по времени

1. Настройте параметры периодического триггера.
2. Нажмите «Тестовое событие» на боковой панели настройки триггера.
3. Триггер выполнится один раз немедленно.
4. Проверьте сформированные данные о времени в узле триггера.

Тестирование триггеров изменения таблицы

1. Настройте триггер изменения таблицы.
2. Вручную выполните действие в таблице (создайте, измените или удалите строку ).
3. Нажмите «Тестовое событие» на боковой панели настройки триггера.
4. Baserow зафиксирует последнее подходящее событие.
5. Проверьте данные строки, которые теперь доступны в узле триггера.

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

Тестирование триггеров вебхука

1. Настройте триггер вебхука.
2. Скопируйте сгенерированный URL вебхука.
3. Отправьте тестовый HTTP-запрос на этот URL с помощью инструмента вроде Postman или cURL, тестовой функции внешнего сервиса либо обычной отправки формы.
4. Нажмите «Тестовое событие» в Baserow.
5. Триггер зафиксирует данные отправленного запроса.

Пример тестового запроса (через cURL):

curl -X POST [YOUR_WEBHOOK_URL] \
  -H "Content-Type: application/json" \
  -d '{"customer_name": "John Doe", "amount": 99.99}'

Часто задаваемые вопросы

Можно ли использовать несколько триггеров в одном workflow? Нет. У каждого workflow может быть только один триггер. Если нужно реагировать на несколько разных событий, создайте отдельные workflow - по одному на каждый тип триггера. После единственного триггера можно использовать условную логику (узлы Router) для обработки разных сценариев.

Что произойдёт, если триггер сработает, пока workflow ещё выполняется? Каждое событие триггера создаёт новый запуск workflow. Если workflow ещё обрабатывается, а срабатывает новый триггер, Baserow запустит второй, параллельный запуск. Оба выполнятся независимо, каждый со своим пакетом данных.

Можно ли запустить workflow вручную, не дожидаясь события? Да, используйте кнопку «Запустить тестовый прогон», чтобы выполнить workflow один раз с тестовыми данными - удобно для отладки и разработки. Ручные тестовые запуски не заменяют реальные события триггера в продакшене.

Как узнать, когда триггер сработал в последний раз? Откройте вкладку «История» в автоматизации - там регистрируется каждое событие триггера с отметкой времени, статусом выполнения workflow и результатом.

Можно ли временно отключить триггер, не удаляя workflow? Да, используйте переключатель, чтобы приостановить опубликованный workflow. Это останавливает срабатывание триггера, сохраняя настройки. Включите переключатель обратно, чтобы возобновить автоматизацию.

В чём разница между тестированием и публикацией workflow? Тестирование выполняет workflow один раз с примерными данными для целей разработки. Публикация активирует workflow бессрочно - он продолжит реагировать на события триггера, пока его не приостановят или не снимут с публикации.

Могут ли внешние вебхуки использовать аутентификацию? Сам URL вебхука по умолчанию не требует аутентификации. Для безопасности можно исключить GET-запросы, проверять данные запроса внутри действий workflow, использовать параметры запроса или заголовки, которые предоставляет внешний сервис, и держать URL вебхука в секрете, не публикуя его.

Все API-запросы должны быть в формате JSON. Другие форматы, например XML, не принимаются.

Решение типичных проблем

Тест триггера не показывает данные. Причина: событие-триггер ещё не произошло. Решение: для триггеров изменения таблицы вручную создайте, измените или удалите строку в указанной таблице, а затем протестируйте снова. Для вебхуков сначала отправьте тестовый запрос на URL.

Workflow не срабатывает после публикации. Причина: workflow приостановлен или событие-триггер не происходит. Решение: убедитесь, что переключатель показывает статус «Активен» (не приостановлен). Проверьте, что событие триггера действительно происходит в базе данных или что внешние сервисы отправляют запросы.

Вебхук возвращает ошибку. Причина: внешний сервис использует исключённый HTTP-метод или отправляет некорректные данные. Решение: проверьте, что HTTP-метод разрешён в настройке «Разрешённые HTTP-методы», и посмотрите вкладку «История» на предмет конкретных сообщений об ошибке.

После настройки и теста триггера следующий шаг - собрать действия, которые Baserow выполнит в ответ на сработавшее событие; раздел «Автоматизация Baserow» содержит остальные статьи цикла.