Перейти к содержимому

Детали выполнения автоматизации

В этом разделе подробно описывается, что вызывает выполнение автоматизации, важные этапы выполнения и что происходит с результатом автоматизации

Встроенная автоматизация

Автоматизация считается встроенной, если триггер использует события before или after (например, beforeCreate и afterCreate).

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

  • События before выполняются первыми, и их результат может повлиять на дальнейшее выполнение операции.

  • События after выполняются после завершения операции, и их результат не влияет на исходную операцию.

Схема 1. Диаграмма предоставляет общее представление о процессе выполнения встроенной автоматизации. Подробное описание приведено ниже.

Подробное описание процесса выполнения встроенной автоматизации:

  • 1. Компонент получает запрос на взаимодействие с ресурсом

    Например, мы хотим создать новую запись или обновить email пользователя.

  • 2. Проверка доступа (Access control) проверяет, может ли инициатор выполнить операцию

    Если у инициатора недостаточно прав для выполнения операции, запрос отклоняется, и автоматизация не запускается.

  • 3. Очистка и проверка данных

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

  • 4. Событие before отправляется в шину событий
    • Если автоматизация синхронная, выполнение операции ожидает завершения события.
    • Если автоматизация асинхронная, операция продолжается без ожидания завершения события.

    Результат выполнения синхронной автоматизации влияет на исходную операцию:

    Если выполнение прошло успешно (без ошибок):

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

    Ошибка выполнения автоматизации завершает только текущую операцию и не отменяет изменения, сделанные в процессе автоматизации.

  • 5. Повторная проверка и очистка данных

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

  • 6. Изменение ресурса

    Исходная операция завершается, и изменения записываются в хранилище.

  • 7. Событие after отправляется в шину событий

    Операция не ожидает завершения события, и результат выполнения автоматизации игнорируется.

Явная автоматизация

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

В некоторых случаях явная автоматизация может заменить необходимость использования маршрутов Sink.

Явная автоматизация выполняется вручную. На фронтенде это обычно инициируется нажатием кнопки, но фактически это HTTP-запрос к конечной точке API.

Скрипты автоматизации и рабочие процессы имеют отдельные конечные точки API для вызова явной автоматизации.

  • Для скриптов автоматизации это: POST $API/$COMPONENT/automation/trigger, где $API — базовый URL вашего API Corta, а $COMPONENT — название компонента, который должен выполнить скрипт (например, compose или system).

  • Для рабочих процессов это: POST $API/automation/$WORKFLOW_ID/exec, где $API — базовый URL вашего API Corta, а $WORKFLOW_ID — ID рабочего процесса, который вы хотите выполнить.

Схема 2. Диаграмма предоставляет общее представление о процессе выполнения явной автоматизации. Подробное описание приведено ниже.

Подробное описание процесса выполнения встроенной автоматизации:

  • 1. Компонент получает запрос на выполнение автоматизации

    Например, пользователь CRM нажимает кнопку для отправки email-сообщения или инициирует исходящий звонок.

  • 2. (Для рабочих процессов) RBAC проверяет, может ли инициатор выполнить автоматизацию.

    Если у инициатора недостаточно прав для выполнения рабочего процесса, запрос отклоняется.

    Настройка контекста безопасности (параметр runAs) не влияет на проверку RBAC на этом этапе. Если автоматизация была вызвана другой автоматизацией с заданным параметром runAs, RBAC проверяет права указанного инициатора.

  • 3. Автоматизация выполняется, и результаты возвращаются в стандартном HTTP-ответе.

    Результаты содержат выходные данные автоматизации, а также метаданные, такие как трассировка выполнения и сообщения об ошибках.

Отложенная автоматизация

Автоматизация считается отложенной, если триггер использует событие onInterval или onTimestamp.

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

В основе работы Corta лежит механизм таймера (ticker), который каждую минуту (по умолчанию) отправляет события onInterval и onTimestamp.

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

Corta отправляет события интервалов (interval) и временных меток (timestamp) для системных и модульных компонентов. Внутренне эти события идентичны, но сохраняются для совместимости с устаревшими версиями.

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

Схема 3. Диаграмма предоставляет общее представление о процессе выполнения отложенной автоматизации. Подробное описание приведено ниже.

Подробное описание процесса выполнения отложенной автоматизации:

  • 1. Системный таймер отправляет события onInterval и onTimestamp

     Эти события отправляются в шину событий.

  • 2. Автоматизация выполняется асинхронно, и результаты игнорируются

    Значение, возвращаемое автоматизацией, не влияет на другие автоматизации.

Автоматизация с использованием Sink

Автоматизация считается sink, если триггер привязан к ресурсу System Sink.

Sink-автоматизация выполняется, когда компонент системы получает HTTP-запрос к конечной точке API /sink. Её выполнение не связано с операциями, такими как ручной запуск или событие.

Sink-автоматизация требует явного указания инициирующего пользователя, так как она выполняется от имени внешнего пользователя, и определить инициатора невозможно.

Схема 4. Диаграмма предоставляет общее представление о процессе выполнения sink-автоматизации. Подробное описание приведено ниже.

Подробное описание процесса выполнения sink-автоматизации:

  • 1. Компонент системы получает HTTP-запрос к конечной точке API /sink.

    Например: GET $API/system/sink/leads/?__sign=$SIGN, где $API — это базовый URL вашего API Corta, а $SIGN — подпись маршрута sink.

    Подробнее о настройке см. в руководстве DevOps (раздел о маршрутах sink).

  • 2. Проверка подписи.

    Сначала проверяется подпись sink, чтобы убедиться, что она не была изменена.

    Подписи sink генерируются динамически на основе секретного ключа JWT и не хранятся в базе данных.

  • 3. Подпись используется для проверки запроса.

    Система проверяет протокол, заголовки, источник и другие ограничения подписи.

  • 4. Событие onRequest отправляется в шину событий.
    • Если автоматизация синхронная, выполнение операции ожидает завершения события.

    • Если автоматизация асинхронная, операция продолжается без ожидания завершения события.

    Результат выполнения синхронной автоматизации влияет на ответ сервера:

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

    • Если выполнение прошло успешно, сервер подготавливает ответ на основе результата выполнения:
      • Устанавливается код состояния и заголовки ответа, 

      • Тело ответа кодируется как поток байтов и отправляется клиенту.

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

    Автоматизация email

    Системная автоматизация email может быть настроена для обработки входящих или исходящих email-сообщений.

    • Получение писем (onReceive)

      Автоматизация выполняется при получении письма системой.

    • Отправка писем (onSend)

      Автоматизация выполняется при отправке письма системой.