#Событие после действия

#Введение

Все изменения данных, которые пользователь вносит в системе, обычно выполняются через действие, чаще всего по нажатию кнопки. Это может быть кнопка отправки формы или кнопка действия в блоке данных. Событие после действия используется для привязки связанных рабочих процессов к действиям этих кнопок, чтобы после успешного выполнения пользовательского действия запускался заданный процесс.

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

На уровне реализации обработка события после действия выполняется в слое промежуточного ПО (middleware Koa), поэтому вызовы HTTP API в NocoBase также могут запускать определённые события после действия.

#Установка

Это встроенный плагин, установка не требуется.

#Настройка триггера

#Создание рабочего процесса

При создании рабочего процесса выберите тип «Событие после действия»:

#Режим выполнения

Для событий после действия при создании также можно выбрать режим выполнения: «Синхронный» или «Асинхронный»:

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

#Настройка коллекции

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

#Выбор режима триггера

Далее выберите режим триггера: локальный или глобальный:

Где:

• Локальный режим срабатывает только на кнопках действия, к которым привязан этот рабочий процесс. Нажатие кнопок без такой привязки его не запускает. Можно выбирать, где привязывать рабочий процесс, в зависимости от того, должны ли формы с разным назначением запускать один и тот же процесс.
• Глобальный режим срабатывает на всех настроенных кнопках действий коллекции, независимо от того, из какой формы они вызваны, и без необходимости привязывать соответствующий рабочий процесс.

В локальном режиме сейчас поддерживаются такие кнопки для привязки:

• Кнопки «Отправить» и «Сохранить» в форме добавления.
• Кнопки «Отправить» и «Сохранить» в форме обновления.
• Кнопка «Обновить данные» в строках данных (таблица, список, канбан и т.д.).

#Выбор типа действия

Если выбран глобальный режим, дополнительно нужно выбрать тип действия. Сейчас поддерживаются «Действие создания данных» и «Действие обновления данных». Оба действия запускают рабочий процесс после успешного выполнения действия.

#Выбор предзагружаемых связанных данных

Если в последующих процессах нужно использовать связанные данные из данных триггера, выберите поля связей для предзагрузки:

После срабатывания эти связанные данные можно напрямую использовать в процессе.

#Настройка действия

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

Рабочие процессы, настроенные на кнопку «Отправить» (включая кнопку «Сохранить данные»), запускаются после отправки пользователем соответствующей формы и завершения действия с данными.

Выберите «Привязать рабочий процесс» в меню конфигурации кнопки, чтобы открыть всплывающее окно настройки привязки. В нём можно настроить любое количество запускаемых рабочих процессов. Если ничего не настроено, значит запуск не требуется. Для каждого рабочего процесса сначала укажите, являются ли данными триггера данные всей формы или данные конкретного поля связи в форме. Затем, исходя из коллекции выбранной модели данных, выберите рабочий процесс формы, заранее настроенный под эту модель коллекции.

#Пример

Ниже демонстрация на примере действия создания.

Предположим, есть сценарий «Заявка на возмещение». После отправки сотрудником заявки на возмещение нужно выполнить автоматическую проверку суммы и ручную проверку для сумм выше лимита. Только заявки, прошедшие проверку, одобряются и передаются в финансовый отдел для обработки.

Сначала можно создать коллекцию «Возмещение» со следующими полями:

• Название проекта: однострочный текст
• Заявитель: многие-к-одному (Пользователь)
• Сумма: число
• Статус: одиночный выбор («Одобрено», «Обработано»)

Затем создайте рабочий процесс типа «Событие после действия» и настройте в триггере модель коллекции «Возмещение»:

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

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

После завершения настройки формы вернитесь к оркестрации логики рабочего процесса. Например, если сумма больше 500, требуется ручная проверка администратором, иначе заявка одобряется напрямую. После одобрения создаётся запись возмещения и передаётся на дальнейшую обработку в финансовый отдел (опущено).

Если не учитывать последующую обработку в финансовом отделе, настройка процесса заявки на возмещение на этом завершена. Когда сотрудник заполняет и отправляет заявку, запускается соответствующий рабочий процесс. Если сумма расходов меньше 500, запись создаётся автоматически и ожидает дальнейшей обработки финансами. Иначе заявка проверяется руководителем, и после одобрения запись также создаётся и передаётся в финансы.

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

#Внешний вызов

Запуск событий после действия не ограничен операциями в пользовательском интерфейсе; его также можно выполнять через вызовы HTTP API.

Для рабочего процесса, локально привязанного к кнопке действия, вызов выглядит так (на примере кнопки создания коллекции posts):

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "title": "Hello, world!",
    "content": "This is a test post."
  }'
  "http://localhost:3000/api/posts:create?triggerWorkflows=workflowKey"

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

После успешного вызова будет запущено событие после действия для соответствующей коллекции posts.

Если в этом действии нужно запускать событие для данных связи «один-к-одному» (связь «один-ко-многим» пока не поддерживается), используйте ! в параметре, чтобы указать данные триггера поля связи:

curl -X POST -H 'Authorization: Bearer <your token>' -H 'X-Role: <roleName>' -d \
  '{
    "title": "Hello, world!",
    "content": "This is a test post.",
    "category": {
      "title": "Test category"
    }
  }'
  "http://localhost:3000/api/posts:create?triggerWorkflows=workflowKey!category"

После успешного вызова будет запущено событие после действия соответствующей коллекции categories.

#Частые вопросы

#Отличие от «События до действия»

• Событие до действия: срабатывает до выполнения действия (например создание, обновление и т.д.). До выполнения действия запрошенные данные можно валидировать или обработать в рабочем процессе. Если рабочий процесс завершён (запрос перехвачен), действие (создание, обновление и т.д.) не выполняется.
• Событие после действия: срабатывает после успешного действия пользователя. На этом этапе данные уже успешно отправлены и сохранены в базе, и связанные процессы могут продолжаться на основе успешного результата.

Как показано на рисунке ниже:

#Отличие от «Событий коллекции»

События после действия и события коллекции похожи тем, что оба запускаются после изменения данных. Однако уровни реализации различаются: события после действия работают на уровне API, а события коллекции — при изменении данных в коллекции.

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

Запуск событий коллекции не включает информацию о пользователе. В отличие от них, события после действия ближе к пользовательскому уровню и являются результатом действий пользователя. Контекст рабочего процесса также содержит пользовательские данные, поэтому он лучше подходит для обработки процессов, связанных с действиями пользователя. В дальнейшем дизайне NocoBase список событий после действия для запуска может быть расширен, поэтому более рекомендуется использовать события после действия для обработки процессов, где изменения данных вызваны действиями пользователя.

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