DK
ну и что
Size: a a a
2020 April 06
DK
там много чего другого нет)
MD
Это хорошо, когда есть разнообразие.
DK
там сайд бара к пропертями от камунды нет, а это сразу досвиданья
SD
Само изоляция идёт на пользу? 😂
DK
ох не говори. всё повода не было с вебсокетами разобраться
2020 April 07
Z
Коллеги, здравствуйте! У нас в проекте используются input/output для хранения переменных в таске. Есть некая проблема, если таска стартовала (1) переменные записались в нее в том ввиде в котором они лежали в процессе до этого, параллельно старту таски(1) происходит обновление переменных в таске (2) в ручном режиме. Так вот в переменную процесса значение приезжает, а в ту же переменную но уже для таски (1) нет. Подскажите как ее обновить не завершая таск (1).
SD
Мне кажется вам нужно хорошо разобраться с этим: https://docs.camunda.org/manual/7.5/user-guide/process-engine/variables/
Z
спасибо посмотрю!
DP
Дамы и господа камунданты, есть следующий вопрос.
У заказчика много разных систем, которые интегрируются через Камунду. Нужно задокументировать все эти API. Мне нужно найти систему которая будет генерировать документацию на API.
Пока я нашел следующие альтернативы Swagger:
1. I/O Docs ( https://github.com/mashery/iodocs )
2. Redoc, кажется надстройка над Свагером ( https://github.com/Redocly/redoc )
3. Радикальный метод: Не использовать никакую систему документации, а вместо этого заставлять разработчиков у каждой конечной точки (endpoint) поддерживать метод OPTIONS. В ответе на запрос OPTIONS присылать в ответе документацию (текстом).
4. RAML ( https://raml.org/ )
5. API Blueprint ( https://apiblueprint.org/ )
Кажется, что выбирать надо между Свагером, RAML и API Blueprint.
Если у кого-нибудь из присутствующих есть опыт работы с этими системами, буду признателен за сообщение. Особенно интересуют подводные камни и неочевидные трудности.
У заказчика много разных систем, которые интегрируются через Камунду. Нужно задокументировать все эти API. Мне нужно найти систему которая будет генерировать документацию на API.
Пока я нашел следующие альтернативы Swagger:
1. I/O Docs ( https://github.com/mashery/iodocs )
2. Redoc, кажется надстройка над Свагером ( https://github.com/Redocly/redoc )
3. Радикальный метод: Не использовать никакую систему документации, а вместо этого заставлять разработчиков у каждой конечной точки (endpoint) поддерживать метод OPTIONS. В ответе на запрос OPTIONS присылать в ответе документацию (текстом).
4. RAML ( https://raml.org/ )
5. API Blueprint ( https://apiblueprint.org/ )
Кажется, что выбирать надо между Свагером, RAML и API Blueprint.
Если у кого-нибудь из присутствующих есть опыт работы с этими системами, буду признателен за сообщение. Особенно интересуют подводные камни и неочевидные трудности.
DK
а что со свагером не так?
DP
С ним все так, просто хочу выяснить, нет ли чего лучше.
R
Dmitrii Pisarenko
С ним все так, просто хочу выяснить, нет ли чего лучше.
gRPC
DP
gRPC
Это разве для документации?
SS
Slate?
R
Dmitrii Pisarenko
Это разве для документации?
нет конечно, там просто contract-first подход, т.е. в какой то мере документация будет сразу
DP
Slate?
Спасибо
DP
нет конечно, там просто contract-first подход, т.е. в какой то мере документация будет сразу
Спасибо, но contract-first не подходит для существующих систем.
R
свагер поддерживается довольно широко
R
Dmitrii Pisarenko
Спасибо, но contract-first не подходит для существующих систем.
а расскажите плиз как используется камунда для интеграции систем?) мне реально интересно))