Медиа.маги Документация

Last updated

notify

notify, срабатывающий по завершении процесса перекодирования.

1. Сводка

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

2. Когда использовать

  • Оповещение операторов об успехе или неудаче процесса для конвейеров без присмотра (watch-папки, плановые распространения).
  • Отправка вебхуков в систему CI, мониторинговый дашборд или систему управления контентом, чтобы внешняя автоматизация могла отреагировать.
  • Разветвление процесса узлом логики и маршрутизация разных исходов в разные каналы уведомлений — например, успех на статус-доску, а неудачу в дежурный алерт.

3. Входы

Узел notify принимает динамические пины, засеянные из подключений выше по потоку; каждый подключённый пин становится переменной шаблона на форме.

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

    Совместимые узлы выше по потоку:

    • upload — загружает файлы на финальное назначение.
  • Package — пакетная нагрузка процесса, используемая, чтобы шаблон сообщения мог ссылаться на поставку, запустившую уведомление.

    Совместимые узлы выше по потоку:

    • upload — загружает файлы на финальное назначение.

Любая другая переменная, которую вы подключаете (произвольная строка, выход решения узла логики), появляется на форме как дополнительный токен шаблона.

4. Выходы

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

5. Параметры

Форма «Настройки» узла notify (учётные данные SMTP отредактированы перед захватом).

Форма «Настройки» — двухстолбцовая раскладка: подписи слева, поля справа, а переключатель Exchange соседствует с полем SMTP Server. Описаны в порядке следования в форме. Форма ожидает учётные данные SMTP; для доставки по вебхуку направьте SMTP Server на релей, оборачивающий вашу HTTP-цель.

  • Node Label (string, по умолчанию пусто)

    Произвольное имя, отображаемое на плитке узла на холсте.

    • Что задаёт. Подпись над плиткой; на само уведомление не влияет.
    • Когда менять. Задавайте, когда в одном процессе несколько узлов notify — например, один уведомляет операторов об успехе, а отдельный — на ветви неудачи, — чтобы холст читался с одного взгляда.
  • SMTP Server (string, обязателен)

    Имя хоста SMTP-релея, используемого для отправки письма.

    • Что задаёт. Почтовый сервер, к которому подключается процесс по завершении задачи. В сочетании с флажком Exchange определяет транспорт (smtp:// для обычного SMTP, smtp+exchange:// для Microsoft Exchange).
    • Когда менять. Направьте на SMTP-релей, достижимый с раннеров процесса — обычно провайдер транзакционной почты, корпоративный релей или вебхук-мост. Развёртывание читателя определит правильный хост.
  • Exchange (boolean, по умолчанию выкл.)

    Переключает транспорт SMTP на Microsoft Exchange.

    • Что задаёт. Когда включено, узел notify подключается по Exchange-специфичному протоколу вместо обычного SMTP. Полный URL, хранимый в процессе, становится smtp+exchange://<server>.
    • Когда менять. Включайте, когда настроенный релей — сервер Microsoft Exchange, требующий аутентификации в стиле Exchange, а не SMTP по RFC-5321.
  • Username (string, обязателен)

    Учётная запись для аутентификации на SMTP-релее.

    • Что задаёт. Логин, который ждёт релей, в паре с Password ниже.
    • Когда менять. Задавайте выделенную учётную запись уведомлений на релее. Избегайте личного ящика — процесс может слать много уведомлений, а личные учётные данные ротируются.
  • Password (string, обязателен, конфиденциально)

    Секрет в паре с Username.

    • Что задаёт. Учётные данные, которые релей валидирует перед приёмом сообщения.
    • Когда менять. Предпочитайте переменную процесса (например, {{ NotifyPassword }}), заполненную из хранилища секретов, литеральному значению, вставленному в форму. Литеральные пароли путешествуют с JSON процесса при экспорте.
  • To (array из string, обязателен)

    Адреса получателей, один или несколько.

    • Что задаёт. Назначение уведомления. Поле принимает список; каждая запись становится одним RCPT TO.
    • Когда менять. По возможности используйте рассылочный алиас вместо отдельных получателей, чтобы добавление или удаление операторов не требовало правки каждого процесса.
  • Subject (string, опционально)

    Тема письма; поддерживает переменные шаблона.

    • Что задаёт. Текст, который получатель видит в сводке входящих. Переменные в {{ ... }} разрешаются при отправке ({{ Package }}, {{ URL }}, любой динамический пин, который вы подключаете).
    • Когда менять. Задавайте короткую, легко считываемую тему, привязанную к имени процесса и исходу — например, {{ Package }} delivered to {{ URL }} для уведомлений об успехе, {{ Package }} failed для ветвей ошибки.
  • Message (object, опционально)

    Шаблоны тела, ключёванные по исходу. JSON-объект держит шаблон on_ok, срабатывающий при успехе, и шаблон on_fail, срабатывающий при неудаче; может быть задан любой из них или оба.

    • Что задаёт. Тело письма или полезной нагрузки вебхука. Каждый шаблон поддерживает те же переменные {{ ... }}, что и Subject.
    • Когда менять. Пишите различные сообщения on_ok и on_fail, когда хотите, чтобы один узел notify покрывал оба исхода. Используйте один on_ok, если узел подключён только к ветви успеха, а отдельный узел notify стоит на ветви неудачи.

Соответствие JSON-ключей и названий полей

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

JSON-ключ Название поля
URL SMTP Server (плюс переключатель Exchange определяет схему URL)
to To
subj Subject
msg.on_ok / msg.on_fail Message (шаблоны тела on_ok / on_fail)

6. Пример

MP4 with branded logo overlay

Полный разбор — переменные, настройка каждого узла и ожидаемый результат — смотрите в MP4 with branded logo overlay.

7. Где используется

  • MP4 with branded logo overlay — отправляет SMTP-уведомление с URL доставленного MP4, как только задача наложения водяного знака загрузит свой выход.
  • Content-aware preview proxy ladder — уведомляет операторов, когда контентно-осознанная лестница завершается, чтобы выбранный битрейт прокси можно было проверить.

8. Антипаттерны

  • Трактовка notify как транзакционной зависимости. Узел работает по принципу «отправил и забыл»: процесс не блокируется на подтверждении доставки, а сбой релея не валит задачу. Не полагайтесь на него, чтобы вести автоматизацию ниже по потоку, которая должна выполниться ровно один раз — используйте вебхук с очередью-потребителем или запускайте внешний оркестратор через поле URL.
  • Хранение учётных данных в JSON процесса. Литеральные имена пользователей и пароли SMTP, вставленные в форму, путешествуют с процессом при экспорте, импорте и аудит-дампах. Используйте переменные процесса из хранилища секретов и ссылайтесь на них как {{ Variable }} в полях Username / Password.
  • Уведомление на каждом шаге. Процесс с notify, вписанным в несколько промежуточных ветвей, затопляет входящие и приучает операторов игнорировать сообщения. Ограничьте notify исходами, которые получатель обязан увидеть: терминальный успех, терминальная неудача и явные ветви проверки человеком.
Медиа.маги Документация