Summary
Camunda 8 REST outbound connectors are modeled as service tasks backed by an element template (zeebe:modelerTemplate) with a zeebe:taskDefinition type like io.camunda:http-json:1. Today bpmn-to-code treats every service task identically as a plain job worker and only emits the raw job-type string under ServiceTasks. Connector tasks should be recognized as their own kind and surface their REST endpoint name and inputs/outputs, so a connector can be consumed from generated code the same way a worker is.
Motivation
A colleague building processes that are entirely REST connectors wants to reference each connector's endpoint name and its in/outputs in a type-safe way, instead of hardcoding strings. Currently there is no connector awareness in the code at all: findServiceTasks() ignores zeebe:modelerTemplate, and ZeebeImplementationKind only has JOB_WORKER (hardcoded). This forces users back to raw strings for exactly the model shape connectors produce.
Proposed Solution
- Detect element-template/connector service tasks via
zeebe:modelerTemplate and introduce a new implementation kind (e.g. CONNECTOR) alongside JOB_WORKER.
- Surface the connector's REST endpoint name and its inputs/outputs (from
zeebe:ioMapping) in the generated API, analogous to how worker variables are already emitted under Variables.
- Keep the raw job type (
io.camunda:http-json:1) as the value where a subscription string is needed.
- Decide on the generated structure (e.g. a dedicated
RestEndpoints grouping vs. extending ServiceTasks) — to be finalized in design.
Prerequisite
Depends on #41 (identifier sanitization crash fix).
Summary
Camunda 8 REST outbound connectors are modeled as service tasks backed by an element template (
zeebe:modelerTemplate) with azeebe:taskDefinitiontype likeio.camunda:http-json:1. Todaybpmn-to-codetreats every service task identically as a plain job worker and only emits the raw job-type string underServiceTasks. Connector tasks should be recognized as their own kind and surface their REST endpoint name and inputs/outputs, so a connector can be consumed from generated code the same way a worker is.Motivation
A colleague building processes that are entirely REST connectors wants to reference each connector's endpoint name and its in/outputs in a type-safe way, instead of hardcoding strings. Currently there is no connector awareness in the code at all:
findServiceTasks()ignoreszeebe:modelerTemplate, andZeebeImplementationKindonly hasJOB_WORKER(hardcoded). This forces users back to raw strings for exactly the model shape connectors produce.Proposed Solution
zeebe:modelerTemplateand introduce a new implementation kind (e.g.CONNECTOR) alongsideJOB_WORKER.zeebe:ioMapping) in the generated API, analogous to how worker variables are already emitted underVariables.io.camunda:http-json:1) as the value where a subscription string is needed.RestEndpointsgrouping vs. extendingServiceTasks) — to be finalized in design.Prerequisite
Depends on #41 (identifier sanitization crash fix).