В Camunda Cloud отказ от Java-делегатов в пользу внешних задач, выполняемых воркерами, не создает сложностей. Воркеры получают задачи из очереди, что аналогично модели «публикация/подписка», когда движок публикует задачи, а воркеры на них подписываются. Код воркеров может оставаться в рамках одного приложения, вызывая сервисы через REST или другие протоколы. Это позволяет избежать сложных архитектур, когда каждый микросервис извлекает свои задачи напрямую из движка.
Разработка связующего кода для внешних задач остается простой благодаря клиентским библиотекам, например, интеграции со Spring, где код воркеров выглядит подобно коду Java-делегатов. Несмотря на отсутствие прямого доступа к внутренностям движка, что позволяет избежать проблем, связанных с неправильным использованием механизмов движка, обработка исключений и повторные попытки остаются доступными через движок.
Хотя воркеры работают удаленно, задержки невелики (около 50 мс), не влияя на общую пропускную способность движка процессов. Основное внимание стоит уделить мониторингу работоспособности приложения воркера, поскольку движок процессов пока не может определить, что воркер перестал извлекать задачи. Вопросы транзакционной целостности решаются без менеджеров транзакций, что также описано в отдельной статье.
В итоге, переход на внешние задачи обеспечивает чистый и изолированный код, открывая преимущества удаленной конфигурации без заметных потерь в удобстве программирования. В Camunda Cloud этот подход является стандартной моделью для связующего кода, предоставляя простой и эффективный способ интеграции бизнес-логики в автоматизированные процессы.
Изображение носит иллюстративный характер
Разработка связующего кода для внешних задач остается простой благодаря клиентским библиотекам, например, интеграции со Spring, где код воркеров выглядит подобно коду Java-делегатов. Несмотря на отсутствие прямого доступа к внутренностям движка, что позволяет избежать проблем, связанных с неправильным использованием механизмов движка, обработка исключений и повторные попытки остаются доступными через движок.
Хотя воркеры работают удаленно, задержки невелики (около 50 мс), не влияя на общую пропускную способность движка процессов. Основное внимание стоит уделить мониторингу работоспособности приложения воркера, поскольку движок процессов пока не может определить, что воркер перестал извлекать задачи. Вопросы транзакционной целостности решаются без менеджеров транзакций, что также описано в отдельной статье.
В итоге, переход на внешние задачи обеспечивает чистый и изолированный код, открывая преимущества удаленной конфигурации без заметных потерь в удобстве программирования. В Camunda Cloud этот подход является стандартной моделью для связующего кода, предоставляя простой и эффективный способ интеграции бизнес-логики в автоматизированные процессы.
