IK
последнее не понял
Size: a a a
2020 November 07
N
а ктонить использует аналоги камунды на js? пока найден bpmn-engine, хотелось бы отзывы послушать
IK
блин с экстернал тасками там будет же проблема, что если процесс 3 дня у них занимает, то я не буду знать - у меня сервис забрал таску и потерял по пути или она улетела и ждет, как это решается? мне же придется огромные таймауты ставить чтобы не задублировались процессы из-за таймаутов и перехвата джобов
MD
блин с экстернал тасками там будет же проблема, что если процесс 3 дня у них занимает, то я не буду знать - у меня сервис забрал таску и потерял по пути или она улетела и ждет, как это решается? мне же придется огромные таймауты ставить чтобы не задублировались процессы из-за таймаутов и перехвата джобов
Ваш процесс должен идти дальше после отправки запроса?
MD
последнее не понял
Имелось ввиду без людей. Как можно больше делать все автоматически.
OG
Информ безопасность может не пройти. Пароли с логинами достать с истории процессов Камунды легко можно будет.
Мне видится, что такое надо решать архитектурно и не гонять пароль/хэш по камунде, а после согласования кидать юзеру ссыль на интерфейс киклоак, в котором тот сможет зарегаться
OG
И уже в плагин keycloak вставить проверку согласования аккаунта
OG
Камунда вообще не упрощения бекенда. Вот эти траблы с паролями только первые звоночки. А как траффик пойдёт, то будет ещё много разных приколов.
На этот случай zeebe?
AD
Привет.
Делегаты при этом зло.
Лучше пользовать external tasks.
1. https://docs.camunda.org/manual/latest/user-guide/process-engine/external-tasks/
2. https://m.habr.com/ru/company/tinkoff/blog/490656/
3. https://github.com/camunda-consulting/external-task-worker-examples
Делегаты при этом зло.
Лучше пользовать external tasks.
1. https://docs.camunda.org/manual/latest/user-guide/process-engine/external-tasks/
2. https://m.habr.com/ru/company/tinkoff/blog/490656/
3. https://github.com/camunda-consulting/external-task-worker-examples
Почему тут многие против делегатов? Был печальный опыт ?
MD
Artur Dauer
Почему тут многие против делегатов? Был печальный опыт ?
Против только в асинхронных взаимодействиях.
Потому что:
1. Держится тред и транзакция
2. Имеет ограничение по времени выполнения.
3. Используются ресурсы jvm камунды
Потому что:
1. Держится тред и транзакция
2. Имеет ограничение по времени выполнения.
3. Используются ресурсы jvm камунды
MD
Но и в синхронных тоже стоит учитывать пункты выше написанные. Потому что есть вероятность упасть быстро и постоянно, если не учитывать это.
K
Кто то пробовал интеграцию комунда с проектом на Go?
AD
Против только в асинхронных взаимодействиях.
Потому что:
1. Держится тред и транзакция
2. Имеет ограничение по времени выполнения.
3. Используются ресурсы jvm камунды
Потому что:
1. Держится тред и транзакция
2. Имеет ограничение по времени выполнения.
3. Используются ресурсы jvm камунды
1 Тред, на сколько мне известно освобождается при асинхронных вызовах, до асинхронного ответа. Иначе бы миллионы инстанций в день валили бы все процессы
2. Ограничения времени выполнения чего ?
3. Используются так же как при экстернал тачках
А так, конечно, интересный вопрос, когда какой подход реализации лучше использовать
2. Ограничения времени выполнения чего ?
3. Используются так же как при экстернал тачках
А так, конечно, интересный вопрос, когда какой подход реализации лучше использовать
MD
Artur Dauer
1 Тред, на сколько мне известно освобождается при асинхронных вызовах, до асинхронного ответа. Иначе бы миллионы инстанций в день валили бы все процессы
2. Ограничения времени выполнения чего ?
3. Используются так же как при экстернал тачках
А так, конечно, интересный вопрос, когда какой подход реализации лучше использовать
2. Ограничения времени выполнения чего ?
3. Используются так же как при экстернал тачках
А так, конечно, интересный вопрос, когда какой подход реализации лучше использовать
1. Делегат это грубо говоря одна функция, которая конечно может в нескольких потоках вызвать другие методы. Но она сама выполняется в одном треде. И в одной транзакции.
2. Ограничение на выполнение делегата. По умолчанию вроде как 10 мин(не помню уже сколько)
3. Нет. Т.к. экстернал таска это просто запись в БД о том что процесс пришел на этот шаг и ждет пока его пошлют дальше
2. Ограничение на выполнение делегата. По умолчанию вроде как 10 мин(не помню уже сколько)
3. Нет. Т.к. экстернал таска это просто запись в БД о том что процесс пришел на этот шаг и ждет пока его пошлют дальше
SD
1. В Java все-таки асинхронщина своеобразная. В любом случае где-то будет блокировка на ожидании результата. И т.к. на уровне самой камунды это не поддерживается, то делегат будет держать поток, пока не получит результат. Плюс большая проблема "длинная транзакция".
3. На экстернал таске транзакция как-раз таки закрывается, и новая откроется как только будет получен результат.
3. На экстернал таске транзакция как-раз таки закрывается, и новая откроется как только будет получен результат.
SD
Недавно был опыт прикручивания реактивщины к экстернал таскам. Получилось прикольно. Пока обкатываем. Возможно в скором времени подготовлю статью на эту тему.
MD
Недавно был опыт прикручивания реактивщины к экстернал таскам. Получилось прикольно. Пока обкатываем. Возможно в скором времени подготовлю статью на эту тему.
MD
Недавно был опыт прикручивания реактивщины к экстернал таскам. Получилось прикольно. Пока обкатываем. Возможно в скором времени подготовлю статью на эту тему.
На камунде тоже эндпоинты переписали на реактивщину?
MD
Мы решили пока что это с помощью листенеров и MQ
SD
Пока нет. Решали проблему вызова сторонних сервисов с неопределенным временем ответа. И там только rest