[!IMPORTANT] This community extension is deprecated. You should prefer the official Camunda REST connector. The connector is available in Camunda SaaS and for self-managed. Further resources:
Thank you to all contributors for making it a great extension. :tada:
A Zeebe worker to make HTTP calls (e.g. invoking a REST service). It is based on the built-in Java HttpClient.
Example BPMN with service task:
<bpmn:serviceTask id="http-get" name="stargazers check">
<bpmn:extensionElements>
<zeebe:taskDefinition type="http" />
<zeebe:taskHeaders>
<zeebe:header key="url" value="https://api.github.com/user/starred/zeebe-io/zeebe-http-worker" />
</zeebe:taskHeaders>
</bpmn:extensionElements>
</bpmn:serviceTask>
the worker is registered for the type http
required custom headers/variable:
url
- the url to invokeoptional custom headers:
method
- the HTTP method to use (default: GET
, allowed: post
| get
| put
| delete
| patch
)contentType
- the type of the request body (default: application/json
, allowed: any valid HTTP content type)accept
- the type of the response body that is accepted (default: application/json
, allowed: application/json
, text/plain
, application/xml
)statusCodeCompletion
- Status codes that lead to completion of the service task (default: 1xx,2xx
, allowed: comma separated list of codes including 1xx, 2xx, 3xx, 4xx and 5xx)statusCodeFailure
- Status codes that lead to the job failing (default: 3xx,4xx,5xx
, allowed: comma separated list of codes including 1xx, 2xx, 3xx, 4xx and 5xx)errorCodePath
- path expression (dot notation) to extract the error code of a failed response body (e.g. error.code
). If the error code is present then a BPMN error is thrown with this code instead of failing the job. Otherwise, that leads to the job failing.errorMessagePath
- path expression (dot notation) to extract the error message of a failed response body (e.g. error.message
). If the error message is present then it is used as the error message of the BPMN error. Otherwise, a default error message is used.header-
prefix. E.g. header-x-api-key
will add x-api-key
header to the HTTP requestoptional variables:
body
- the request body as JSONauthorization
- the value of the authorization header (e.g. token 6bac4..
)jobs are completed with variables:
statusCode
- the response status codebody
- the response body, if presentPlease note that the current way of handling placeholders is subject to change in the future, especially with https://github.com/zeebe-io/zeebe/issues/3417.
You can use placeholders in the form of {{PLACEHOLDER}}
at all places, they will be replaced by
Mustache is used for replacing the placeholders, refer to their docs to check possibilities.
Example:
<bpmn:serviceTask id="http-get" name="stargazers check">
<bpmn:extensionElements>
<zeebe:taskDefinition type="http" />
<zeebe:taskHeaders>
<zeebe:header key="url" value="https://{{BASE_URL}}/order?id={{orderId}}" />
<zeebe:header key="method" value="GET" />
</zeebe:taskHeaders>
</bpmn:extensionElements>
</bpmn:serviceTask>
BASE_URL
could be configured by the configuration variables from the URL and the orderId
might be a workflow variable.
To support some legacy scenarios the worker at the moment still also understands placeholders in the form of ${PLACEHOLDER}
. This is subject to be removed in later releases.
As described you can set the statusCodeCompletion
and statusCodeFailure
header to control the behavior depending on the HTTP Status. If the status code is in neither of the lists Zeebe will just keep waiting in the service task, allowing for asynchronous callbacks.
A common example is
To allow this, the jobKey
can be passed to the external service.
The docker image for the worker is published to GitHub Packages.
docker pull ghcr.io/camunda-community-hub/zeebe-http-worker:1.0.0
zeebe.client.broker.contactPoint
(default: localhost:26500
) For a local setup, the repository contains a docker-compose file. It starts a Zeebe broker and the worker.
cd docker
docker-compose up
Download the latest worker JAR (zeebe-http-worker-%{VERSION}.jar )
Start the worker
java -jar zeebe-http-worker-{VERSION}.jar
You can check health of the worker:
http://localhost:8080/actuator/health
This uses the Spring Actuator, so other metrics are available as well
The connection to the broker Zeebe can be changed by setting the environment variables
ZEEBE_CLIENT_BROKER_CONTACTPOINT
(default: 127.0.0.1:26500
).ZEEBE_CLIENT_SECURITY_PLAINTEXT
(default: true).ZEEBE_WORKER_DEFAULTNAME
(default: http-worker
)ZEEBE_WORKER_DEFAULTTYPE
(default: http
)This worker uses Spring Zeebe underneath, so all configuration options available there are also available here.
You can load additional configuration values used to substitute placeholders:
ENV_VARS_URL
)ENV_VARS_URL
isn't set)If ENV_VARS_URL
is configured, the worker will query an HTTP endpoint and expects a JSON back:
[
{
"key": "someValue",
"value": 42
},
{
"key": "anotherValue",
"value": 42
}
]
To load additional config variables from an URL set these environment variables:
ENV_VARS_URL
(e.g. http://someUrl/config
, default: null)ENV_VARS_RELOAD_RATE
(default 15000
)ENV_VARS_M2M_BASE_URL
ENV_VARS_M2M_CLIENT_ID
ENV_VARS_M2M_CLIENT_SECRET
ENV_VARS_M2M_AUDIENCE
To avoid exposing sensitive information, a prefix can be used to filter environment variables.
To change the prefix set these environment variables:
LOCAL_ENV_VARS_PREFIX
(default: "ZEEBE_ENV_"
)LOCAL_ENV_VARS_REMOVE_PREFIX
(default: true
)Build with Maven
mvn clean install
This project adheres to the Contributor Covenant Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to code-of-conduct@zeebe.io.