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

Для мэтча номера клиента и поиска персонального менеджера как раз и хочется делать SQL запрос в CRM. Все остальное телефонная платформа делает.

ну можно написать просто джава делегат который этот селект сделает, со схемы вызвать его по имени

пока пытаемся без джавы обходиться. ext worker-ами. то что с джавой можно сделать в камунда что угодно - это понятно..

полюбите джаву (или котлин) и перестаньте страдать :)

Там сложности могут быть.
Потому что у делегата есть таймаут. И с запросами к БД это как раз может заафектить.
@abaranchuk может подробнее рассказать.

понятное дело могут,  там поток блочится

И это тоже плюс.

отладка в один клик, деплои удобные, тесты общие...

Так и сделайте worker который отрабатывает external task. Там нет ограничений по времени. Можете на 99 лет забирать задачу

Под капотом делегат работает очень схоже с external task, т.е. engine вычитывает и лочит задачу (по дефолту минут на 10). Если делегат успевает выполниться за это время, то все ок... Но если стабильно больше этого времени, то это приводит к ошибке OptimisticLock, откату транзакции и выполнение таски по новой. В конечном счете выполнение делегата бесконечно циклится. Так что прежде чем ставить делегат лучше убедиться что он не блокирует транзакцию на длительное время

"Единственное я бы от SQL избавился, и завернул базу в HTTP сервис" - каждый новый запрос расширяющий функциональность оборачивать в REST не особо интересная работа. Ее как раз и хочется свести к 0.

😁👍

Не совсем так, там тоже есть таймер когда задача вернётся в пул доступных

вам виднее. Глобально у запросов SQL проблема в том, что сетевые запросы невозможно балансировать, впринципе 3 уровень OSI чувствительнее к качеству сети,  + вы начинаете знать структуру табличек внутри, что накладывает ограничение на их модификацию с той стороны и еще какие-то аргументы наверное есть.  Но обычно у CRM систем есть миллион апи уже ,в том числе автоматически генерируемые

Так я про него и говорю. Заберите на 99 лет. Тогда остаётся только complete если уж взялись выполнять. А всю обработку исключений на воркере делать

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

Ааа

Пожно использовать GraphQL вместо простого REST для расширяемых запросов к БД. Но проблемы скорости и таймаутов это не решит

Проще уж котлин выучить, чем прикручивать эту шайтан технологию :)