Один JSON-поток для разных команд

Приложение отправляет JSON в один канал. Ошибки production нужны эксплуатации, заявки — поддержке, а неизвестные типы событий — ответственному за интеграцию. Настроим три правила, общий шаблон и предсказуемый маршрут без совпадения.

Подготовьте получателей и канал

1. В организации создайте команды «Эксплуатация» и «Поддержка» и добавьте сотрудников. Выберите отдельного сотрудника, ответственного за интеграцию.
2. Создайте входящий канал «События приложения». Оставьте базовых получателей пустыми: команды и ответственного назначим через правила.
3. После подключения правил каждый потенциальный получатель открывает «Моя доставка» и выбирает свои подтверждённые способы для этого канала. Канал будет виден даже при отключённых правилах или подключениях.
4. В каталоге «Метки» этой организации создайте production, поддержка и неизвестное.
5. В разделе «Шаблоны» создайте текстовый шаблон «Событие приложения» и выберите его у канала:

{{json.service}}: {{message}}
Важность: {{importance}}
Метки: {{tags}}

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

Добавьте правила

В разделе «Правила обработки» создайте следующие определения в контексте организации. Условия для первых двух объедините режимом «Все условия». Значения JSON сравнивайте с типом «Строка».

Порядок	Название и вид	Условия	Действия
1	Ошибка production, по условиям	JSON environment равно production; JSON event.type равно service_failed	Взять текст из JSON message; важность «Критично»; метки: только production; получатели: только «Эксплуатация»
2	Новая заявка, по условиям	JSON event.type равно ticket_created	Взять текст из JSON message; важность «Информация»; метки: только поддержка; получатели: только «Поддержка»
Default	Неизвестное событие, по умолчанию	Условий нет	Взять текст из JSON message; важность «Предупреждение»; метки: только неизвестное; получатель: только ответственный за интеграцию

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

1. В «Текст сообщения и переменные» добавьте «Взять текст из JSON», путь message.
2. Через «Добавить действие» задайте важность, метки и «Параметры доставки».
3. В доставке отметьте нужную команду или сотрудника. Правило добавит их к базовым назначениям; в этом примере базовый список пуст.
4. Действие шаблона не добавляйте: все три правила наследуют шаблон канала.
5. Сохраните определения, подключите к каналу и проверьте порядок.

Если одно событие должно получить несколько команд, выберите их в одном победившем правиле. Следующее совпавшее правило уже не исполнится.

Проверьте разные события

В «Проверить на примере» используйте application/json и последовательно вставьте три тела.

Ошибка production:

{
  "service": "api",
  "environment": "production",
  "event": {
    "type": "service_failed"
  },
  "message": "API недоступен"
}

Новая заявка:

{
  "service": "portal",
  "environment": "production",
  "event": {
    "type": "ticket_created"
  },
  "message": "Создана заявка №42"
}

Неизвестный тип:

{
  "service": "api",
  "environment": "staging",
  "event": {
    "type": "maintenance_finished"
  },
  "message": "Обслуживание завершено"
}

Пример	Выбранная ветка	Получатели	Важность	Метки
Ошибка production	Ошибка production	Эксплуатация	critical	production
Новая заявка	Новая заявка	Поддержка	info	поддержка
Неизвестный тип	Неизвестное событие, default	Ответственный за интеграцию	warning	неизвестное

Итоговый текст первого примера:

api: API недоступен
Важность: critical
Метки: production

Дополнительно проверьте ошибку с environment: "staging": она попадёт в default. Удаление event.type тоже приведёт к default; отсутствующий путь не удовлетворяет сравнению. Подробнее — условия JSON.

Отправьте реальные запросы

Сохраните первое тело как event.json, замените адрес канала и выполните:

curl --include \
  --request POST \
  --header 'Content-Type: application/json' \
  --data-binary @event.json \
  'https://depesher.ru/w/ВАШ_PUBLIC_ID'

Для защищённого канала добавьте Bearer-токен. Повторите с двумя другими телами. Каждый реальный запрос создаёт новое сообщение; симуляция ничего не сохраняет и не отправляет.

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

Если отключить определение или подключение первого правила, production-ошибка попадёт в активный default, а не в «Эксплуатацию». Сотрудники эксплуатации при этом продолжают видеть канал в «Моей доставке». Если при пустой базе отключить и default, событие без совпадения не создаст личных назначений сотрудникам. Для проверки результата обработки используйте симуляцию: общей истории всех сообщений организации у администратора нет.

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

Вариант для личных уведомлений

Та же схема работает в личном контексте. Вместо команд выбирайте исходящие каналы в действии доставки. Например, ошибки — Email и Telegram, обычные события — только Email. Для полностью условной внешней доставки оставьте базовые связи входящего канала пустыми. Пустой выбор или отсутствие действия не добавляют направлений: при пустой базе остаётся только личная история, при заданной — базовая отправка продолжается. Пример успеха без внешних уведомлений — CI/CD.

Вариант с ошибкой платежа, возвратом и boolean-флагом VIP — бизнес-события. Оформление текста — действия и переменные, поиск результата — история.

Другой вариант одного потока — состояния AI и workflow: ошибки, ожидание ввода и завершение с разными получателями.