Using connectors on self-managed Zeebe

Camunda 8 Topics Discussion & Questions
1

We are interested in using the Rest APIs offered in C8. For now, we have self-managed Zeebe.

Documentation for C8 says " In Camunda Platform 8 Self-Managed, the user can employ the same concept of element templates and job workers to provide their connector landscape." (Introduction to connectors | Camunda Platform 8).

Can you provide any more direction on what implementing the element templates and job workers would mean on our side if we are not using SaaS version of C8?

PS: We have implemented job workers to which Zeebe passes control. I could create a job worker of a new type “myREST” to which Zeebe would pass control. Then, the myREST job worker could connect to a specified REST endpoint. Is that what is being suggested above by us “providing our own connector landscape”? Or, is there some way to leverage the REST connector that has already been created by Camunda for the SaaS version of Zeebe?

2

Hey Mcarleb.

This is exactly what the documentation means. An example is the community HTTP worker: GitHub - camunda-community-hub/zeebe-http-worker: Zeebe worker for HTTP calls (lacking the element templates part though).

We are still in the process to define how we want to make SaaS connectors usable in self-managed, but this might not happen before end of the year.

Hope that helps?
Bernd

PS: Would also be interesting to learn about your use case and your requirements for connectors (e.g. one interesting problem is how to define credentials in the environment that are then used in the connector).

1 Like
3

Thanks for response. We are just moving up learning curve with internal use cases. My simple example is to integrate C8 with Jira (so that user tasks can be done by Jira users using Jira forms in lieu of task list).

FWIW: I did integrate with Jira now using your job-worker approach and pyZeebe–where I create 2 new external job-workers, one of type ‘jira_interface’ and 2nd of type f’webhook_{uuid}’. The jira_interface task is always polling/ waiting for Zeebe to have work of that type. When jira_interface type task gets work, it generates a unique callback uuid and uses ‘requests’ package to pass that callback uuid (and other variables in payload) to Jira endpoint. (Jira could take days to finish its asynchronous workflow). The c8 workflow then moves to the 2nd external task type with a unique type = f’webook_{uuid}’. When jira completes its work, Jira posts to a Flask server with the uuid it was given earlier as a parameter. Flask then starts a new process in Celery job manager, passing the uuid to that new process. The new process in Celery then connects to Zeebe with the unique task type f’webhook_{uuid}’–grabbing control from the waiting task in Zeebe and immediately returning to release the wait.

Seems to work. Appreciate and suggestions!

1 Like
4