Check out this extended Q&A from the CamundaCon Day 2 keynote with answers from Bernd Ruecker, Camunda Co-founder and Chief Technologist, and Daniel Meyer, Camunda CTO, that we couldn’t get to live. Read on to learn about our plans for connectors, the modeling and developer experience, and more.
CamundaCon 2022 wrapped up last week, and it was packed with amazing sessions. I and Daniel Meyer were glad to give an exciting keynote to open the second day that received a lot of great audience questions. We didn’t have time to answer them all live, but we wanted to make sure we got to them and shared the answers with the community.
If you missed the keynote or any other session of CamundaCon 2022, the recordings are already available on-demand – just click the link below to check them out, or keep reading for answers from myself and Daniel. Note that some questions have been combined/edited for clarity.
Connectors
Will there be a connector marketplace?
There were many questions around sharing connectors, which is great, because this is one important pillar of our connectivity vision for Camunda 8. So far, we do not have a marketplace ready yet. Still, it is pretty clear how a connector should look to contain all important artifacts in a way that could be later used by a possible connector marketplace (or “bazaar” like one question framed it :-)).
You can check out our out-of-the-box connectors as good examples. All sources are available and linked from here: https://github.com/camunda/connectors-bundle. A connector
- Is written in Java
- Uses the Connector SDK: Connector SDK Docs | Connector SDK GitHub
- Contains the element templates as JSON in a specific subdirectory
This is for example what the REST Connector looks like:
One question was also asked regarding whether Camunda verifies or certifies connectors in some way. At the moment, this is not yet a pressing problem, as we for sure verify our own out-of-the-box connectors, as we build and support them. But this is a very interesting question, if you look forward to a marketplace of connectors. Honestly, we haven’t yet defined all the nuts and bolts here, but I assume that we will end up with different “quality levels” of connectors. So, for example, every connector could be either
- Supported by Camunda
- Quality assured by Camunda (but maintained by a third party)
- Community-based (like all other existing Community Extensions, then also following the defined lifecycle stages)
And I am pretty sure that our partners that develop their own connectors will have their own quality assurance.
Can we write connectors in other programming languages?
The Connector SDK and the Connector runtimes focus on Java only, so you cannot write Connectors in any other language. We are still discussing if we want to open this up to other languages (especially Node.js and Python), but have more important things to do first (e.g. Inbound Connectors).
Does the REST Connector support OpenAPI?
Providing OpenAPI support directly in the connector is an interesting path to explore. We did first experiments with a community extension that can generate element templates for a connector from an OpenAPI specification. We are currently discussing how to productize this exactly. Expect something to land in one of the next releases.
Can we use out-of-the-box connectors in self-managed environments?
Starting with the just released Camunda Platform 8.1, all out-of-the-box connectors were made available on GitHub: https://github.com/camunda/connectors-bundle. You can run those connectors also self-managed, either by providing your own runtime (e.g. based on Spring Zeebe), or using the provided Docker container.
In our SaaS environment, we have a slightly different runtime (using Lambas for code execution), but this is not available for self-managed. But talk to us if you see requirements to have a runtime fitting into your SaaS environment (in a self-managed scenario).
Can a connector retrieve secrets from external vaults or secret stores?
The Connector SDK contains a simple abstraction for any SecretStore. In Spring Boot, for example, the default is to fall back to the environment (e.g. application.properties or environment variables), but in our SaaS environment we use the Google Secrets Manager to make sure credentials are safe.
If you manage the connector runtime yourself, you could also plug in your own implementation for a Secret Store, like Vault, probably using existing libraries within the Spring universe. We have not yet created a proof of concept (POC) around this, but I expect this to happen soon. So: yes, this should be definitely possible.
What is the difference between a Job Worker and a Connector?
The difference is actually not too big. Especially the code is pretty similar. But the connector works on a slightly higher abstraction. For example, you cannot simply access all process variables, but need to explicitly define what data will be available. Additionally, you will have support to handle secrets properly, which you have to handle on your own in a Job Worker.
This reduces the scope of what a connector can do, which allows us to build different runtimes. So while in Spring Boot the difference is hard to see, you can run a connector function in SaaS in a stateless Google Function, which is not the case for a Job Worker.
Anyway, I expect that we will add some more syntactic sugar on connectors over time, so this might even get the default way of waiting Java glue code in future, making it unnecessary to leverage the “low level” Job Worker API. But honestly, this also depends on how the community is picking things up.
Is there a way to provide different versions of a connector?
Yes, the task type defined for a connector contains an encoded version, so you can run multiple versions of a connector at the same time.
Is there any framework to extend and implement custom connectors?
Yes, the Connector SDK. We are also working on a tutorial blog post that will come up soon.
Modeling and Developer Experience
Great to see Modeler is becoming more like a powerful IDE! I am curious about any plan to help TESTING BPMN files?
There are many ideas and also some prototypes around testing BPMN processes and DMN decisions on this level, but at the moment there is no specific feature available or even planned on the near term roadmap. So this might take a bit to land in Camunda Platform 8, but I could very well imagine some Community Extension forming around this fascinating topic.
How can the artifacts that are being generated using the low-code UIs be stored in a versioning system like Git?
We still produce “normal” BPMN and DMN models as target artifacts. At the end of the day, those are XML files that can be downloaded and stored anywhere, including any version control system, of course including Git. The Desktop Modeler already has features built in to connect to the SaaS Modeler and synchronize this file by the push of a button. So it is not only pretty simple, but also allows you to control which versions should end up exactly in Git.
We are also looking into a direct synchronization of our SaaS repository with customers’ version control systems, but this is something for the future.
Other Questions
Will there be training videos on FEEL in the Camunda Academy?
FEEL is not only an exciting expression language, but also an important core component in the Camunda Platform 8 stack, so yes, we do plan to extend the educational material around FEEL.
Do you have any plans for supporting Signal Event types in Camunda?
BPMN Signal events are not yet available but planned to be available with one of the next releases. You can always check the current BPMN coverage online.
I know how to scale Zeebe, however I want to know how to scale the clients to be synchronized with Zeebe?
In general, you can connect as many clients to Zeebe as you like. The decision of course depends on your scenario. You could either just scale out your one application connecting to Zeebe, or even scale different workers for certain tasks in a process separately. The determination of how many client applications you run solely depends on what they need to do. For example, if they mostly call web endpoints, they might just wait for IO most of the time, so if programmed properly, you don’t need to scale them too much. But if you have workers doing complex calculations requiring a lot of CPU, you do need to run more of them to process high loads.
Our best practice around writing good workers might help to understand this.
Thank You
CamundaCon, and Camunda in general, can only be as great as it is thanks to our amazing community. Thank you as always for your questions, contributions and support. Don’t forget to check out all the CamundaCon 2022 videos and get excited for CamundaCon 2023. It’s already planned for next September and we can’t wait to see you there!
