DK
Тенант это ацтой, база все равно одна
Size: a a a
2021 March 31
ММ
Multi tenancy это идея для saas решений. То есть каждый Теннант может хранить свои копии таблиц, как будто они единственные и другие клиенты не видят данные в тех таблицах других клиентов, но не прибегая к разрезам и фильтрам. Но в разрезе камунды, я слабо представляю где это можно применить. Разве что разные отделы имеют свои модели.
VK
я просто хочу понять у процесса Cammunda есть свой Tenant ID, и допустим есть ряд процессов с одним тенентом, а другие с другим тенентом, то какие могут быть сценарии применение этих процессов с разными тенентами?
VK
например: у меня есть куча процессов в Camunda, которые можно разделить на разные не связанные апликейшеный фронта. Но есть несколько процессов общие для нескольких апликейшенов. Тут применим деление на Tenant? Если нет, то в каких вообще сценариях оптимально использовать в Camunde деление на Tenant ID?
VK
у кого-то может есть практика и сценарии использования у себя на практике данного Tenant ID? Поделитесь плиз опытом если не сложно.
DG
Vladimir Kulbida
у кого-то может есть практика и сценарии использования у себя на практике данного Tenant ID? Поделитесь плиз опытом если не сложно.
Делали федеральную систему. Нужно было разграничение по регионам, помимо традиционного деления по ролям. Заюзали тенантИд.
DG
Делали федеральную систему. Нужно было разграничение по регионам, помимо традиционного деления по ролям. Заюзали тенантИд.
Т.е. разграничили доступ к данным процессов. Даже большой начальник из Питера например, не должен иметь доступа к процессам в Краснодаре. Группы пользовали для разграничения доступности разных тасок в одном регионе.
На тенантов все легло красиво, без дополнительных действий
На тенантов все легло красиво, без дополнительных действий
VK
Дмитрий, спасибо за информацию. Как я понял у Вас тенант использовался для разграничения доступов пользователей к процессам. Если мы будим свой UI писать, а камунда будет только BPM движком, то через front будет дергать процессы под системной учеткой, то тенант в камунде в такой архитектуре применим?
VK
PS может вопрос глупый, сильно не пинайте, т.к. делаю только первый шаги в освоение Camunda
VK
и хочется изначально правильно выстроить архитиктуру СЭД на Camund-е
DG
Vladimir Kulbida
например: у меня есть куча процессов в Camunda, которые можно разделить на разные не связанные апликейшеный фронта. Но есть несколько процессов общие для нескольких апликейшенов. Тут применим деление на Tenant? Если нет, то в каких вообще сценариях оптимально использовать в Camunde деление на Tenant ID?
Вот по описанному здесь сценарию я бы не стал пользовать тенантов. Лучше, как и писали выше, разные камунды или все схемы шаред. Т.е. тенанты сделаны именно для разграничения доступа. Если в Вашем случае нужно гарантировать, что одни процессы не смогут видеть данные других процессов и нагрузка небольшая, то можно заюзать тенантов. Если просто хотите разделить разные аппликейшены, то не стоит ИМХО.
DG
Vladimir Kulbida
у кого-то может есть практика и сценарии использования у себя на практике данного Tenant ID? Поделитесь плиз опытом если не сложно.
Накину еще сценарий. Есть общая шаред схема, в ней внешние подпроцессы. Эти подпроцессы разные в разных регионах. Тоже хорошо ложится на камундовских тенантов
ММ
Если вы собираетесь делать некое решение с внешним клиентом, то вы можете рассмотреть решение с одной backend api point собственной, которая работает с несколькими движками камунды, тогда каждый движок будет независим и спрятан за api point. Все зависит от требований к системе
ММ
Если история включена и проходит много процессов, базы камунды могут очень быстро расти по размерам, и в итоге или использовать очистку или все равно решать вопрос с размерами бд, когда производительность может падать от числаактивных процессов и общего размера исторических данных. Этот фактор тоже нужно учитывать
VK
Коллеги, спасибо за консультацию. Из всего выше сказанного я понял, если у нас предполагается большой СЭД (апликейшенов >20) с множеством процессов в Камунде и если апликейшены не связаны между собой, то двужок Camunda лучше разделить на несколько инстенсов, а если в апликейшенах используются единые данные (справочники, структура и т.п.) то их вынести в отдельную БД и оттуда дергать?
DG
Vladimir Kulbida
Коллеги, спасибо за консультацию. Из всего выше сказанного я понял, если у нас предполагается большой СЭД (апликейшенов >20) с множеством процессов в Камунде и если апликейшены не связаны между собой, то двужок Camunda лучше разделить на несколько инстенсов, а если в апликейшенах используются единые данные (справочники, структура и т.п.) то их вынести в отдельную БД и оттуда дергать?
Я бы делал так, да. А последний пункт вообще обязательно в любом случае
ММ
execution.getVariable ("varName") == null
RD
Всем привет! Ищем java разработчика под Camunda. Описание вакансии тут. https://hh.ru/vacancy/42726970
Все вопросы в личку :)
Все вопросы в личку :)
SP
Vladimir Kulbida
Коллеги, спасибо за консультацию. Из всего выше сказанного я понял, если у нас предполагается большой СЭД (апликейшенов >20) с множеством процессов в Камунде и если апликейшены не связаны между собой, то двужок Camunda лучше разделить на несколько инстенсов, а если в апликейшенах используются единые данные (справочники, структура и т.п.) то их вынести в отдельную БД и оттуда дергать?
Разделять инстансы полезно еще и из соображений нагрузки. Camunda умная, но тормозная из-за того,что данные процессов пишутся в реляционную БД с транзакциями и блокировками. Поэтому точно не стоит объединять то, что может существовать отдельно.
DP
20-го апреля будет вебинар, посвященный релизу Камунды 7.15.
Зарегистрироваться на вебинар можно на
https://page.camunda.com/wb-camunda-7-15-release-webinar .
Зарегистрироваться на вебинар можно на
https://page.camunda.com/wb-camunda-7-15-release-webinar .
