Zeebe API (gRPC)
Zeebe clients use gRPC to communicate with the cluster.
Note: This specification still contains references to YAML workflows. This is a deprecated feature and will be removed at some point
#
Gateway ServiceThe Zeebe Client gRPC API is exposed through a single gateway service.
ActivateJobs
RPC#
Iterates through all known partitions round-robin and activates up to the requested maximum and streams them back to the client as they are activated.
ActivateJobsRequest
#
Input: ActivateJobsResponse
#
Output: #
Errors#
GRPC_STATUS_INVALID_ARGUMENTReturned if:
- type is blank (empty string, null)
- worker is blank (empty string, null)
- timeout less than 1 (ms)
- amount is less than 1
CancelWorkflowInstance
RPC#
Cancels a running workflow instance
CancelWorkflowInstanceRequest
#
Input: CancelWorkflowInstanceResponse
#
Output: #
Errors#
GRPC_STATUS_NOT_FOUNDReturned if:
- no workflow instance exists with the given key. Note that since workflow instances are removed once their are finished, it could mean the instance did exist at some point.
CompleteJob
RPC#
Completes a job with the given payload, which allows completing the associated service task.
CompleteJobRequest
#
Input: CompleteJobResponse
#
Output: #
Errors#
GRPC_STATUS_NOT_FOUNDReturned if:
- no job exists with the given job key. Note that since jobs are removed once completed, it could be that this job did exist at some point.
#
GRPC_STATUS_FAILED_PRECONDITIONReturned if:
- the job was marked as failed. In that case, the related incident must be resolved before the job can be activated again and completed.
CreateWorkflowInstance
RPC#
Creates and starts an instance of the specified workflow. The workflow definition to use to create the instance can be specified either using its unique key (as returned by DeployWorkflow), or using the BPMN process ID and a version. Pass -1 as the version to use the latest deployed version.
Note that only workflows with none start events can be started through this command.
CreateWorkflowInstanceRequest
#
Input: CreateWorkflowInstanceResponse
#
Output: CreateWorkflowInstanceWithResult
RPC#
Similar to CreateWorkflowInstance
RPC , creates and starts an instance of the specified workflow.
Unlike CreateWorkflowInstance
RPC, the response is returned when the workflow is completed.
Note that only workflows with none start events can be started through this command.
CreateWorkflowInstanceWithResultRequest
#
Input: CreateWorkflowInstanceWithResultResponse
#
Output: #
Errors#
GRPC_STATUS_NOT_FOUNDReturned if:
- no workflow with the given key exists (if workflowKey was given)
- no workflow with the given process ID exists (if bpmnProcessId was given but version was -1)
- no workflow with the given process ID and version exists (if both bpmnProcessId and version were given)
#
GRPC_STATUS_FAILED_PRECONDITIONReturned if:
- the workflow definition does not contain a none start event; only workflows with none start event can be started manually.
#
GRPC_STATUS_INVALID_ARGUMENTReturned if:
- the given variables argument is not a valid JSON document; it is expected to be a valid JSON document where the root node is an object.
DeployWorkflow
RPC#
Deploys one or more workflows to Zeebe. Note that this is an atomic call, i.e. either all workflows are deployed, or none of them are.
DeployWorkflowRequest
#
Input: DeployWorkflowResponse
#
Output: #
Errors#
GRPC_STATUS_INVALID_ARGUMENTReturned if:
- no resources given.
- if at least one resource is invalid. A resource is considered invalid if:
- it is not a BPMN or YAML file (currently detected through the file extension)
- the resource data is not deserializable (e.g. detected as BPMN, but it's broken XML)
- the workflow is invalid (e.g. an event-based gateway has an outgoing sequence flow to a task)
FailJob
RPC#
Marks the job as failed; if the retries argument is positive, then the job will be immediately activatable again, and a worker could try again to process it. If it is zero or negative however, an incident will be raised, tagged with the given errorMessage, and the job will not be activatable until the incident is resolved.
FailJobRequest
#
Input: FailJobResponse
#
Output: #
Errors#
GRPC_STATUS_NOT_FOUNDReturned if:
- no job was found with the given key
#
GRPC_STATUS_FAILED_PRECONDITIONReturned if:
- the job was not activated
- the job is already in a failed state, i.e. ran out of retries
PublishMessage
RPC#
Publishes a single message. Messages are published to specific partitions computed from their correlation keys.
PublishMessageRequest
#
Input: PublishMessageResponse
#
Output: #
Errors#
GRPC_STATUS_ALREADY_EXISTSReturned if:
- a message with the same ID was previously published (and is still alive)
ResolveIncident
RPC#
Resolves a given incident. This simply marks the incident as resolved; most likely a call to UpdateJobRetries or UpdateWorkflowInstancePayload will be necessary to actually resolve the problem, following by this call.
ResolveIncidentRequest
#
Input: ResolveIncidentResponse
#
Output: #
Errors#
GRPC_STATUS_NOT_FOUNDReturned if:
- no incident with the given key exists
SetVariables
RPC#
Updates all the variables of a particular scope (e.g. workflow instance, flow element instance) from the given JSON document.
SetVariablesRequest
#
Input: SetVariablesResponse
#
Output: #
Errors#
GRPC_STATUS_NOT_FOUNDReturned if:
- no element with the given
elementInstanceKey
was exists
#
GRPC_STATUS_INVALID_ARGUMENTReturned if:
- the given payload is not a valid JSON document; all payloads are expected to be valid JSON documents where the root node is an object.
ThrowError
RPC#
Throw an error to indicate that a business error is occurred while processing the job. The error is identified by an error code and is handled by an error catch event in the workflow with the same error code.
ThrowErrorRequest
#
Input: ThrowErrorResponse
#
Output: #
Errors#
GRPC_STATUS_NOT_FOUNDReturned if:
- no job was found with the given key
#
GRPC_STATUS_FAILED_PRECONDITIONReturned if:
- the job is already in a failed state, i.e. ran out of retries
Topology
RPC#
Obtains the current topology of the cluster the gateway is part of.
TopologyRequest
#
Input: TopologyResponse
#
Output: #
ErrorsNo specific errors
UpdateJobRetries
RPC#
Updates the number of retries a job has left. This is mostly useful for jobs that have run out of retries, should the underlying problem be solved.
UpdateJobRetriesRequest
#
Input: UpdateJobRetriesResponse
#
Output: #
Errors#
GRPC_STATUS_NOT_FOUNDReturned if:
- no job exists with the given key
#
GRPC_STATUS_INVALID_ARGUMENTReturned if:
- retries is not greater than 0
#
Technical Error HandlingIn the documentation above, the documented errors are business logic errors. These are errors which are a result of request processing logic, and not serialization, network, or other more general errors. These error are described in this sections.
The gRPC API for Zeebe is exposed through an API gateway, which acts as a proxy for the cluster. Generally, this means that the clients execute a remote call on the gateway, which is then translated to special binary protocol that the gateway uses to communicate with nodes in the cluster. The nodes in the cluster are called brokers.
Technical errors which occur between gateway and brokers (e.g. the gateway cannot deserialize the broker response, the broker is unavailable, etc.) are reported to the client using the following error codes:
GRPC_STATUS_RESOURCE_EXHAUSTED
: when a broker receives more requests than it can handle, it signals back-pressure and rejects requests with this error code.- In this case, it is possible to retry the requests with an appropriate retry strategy.
- If you receive many such errors within a small time period, it indicates that the broker is constantly under high load.
- It is recommended to reduce the rate of requests. When back-pressure is active, the broker may reject any request except CompleteJob RPC and FailJob RPC.
- These requests are white-listed for back-pressure and are always accepted by the broker even if it is receiving requests above its limits.
GRPC_STATUS_UNAVAILABLE
: if the gateway itself is in an invalid state (e.g. out of memory)GRPC_STATUS_INTERNAL
: for any other internal errors that occurred between the gateway and the broker.
This behavior applies to every request. In these cases, the client should retry with an appropriate retry policy (e.g. a combination of exponential backoff or jitter wrapped in a circuit breaker).
As the gRPC server/client is based on generated code, keep in mind that any call made to the server can also return errors as described by the spec here.