DK
Можно свою реализацию написать, у них там есть точки расширения в historyhandler
Size: a a a
2019 May 22
2019 May 23
AV
Зависит от того, зачем и что вы хотите с этим делать потом
Для распределения нагрузки и ресурсов. Приложение с камундой должно использовать бд для рантайма, а исторические события писать в другую бд. Есть ещё одно приложение с камунда движком на борту, которое используется исключительно для работы с историческими данными посредством camunda history api, оно и работает с этой бд.
AV
Можно свою реализацию написать, у них там есть точки расширения в historyhandler
Это понятно, я даже делал подобную реализацию, которая пишет эти события в elasticsearch. Но в этом случае, нам не нужен велосипед, мы хотим иметь возможность пользоваться camunda history api поэтому нам нужна именно дефолтная имплементация этого хендлера. Вопрос лишь в том как заставить его работать с другой БД?
AV
Если пойти глубже, там все упирается в DbEntityManager, который непосредственно и осуществляет работу с бд. Но как его сконфигурить и создать, я пока ещё не разобрался
DK
Чтобы юзать апи надо поставить nginx, который по сигнатуре запроса будет направлять на рантайм камунду
DK
Или историческую камунду
DK
И.е. основанная пишет в соседнюю базу, на ту соседнюю базу смотрит камнудовый движок другой
DK
И запросы на него с ngnix прилетают только к истории
DK
Ну или без извратов с хендлером, а просто таким нибудь dblink или типа такого синхрить базы, если онлайн быстрый не нужен
AK
А что вы от истории хотите? Вам Camunda Optimize не поможет ли? А историю можно будет чистить
AV
history api будет использоваться только с "history" camunda. "runtime" camunda им не пользуется.
Проблем с использованием history api нет. "history" camunda создаётся в сервисе и наказывается на любую бд - все работает.
Все что осталось, это заставить "runtime" camunda писать исторические данные в другую бд.
Проблем с использованием history api нет. "history" camunda создаётся в сервисе и наказывается на любую бд - все работает.
Все что осталось, это заставить "runtime" camunda писать исторические данные в другую бд.
Д
А что вы от истории хотите? Вам Camunda Optimize не поможет ли? А историю можно будет чистить
Она же только для энтерпрайза?
AK
Ну да
DK
history api будет использоваться только с "history" camunda. "runtime" camunda им не пользуется.
Проблем с использованием history api нет. "history" camunda создаётся в сервисе и наказывается на любую бд - все работает.
Все что осталось, это заставить "runtime" camunda писать исторические данные в другую бд.
Проблем с использованием history api нет. "history" camunda создаётся в сервисе и наказывается на любую бд - все работает.
Все что осталось, это заставить "runtime" camunda писать исторические данные в другую бд.
ну вот тема с nginx и отдельной исторической камундой, которая ресты до исторической базы дает, работает.
AV
А что вы от истории хотите? Вам Camunda Optimize не поможет ли? А историю можно будет чистить
История нужна для того, чтобы вести аудит процессов.
Исторические события записываются параллельно в elasticsearch. От туда и используются.
А camunda history bd для надежного хранения.
В случае если elasticsearch разваливается, в ход вступает сервис который восстанавливает elasticsearch из этой бд
Исторические события записываются параллельно в elasticsearch. От туда и используются.
А camunda history bd для надежного хранения.
В случае если elasticsearch разваливается, в ход вступает сервис который восстанавливает elasticsearch из этой бд
AV
ну вот тема с nginx и отдельной исторической камундой, которая ресты до исторической базы дает, работает.
Я не очень понял как к сожалению
DK
ща нарисую
AV
