temporalio/temporal

Конструктор сценариев в RetailCRM и при чем тут Temporal [Часть 1] В последнем релизе RetailCRM мы запустили раздел Сценарии. Если объяснять просто, можно накидывать на холсте сложную логику процессов, в первую очередь коммуникации с клиентами через email, чаты, sms, но не только. А чтобы не составлять руками, научили AI-помощника собирать сценарии по вводным от пользователя. Но обо всём по порядку. Модуль сложный и интересный, кажется, тянет на серию постов. Расскажу сначала, в чем были технические сложности задачи. Вводные были таковы: 1. Создание и запуск динамических workflow Пользователь должен сам настроить логику сценария, а мы её выполнить 2. Асинхронное выполнение сценариев Сценарий должен запуститься по событию и пройти свой путь, не блокируя точку запуска сценария. События могут вызываться часто). 3. Распределенность выполнения сценария Разные функции RetailCRM физически локализованы в разных сервисах. Созданное решение должно обеспечивать распределенное прохождение разных частей сценария в разных сервисах. 4. Протяженное время выполнения сценария Должны быть блоки ожидания от нескольких минут до месяцев. Сценарии могут выполняться долго и не должны «ломаться» при деплоях новых версий. Примеры: • отправили письмо → ждем час → проверяем, что письмо не открыто → отправляем чат-сообщение • заказ перешел в статус Выполнен → ждем 3 месяца → проверяем, что за 3 месяца у клиента не было заказов → отправляем каскад имейл/чат/смс с предложением повторить заказ 5. Отказоустойчивость выполнения сценариев Должна быть заложена обработка неудачного выполнения шагов. Это может быть временная недоступность внешних сервисов (например, email-транспорт), внутренних сервисов, временные ошибки. Возможность задать логику ретраев и времени ожидания выполнения шага. 6. Версионность сценариев Например, пользователь создал первую версию сценария и запустил её. После этого изменил флоу сценария и запустил обновленную версию. Все срабатывания первой верс