D
А инцидент это некое событие, которое нужно будет разрешить ручками в GUI Camunda?
Size: a a a
2019 July 17
AK
Ну да, вот так
АВ
Всем привет. Может кто сталкивался:
запускаю camunda локально как fat-jar:
java -jar camunda.jar
...доходит до ...SpringJobExecutor] starting to acquire jobs
и нормально работает.
когда я заворачиваю её в докер:
FROM openjdk:8-jdk-alpine
COPY camunda.jar services/camunda.jar
CMD java -jar services/camunda.jar
и запускаю в openshift она почему-то сама выключается:
доходит до того-же "...starting to acquire jobs" и без ошибок сразу
"...Process application camundaApplication undeployed"
запускаю camunda локально как fat-jar:
java -jar camunda.jar
...доходит до ...SpringJobExecutor] starting to acquire jobs
и нормально работает.
когда я заворачиваю её в докер:
FROM openjdk:8-jdk-alpine
COPY camunda.jar services/camunda.jar
CMD java -jar services/camunda.jar
и запускаю в openshift она почему-то сама выключается:
доходит до того-же "...starting to acquire jobs" и без ошибок сразу
"...Process application camundaApplication undeployed"
D
Кубик заново начинается и после трёх раз будет инцидент
Подскажи, пожалуйста, у меня процесс полностью прерывается, что я делаю не так?
AK
кидаешь BPMNError скорее всего
AK
а нужно просто Exception
D
Кидаю runtime
AK
не надо рантайм. кидай лучше свой
D
не надо рантайм. кидай лучше свой
Делаю так: запускаю процесс из gui, в процессе userTask -> serviceTask(delegate), в делегате стоит просто throw Exception
Сабмичу таску на gui, процесс не двигается дальше, говорит - вылетел exception
Сабмичу таску на gui, процесс не двигается дальше, говорит - вылетел exception
AK
А, галку asynchronous before на делегате надо поставить
AK
Тут транзакция откатывается назад на гуи
D
А если это все делать не через gui, то эту галку тоже ставить нужно? Там ведь тогда транзакция будет откатываться на предыдущую таску
AK
AK
Пока вы точно не уверены, что эта галка вам не нужна - лучше её ставить чтобы токен по всему процессу не ловить
F
Мы сделали так:
1) UI запрашивает список задач -> камунда отдает список согласно аутентификации текущего пользователя -> UI отображает список задач
2) пользователь открывает одну из задач -> запрос в камунду на получение задачи по ID -> камунда отдает ДТО -> UI по formKey понимает какую форму открыть, какие переменные из таска нужны (например ИД заказа) -> подтягивает по ИД заказа всю нужную инфу
3) пользователь заполняет форму и жмет завершить -> UI отправляет нужную инфу в сторонние сервисы и после этого дергает сервис completeTask в камунде с нужными дальше переменными
Камунде нужны переменные только для движения по процессу + ИД бизнес-модели (заявки в этом примере)
1) UI запрашивает список задач -> камунда отдает список согласно аутентификации текущего пользователя -> UI отображает список задач
2) пользователь открывает одну из задач -> запрос в камунду на получение задачи по ID -> камунда отдает ДТО -> UI по formKey понимает какую форму открыть, какие переменные из таска нужны (например ИД заказа) -> подтягивает по ИД заказа всю нужную инфу
3) пользователь заполняет форму и жмет завершить -> UI отправляет нужную инфу в сторонние сервисы и после этого дергает сервис completeTask в камунде с нужными дальше переменными
Камунде нужны переменные только для движения по процессу + ИД бизнес-модели (заявки в этом примере)
У меня вопрос еще возник. А что у вас будет, когда например
сущности положили в бд, вызвали комплит таски и так получилось что комплит не прохдит по причине что данные не валидны с точки зрения процесса(всякое бывает, например поля какого то не хватило или еще чего нибудь)?
На ui соответственно ошибка вылезет, а вот данные в бд как лежали, так и лежат.
По хорошему, на мой взгляд, должен быть произведен откат изменений в бд. То есть транзакция условно от начала заполнения формы до комплита.
сущности положили в бд, вызвали комплит таски и так получилось что комплит не прохдит по причине что данные не валидны с точки зрения процесса(всякое бывает, например поля какого то не хватило или еще чего нибудь)?
На ui соответственно ошибка вылезет, а вот данные в бд как лежали, так и лежат.
По хорошему, на мой взгляд, должен быть произведен откат изменений в бд. То есть транзакция условно от начала заполнения формы до комплита.
AK
Смотрите, вызов task.complete синхронный до ближайшей точки асинхронности и будет сделан в треде контроллера формы. Если у вас откат транзакции прикладной базы привязан к ошибкам в этом треде - он откатит и прикладную и процесснкю бд
AK
А если точка асинхронности - ближайший кубик - таска просто будет закомпличена
D
Пока вы точно не уверены, что эта галка вам не нужна - лучше её ставить чтобы токен по всему процессу не ловить
Спасибо, работает!
А что за токен?
Можешь посоветовать какой-нибудь материал почитать, а то чистую документацию мне очень тяжело, не знаю последовательность
А что за токен?
Можешь посоветовать какой-нибудь материал почитать, а то чистую документацию мне очень тяжело, не знаю последовательность