英文:
Difference between deployment through REST and Deployment through Process Application in Camunda
问题
根据以下链接中提供的建议，只有当流程模型不依赖于Java类（已突出显示部分）时，我们才可以通过REST进行部署。所以，如果我的流程包含Java代理和Java监听器，那么我不能/不应该通过REST部署流程吗？或者即使我通过REST部署这样的流程，它也不会起作用吗？
请提供建议。
链接：https://camunda.com/blog/2020/04/how-to-choose-the-right-camunda-architecture/
通过REST进行部署：您可以简单地使用Camunda的REST API将流程模型发送到引擎。通常用于外部任务模式或在流程模型不依赖于任何本地工件（例如Java类）的情况下。
通过流程应用进行部署：在这种情况下，您将本地构建和编译一个包含您的流程和其他所需工件的应用程序，然后将其部署到包含引擎的同一应用程序服务中。引擎将自动部署应用程序中找到的内容。
英文:
As per the recommendation given in below link, we can use deploy via REST only when it is independent of java classes (highlighted part) so if my process has Java delegates and Java listeners then I can't/shouldn't deploy the process via REST ? Or even if I deploy such process via REST, it won't work ?
Please advise.
https://camunda.com/blog/2020/04/how-to-choose-the-right-camunda-architecture/
Deploy via REST: you can simply use Camunda’s REST API to send the process model to the engine. This is often done for the External Task Pattern or in cases where the model is not dependent on any local artifacts (e.g. Java Classes)
Deploy via Process Application: In this case you would locally build and compile an application containing your process(es) and any other required artifacts and then deploy that to the same application service that contains the engine. The engine will automatically deploy what it finds in the application
Thanks
答案1
得分: 1
部署可以通过REST进行，可适用于任何情况。但是，如果您的流程模型使用了Java类，则这些类需要存在于服务器上，否则Camunda将无法找到您的代理或监听器。如果这些类已经部署，那么部署模型更改而不需要新的或更新的类将是可以的。如果更改了类，则需要进行字节码部署。如果您无论如何都要重新启动服务器，那么通过流程应用自动部署会很方便。当您只想尝试部署不需要代码更新的模型更改时，也可以通过REST API进行部署。
如今的建议是不要使用Java代理和监听器，而是将Camunda视为一个黑匣子（远程引擎），将您的代理代码放在外部工作程序中。这样，您的自定义代码与引擎分离，无需重新启动服务器即可应用对模型或集成代码的更改（尽管您仍然可以选择从现在的外部流程应用代码进行部署）。这种架构不仅建议将自定义代码与Camunda解耦，无论编程语言如何，更容易扩展，并与现代微服务架构更加一致，而且还使您在潜在的未来Camunda 8迁移方面处于更好的位置。
还请参阅：
- https://docs.camunda.io/docs/components/best-practices/architecture/deciding-about-your-stack-c7/#customize-your-stack
- https://docs.camunda.io/docs/guides/migrating-from-camunda-platform-7/#prepare-for-smooth-migrations
- https://docs.camunda.org/manual/7.19/user-guide/process-engine/external-tasks/
英文:
The deployment via REST can be used in any case. However, if your process model uses Java classes, then those classes need to exist on your server, otherwise Camunda will not be able to find your delegate or listeners. If the classes are already deployed, then deploying model changes that do not need new or updates classes will be fine. If you change classes, then a byte code deployment will be required. If you restart the server anyway, then deploying automatically via the process application is convenient. You can also deploy through the process application when deploying updated byte code but deploy via REST API when you just want to try deploy model changes not requiring code updates.
These days the recommendation is not to work with Java Delegate and listeners, but to treat Camunda as a black box (remote engine) and have your delegate code in external workers instead. This way your custom code is separated from the engine and you will never need a server restart to apply changes to model or integration code (You will still have the option to deploy from the now external process application code though). This architecture is not only advisable to decouple your custom code from Camunda, independent of programming language, easier scalale, and more in line with modern micro service architectures, but it also puts you in a better position for a potential future Camunda 8 migration.
Also see:
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论